Then I tried the CalculiX version from @prool: CalculiX 2.20 for Win64
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?
I will watch with interest. Maybe I’ll find something. I clarify, I’m a programmer, not an mechanical engineer.
With best regards, Serge “Prool” Pustovoitoff
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.
Hello,
I’m fastly making ccx 2.20 with gfortran flag -std=legacy
(I’m using gfortran 11.3.0 in cygwin x64 in Windows 7)
For your pleasure:
http://mud.kharkov.org/files/calculix/ccx2.20-gfortran-legacy.zip
With best regards,
Serge “Prool” Pustovoitoff
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:
*Dload, Load case=1
Internal-1_Internal_Selection-1_Uniform_Pressure-1_S1, P1, 0
Then I found out that deleting the line 17934:
*Dload, op=New
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.
Both models can be found at:
both run in v2.17 (windows) and fail in v2.20 (macOS) (spooles solver) 
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.
I have been able to complete the analysis just once on the first attempt.
Second and next failed.
I’m getting this error:
Error opening solution file …\ccx\Dynamic_Steady_State.frd
I’m using win10Pro
Field of length 12 missing at column 14 of line
-1 1955 0.00000E
Context:
-1 1947 0.00000E+00 0.00000E+00 0.00000E+00
-1 1948 0.00000E+00 0.00000E+00 0.00000E+00
-1 1949 0.00000E+00 0.00000E+00 0.00000E+00
-1 1950 0.00000E+00 0.00000E+00 0.00000E+00
-1 1951 0.00000E+00 0.00000E+00 0.00000E+00
-1 1952 0.00000E+00 0.00000E+00 0.00000E+00
-1 1953 0.00000E+00 0.00000E+00 0.00000E+00
-1 1954 0.00000E+00 0.00000E+00 0.00000E+00
-1 1955 0.00000E
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
Maybe Mr. Pustovoitoff compilation is not multithread…?¿?
Hello,
I was unable to reproduce the error. Both models completed normally.
For testimg i’m using my ccx 2.20 in Windows 7 (i’m working in old Windows, not 10).
and ccx is no multithread
With best regards,
Prool
running your ccx.exe under Windows 10 (22H2) I can reproduce Matej issue. model-1 produces cygwin_exception while model-2 does not.
Analogically in macOS Catalina.
ccx 2.20
model-1 is crashed
model-2 not
With best regards,
Prool
hi, trying to run both input files on my machine Win10 (ccx_dynamic/pardiso). thrown some error messages,
*WARNING in calinput: PU, PHS, MAXU or MAXS was selected for a static, a non-cyclic-symmetric frequency, a buckling or a modal dynamic calculation; the output option is removed.
*WARNING in steadystate: too many modal damping coefficients applied damping coefficients corresponding to nonexisting eigenvalues are ignored
*edited
similar problems with ccx Prool’s distribution, add some message
model-1.inp
0 [main] ccx 310 cygwin_exception::open_stackdumpfile: Dumping stack trace to ccx.exe.stackdump
model-2.inp
Job finished
when i move the boundary to place outside the step, the problem become opposite in condition. model-1 is finish but not for model-2
this problem may similar, moving the boundary to place outside the step make it work.
i modified the input files (SSD_problem.inp) and try to re-running several times is consistent and finished using CCX Prool’s distribution…
beamdy8.inp placed the boundary outside the step, however, in your model is not.
Hereby my experience so far by debugging and testing.
I don’t want to be the judge of whether there are errors in ccx_2.20 or errors in the input files SSD_problems.inp, model-1.inp and model-2.inp, but I rightly believe that it would be nice if an error message could be inserted in future versions of ccx
Compiling and running the untouched original code of ccx_2.20 with the 3 datasets will produce a segmentation fault in the module steadystatedynamicss of other locations in the code where the cs array is being used because the array cs has not been allocated by use of the 3 datasets.
My claim can be proven by inserting the code shown in line 582 of ccx_2.20.c where the array should at least be allocated to avoid segmentation errors
Perhaps with this knowledge others can contribute with possible work arounds
