Hi!
This topic mentions that the curren RF key of *NODE PRINT outputs both reaction forces and point loads.
I’ve created a PR that introduces RR, which outputs only the reaction forces.
I’ve created some validation samples myself, but I’m not an advanced CalculiX user. Can somebody help me verify the output with some more complex inputs?
My validation case:
Input:
*NODE, NSET=NALL
1, 0, 0, 0
2, 1, 2, 0
3, 2, 0, 0
*ELEMENT, TYPE=T3D2, ELSET=EALL
1, 1, 2
2, 2, 3
3, 1, 3
*BOUNDARY
1, 1, 3
2, 3, 3
3, 2, 3
*MATERIAL, NAME=EL
*ELASTIC
2.1E11, .3
*SOLID SECTION, ELSET=EALL, MATERIAL=EL
1
*STEP
*STATIC
*CLOAD
** Node, DOF, Magnitude
2, 1, 1000.0
2, 2, 1500.0
*NODE PRINT, NSET=NALL
RF, RR
*END STEP
result:
S T E P 1
INCREMENT 1
forces (fx,fy,fz) for set NALL and time 0.1000000E+01
1 -1.000000E+03 -1.750000E+03 -7.225266E-14
2 1.000000E+03 1.500000E+03 -1.736508E-12
3 -4.575895E-12 2.500000E+02 1.808760E-12
reaction forces (rfx,rfy,rfz) for set NALL and time 0.1000000E+01
1 -1.000000E+03 -1.750000E+03 -7.225266E-14
2 5.798029E-12 -9.777068E-12 -1.736508E-12
3 -8.299139E-12 2.500000E+02 1.808760E-12
Yeeeaahh, as this has been a long awaited feature I would like to help you with the testing. So I downloaded the latest ccx development version including your changes from github. During the compilation I needed to fix 2 errors (in files resultsinduction.c and resultsstr.c) which seem to be related to other developments:
Then the code successfully compiled, but all runs then fail in the routine forparll.c . As I only have a beginner knowledge level on github usage, can you please share (through dropbox, wetransfer or other file sharing sites) the entire set of ccx *.f and *.c files you used for your development? I would then try to compile it again to start the testing. Thank you!
Ahh, thanks! Yes, I’m working on a different branch as well… I’ve pushed the fixes.
I compiled a single threaded version of CalculiX with SPOOLES using this tutorial. It works on my Linux machine as well in Windows using WSL.
I think the easiest way to exchange the files is:
Go to my repo
Click on the green “Code” button
Select “Download ZIP”
It should save a “CalculiX-reaction-forces-only.zip” file
This way I can make changes and you will always have the most recent version.
ok,I followed your above download instructions from github and recompiled all files:
With your recent fixes standard ccx test inp files work now.
But input files which have the new “RR” output still fail in routine forparll.c.
Hmm, could you please give me instrustions how you compiled ccx? I want to reproduce this bug.
I compile ccx with the cygwin environment under Windows 10.
Can you send me a detailed list of the steps you use or can you send me the output of calculix?
I updated the code to ensure proper boundaries, maybe it helps.
To analyze failing ccx runs I set environment variable CCX_LOG_ALLOC=1 to understand in which function the program may crash: This setting reports memory allocation changes to the console output. In our case I am not interested in the amount of memory being allocated, I am only interested in the function name mentioned by the console output.
Then running your example file above with the truss elements the last successful console outputs before the program crash are:
ALLOCATION of variable nal, file results.c, line=199, num=1, size=4, address= 42950005200
ALLOCATION of variable energysms1, file results.c, line=200, num=1, size=8, address= 42950005232
Using up to 1 cpu(s) for the stress calculation.
ALLOCATION of variable ithread, file results.c, line=232, num=1, size=4, address= 42950005264
FREEING of variable fn1, file results.c, line=248: oldaddress= 42949969168
FREEING of variable ithread, file results.c, line=248: oldaddress= 42950005264
FREEING of variable neapar, file results.c, line=248: oldaddress= 42949982384
FREEING of variable nebpar, file results.c, line=248: oldaddress= 42949982304
FREEING of variable qa1, file results.c, line=287: oldaddress= 42949911136
FREEING of variable nal, file results.c, line=298: oldaddress= 42950005200
FREEING of variable energysms1, file results.c, line=308: oldaddress= 42950005232
ALLOCATION of variable nkapar, file forparll.c, line=44, num=1, size=4, address= 42949911136
ALLOCATION of variable nkbpar, file forparll.c, line=45, num=1, size=4, address= 42949982304
ALLOCATION of variable ithread, file forparll.c, line=66, num=1, size=4, address= 42949982384
FREEING of variable ithread, file forparll.c, line=74: oldaddress= 42949982384
FREEING of variable nkapar, file forparll.c, line=74: oldaddress= 42949911136
FREEING of variable nkbpar, file forparll.c, line=74: oldaddress= 42949982304
This means that in line 74 of forparll.c the final memory cleanups seem to have worked:
Something seems to happen when function forparll() is being left or after. Once function forparll() is left the program returns back to resultsforc(). As resultsforc() does not contain an SFREE() command there is no console output to verify if the code crashes in function resultsforc(). So the crash may have alternatively occured in a function which called resultsforc().
I’m able to build it from commit 86128e7 Ensure bounds. · g0mb4/CalculiX@86128e7 · GitHub that @gmb did just a few hours ago.
It seems to work - prints numbers to the .out file for *NODE PRINT with RR.
This is awesome! It would be nice to have it in *NODE FILE too so I can read it for post-processing but anything’s better than nothing.
I’m working on the frd file output, just have to figure out memory management.
I’ve implemented RR for *NODE FILE, feel free to test it.
Including
*NODE FILE
RR
does generate REFO vectors in the .frd file but causes displacements to be all random and wrong.
The reaction forces are wrong too, even with just *NODE PRINT, which also breaks displacement.
Unrelated to that, do you think it would make more sense to hitch-hike on the RF input? Then it won’t be diverging from Abaqus. RF would mean reaction forces plus legacy external forces. You’d always get both together which I suppose isn’t really a problem.
Can you send me the .inp file you used and the expected results?
Interesting idea, I kinda like that, I can give it a try.
I give it a tought and my consern is that way RF would produce a different output as before and it may break scripts expecting the old format. Calculix is a widely used software, I’m sure someone is dependig on the format of the output of RF.
The real nice solution would be to rename RF to TF and RR to RF, but it is also a breaking change.
This is why I introduced a new key. If we decide to do the renaming, it would be “just” a search and replace.
