PrePoMax Results fail due to memory limit

I ran a simulation over night. Its just a pressfit attempt and I went with 1s simulation in 0.01s increments. The PrePoMax was awesome to set it up and try different things but now after having run the simulation and having results, I can’t see them. Clicking on the “results” button quickly fails with an exception and if you look at ram usage you see a clear ramp and then a dump.

So Now I’m trying to extract the data into .VTU using this code:

#imports for running CCX and output file conversion
import os
import ccx2paraview
import logging

#imports for file modification:
from tempfile import mkstemp
from shutil import move, copymode
from os import fdopen, remove

cwd = os.getcwd()


#convert output to VTK (vtu) format so paraview can use it
frd_file_name= Setupname+’.frd’
logging.basicConfig(level=logging.INFO, format=’%(levelname)s: %(message)s’)
c = ccx2paraview.Converter(frd_file_name, [‘vtu’])
input(“Press enter to exit ;”)

Anyway. I just noticed the new pastix exodus and I will also give it a try.

You can export the inp file from PrePoMax and then submit it from command line using CalculiX. As a result you will get frd file that you can postprocess in GraphiX.

looks like ccx2paraview eats up all ram, then starts using up ssd steadily. eventually it crashed on me. but I started digging into the code and it may be something that can be worked out.

The Calculix version that includes Exodus format can actually output results in that format directly it seems. Then according to the story, Paraview can open that format. I have yet to see.
like this:
rem === Final CCX run command (output in the Exodus II format) ===
%CCX_PATH%\ccx_pastix_exodus.exe -i %~n1 -o exo

So I guess one just replaces the pastix solver with a batch file that includes it with those arguments.

1 Like

I do not think that the memory limit is a problem for PrePoMax since it can use the virtual memory of the Windows OS. But having a large number of finite elements or many unconnected parts can be very memory and CPU intensive. I could help determine the problem if you could share the .frd file with me.

1 Like

It did continue for a while swapping on an SSD but after it completed I could not open the results on prepomax. I had to use a computer with lots of memory ram to translate the results using the ccx2paraview converter. After that I started using the EXO II format and it is so much better! I can even open a partially completed run in paraview while still running.

1 Like

Well, I am not familiar with the EXO II format. Is this format supported in the official CalculiX build? I could not find any information about it.

1 Like

Hi Matej, this is an old document on EXODUS II data format.

Best regards

Dear Sergio,

thank you for the info. I will check It out and I saw you asked how to export in this format. Is this only working for the Pastix version of CalculiX? What are your experiences using it?

Kind regards, Matej


You can add this extras to any CalculiX 2.17 (linux, windows, … because this is patch/extras for source code)

See this page:

1 Like

I have tested several conversors for the .frd results, this CCX version with Exodus support was the last one. I found out that some conversors translate the results to .vtk , vtu or rmed results, some of them gives the no lineal results as a set of multiple files (I found hard to manage 100, 200, or more files…), and other as Calmed8 gives only one rmed file. Those vtk, vtu or rmed files needs a different work to postprocess in Paraview, I have used a lot Calmed8 with rmed format and found it more suitable than the others. There are two important things missed in all conversors, the first one is that some important variables are not translated (don´t remember well now, but I could search again), and the other is that they don´t give you the different components (parts) of the model separated, so you must use some filter based on element number to recreate on Paraview and be able to postprocess separately. Worst thing is that sometimes parts don´t have elements numerated correlatively, so is a pain or directly impossible to separate it.
When I saw the work done on Prepomax for postprocessing, I though that there was a vtk conversion ready for the frd results, that´s why I aked for long time ago.