I prepared a simple test model for the steady state dynamics analysis procedure. The problem is that it sometimes runs to completion and sometimes fails with no error during the second step (SSD). This behavior occurs in ccx 2.18, 2.19 and 2.20. It usually terminates at the same stage (“Composing the steady state response from the eigenmodes”) but sometimes during factorization.
Here’s the input file:
I run it on Windows with parallelization but @Matej tested it using a single CPU and the same behavior occurred (but with “POSIX WinThreads for Windows has stopped working” pop-up error message). This also proves that it’s not the fault of a particular computer.
Can you confirm the problem ?
What’s interesting, I’ve noticed that the beamdy8.inp file from CalculiX test examples is solved successfully in most cases but once in a while fails during factorization. I don’t know if it’s related to the problem with my model though.
Thank you for confirming the issue. The analysis discussed in that older thread is modal dynamic and involves shell elements but maybe similar bugs occur with other modal superposition procedures performed on solid elements. Perhaps the rigid body constraint is causing this issue in my case.
I can confirm similar behavior in a resonance analysis I did some months ago using CalculiX 2.19. I reduced the mesh size so fewer equations needed to be resolved (for me, any mesh resulting in less than 25000 equations worked). At the time, I thought it was something wrong with my machine like a lack of RAM or something like this.
At the time I didn’t get any errors, the analysis just stopped, and even though I’m not sure when I think the last message was something about matrix composition just after the frequency analysis was complete (first step).
I am adding support for Steady state dynamics step into PrePoMax and the issue with the Steady step dynamics step is still there. I wrote about it in the topic: Segmentation fault with ccx_2.19 dynamic modal analysis - #10 by Matej and hopefully we will get some information on how to solve them.
Since this topic best fits the problem, I will post all my findings directly here.
I can confirm some issues for windows versions of Calculix 2.16, 2.18, 2.19 and 2.20 running the *Steady state dynamics step. It seems that CalculiX is able to solve problems with smaller number of nodes (for me, it is around 1000) but fails for a larger model (for me it is around 5000 nodes). It fails for PaStiX and Spooles solvers. I think it fails after the frequency step finishes and steady state dynamic step starts. It outputs the result for the starting frequency of the steady state dynamic step.
But I run a test with about 100.000 nodes on 2.16 version for Linux and it works. So maybe it is only a windows problem?
I tried it with steady state dynamics up to 100.000 nodes and I got the results every time I tried it. It has some problems with PrePoMax, so I had to add compatibility mode to get it to work but running it from command line works fine. The results can also be read without a problem.
Now I am wondering what is the actual difference between the official CalculiX version and the version compiled by @prool.
A fascinating finding, Matej. This bug with the steady-state dynamics step has always bothered me. And it is even better to know that you will implement it in PrePoMax!
I am adding support for imaginary load components in PrePoMax while using the prool’s version of Calculix for Windows, but unfortunately, I came across some unwanted behaviour. The solver crashes in some cases while it works in others. I tried to figure out what is wrong more specifically but could not. Very different changes to the unworking .inp file caused it to work again. If @prool would like to look at it I would be happy to share the files and my findings.
After some reading I think that the official Windows versions of CalculiX are compiled by rafal.brzegowy. It that is true, would it be possible to for you @rafal.brzegowy to look into this issue?
Some of the modules in ccx have been written in FORTRAN 66. Compiling in Windows with GFORTRAN 11.2 I was warned to raise the flag -std=legacy to avoid unexpected program execution in those modules. I haven’t traced where those module belongs and if they still are active. I wont claim that’s the problem but it smells like a compiler problem.
Thank you for the quick response. I have tried to use the -legacy version, but it is the same.
I ran the model on two different computers, both on windows 10, and I tried prool’s versions 2.18, 2.19 and 2.20. All of them fail to complete the analysis. I tried it with the model called model-1.inp. Unfortunately, the model contains around 10000 nodes.
Then I tried to change some things in the model and found out that adding additional load with a magnitude of 0 helps. model-2.inp contains this case that works. The lines that define the added load with a magnitude of 0 are:
from the model-1.inp also helps to complete the execution. So I thought this is the main reason but then I discovered that with a different density of the mesh, the model works.
If some additional data is needed I can provide it.
Just for info in case anyone trying to locate for the error causing the terminate without error.
I haven’t been able to provoke the failure in Debian linux, but in Windows I have found that bypassing the call to the frd() at line 2320 in the steadystate,c file seems to remove the unexpected termination.
I believe it must be a pointer/counter/array running out of boundary but in fact it could also be an uninitialized variable.
It would be nice if we together will be able to solve the problem.
Have you tested with different number of threads/cpus. Running ccx with a single cpu/thread should provide sequential execution of the code and since every return has a preceding fclose() in the frd() module so the fopen-fclose sequence should be ok
I have tested both input files from Matej with both Spooles and Pardiso in ccx_2.20 with my described bypass of frd() and the all run to the end with job finished.
I fully aware of that the bypass isn’t a final solution but only an attempt to isolate the problem
I don’t have dropbox so I don’t know how to share if you would like to test my ccx
