I do remember seeing lots of warnings while it was running, but no errors (it’s running on a CMD window that then disappears when it’s done, so can’t copy & paste the log). What’s the log file called? I assumed it’s in the Temp folder? Number of elements is 1,670,267
If you run from PrePoMax, the log is shown in its job monitor. Other files are indeed in Temp by default (working directory can be changed if needed). But, especially for larger models, it might be better to run from the command line in such cases: Using standalone CalculiX
Then, even if output goes only to the command window, you can always redirect it to a text file with:
ccx_static job_name > job_name.log
This is quite a lot, but it should be solvable with Pardiso. Unless you have e.g. surface to surface radiation.
Strangely, when I run the .inp in the standalone CalculiX on my local computer I get the error *ERROR in e_c3d_th: nonpositive jacobian determinant in element 114690. But the same file runs fine in PrePoMax (and the results are what I’d expect them to be)
I’ve attached .log file
ImprovedCase.zip (755.3 KB)
The log file mentions really old version of CalculiX (2.10), PrePoMax currently uses 2.22.
Regarding negative jacobian, disable adjustment in tie constraints.
How do you submit it ? It should be just:
ccx_static ImprovedCase
provided that you have the solver’s directory added to Path or call it directly from a folder where the .inp file is located. Check the aforementioned forum thread about standalone ccx submission.
Without “.exe”. The second command should run. Maybe the folder with ccx_static is not properly recognized in Path. You could try calling it from its directory directly.
Is .inp also located in the same folder as the solver ?
And make sure that cmd is opened in the same directory
You can enter “cmd” in the address bar to open it there.
That did it – thanks!
Both .log files are showing the same error, which is strange because I was able to run it from PrePoMax on my computer no probs.
.log files for local and server are attached
.log files.zip (1.5 MB)
Libraries (.dll files) needed for Pardiso are not provided with the CalculiX binary available on its website. However, PrePoMax provides them so you could copy them over or just use the binary from PrePoMax’s Solver folder (version 2.22).
Or you can simply edit the .inp file and remove the SOLVER=PARDISO parameter from the *HEAT TRANSFER keyword to use the default (potentially slower and less robust) PaStiX solver.
Ran the ccx_dynamic from the Solver folder. Only when running it from my local computer does it get to the finish line. Seems like when running on HPC server it doesn’t get to iterations for some reason
.log files attached
.log files.zip (1.5 MB)
Did you check if other models run on this cluster ? Maybe it has some issue with CalculiX installation. Otherwise, if it works on one machine and doesn’t work on other, it might be good to report a potential bug on the CalculiX forum.
It seems that you are running it on 1 CPU, at least locally. You can use the OMP_NUM_THREADS variable (mentioned in the Using standalone CalculiX thread) to set as many CPUs as you have.
Forgive me for the late reply. I’ve posted this on CalculiX, someone suggested it might be related to Pardiso libraries and then the post got removed (!). I’ve tried changing it to *Heat transfer, Steady state and that didn’t work. I’ve also changed the PrePoMax settings > CalculiX to Default instead of Pardiso and that didn’t help either
Strange, did you get any notification explaining why it happened ? Maybe it was a mistake.
The default solver is PaStiX, it’s unlikely to provide any speed-up, apart from some specific cases.
If it appears to be a bug, you can also report it here: Issues · Dhondtguido/CalculiX · GitHub
The community thought it was spam
It is only a bug on the HPC server as it works just fine on my laptop. Have reported it to them and hopefully they’ll be able to fix it.
Apparently, it was a mistake. I see that it was restored.
Yeah, but such inconsistencies should be analyzed when possible - perhaps something can be improved in the solver here. Let’s see what they say. Ultimately, a GitHub ticket might be needed when it’s confirmed/triaged on their forum.







