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.
Here’s an example.
With RR, uy on node 3 = 2.67503
Without RR, it’s 1.22368E-06
** Generated by Mecway 33
*NODE
1,-0.001993585721254,-0.0095,0.00283995009525
2,-0.0009061602102213,-0.008372088848054,0.003793472798944
3,-0.001999483522315,-0.006708357894769,0.002954550676843
4,-4E-19,-0.007629588848054,0.004370538201858
5,-0.001812320420443,-0.0095,0.003845869194171
6,-3E-19,-0.007244177696108,0.003741076403717
7,-0.0004377099981291,-0.008890312877388,0.001787086741345
8,-4E-19,-0.0095,0.002976
9,-2E-19,-0.0087575,0.003988
10,-0.0008754199962583,-0.008280625754775,0.002574173482689
11,-0.001437451759287,-0.007494491824772,0.002764362079766
12,-0.0009997417611574,-0.006976267795438,0.00334781354028
13,-0.00134387020835,-0.008890312877388,0.00321002133843
14,-0.0009061602102213,-0.0095,0.003410934597085
15,-0.001799004471467,-0.006764878480191,0.003873832732807
16,-0.0006040185793307,-0.007069575114372,0.004167508442453
17,-0.0009358596285211,-0.0095,0.001232468739823
18,-0.0008270805742746,-0.0095,0.002425916622148
19,-1E-19,-0.008015,0.005
20,-3E-19,-0.008372088848054,0.003358538201858
21,-0.0006372280026651,-0.007454986266318,0.004895769097918
22,-4E-19,-0.0095,0.001
23,-0.001654161148549,-0.0095,0.001875833244296
24,-4E-19,-0.0095,0.001988
25,-0.001208037158661,-0.006894972532635,0.004593940481188
26,-0.001957313081934,-0.008104178947384,0.00341100547355
27,-0.0004377099981291,-0.007762401725442,0.003157624943203
28,-0.001555809315623,-0.008197486266318,0.004256764645198
29,-0.001074304801176,-0.0087575,0.004686970418878
30,-0.0004377099981291,-0.008890312877388,0.002775086741345
31,-0.001264790572404,-0.008890312877388,0.002225003363492
*ELEMENT,TYPE=C3D10
1,10,6,5,8,27,2,13,30,20,14
2,5,25,19,6,28,21,29,2,16,4
3,3,25,5,6,15,28,26,12,16,2
4,8,23,10,22,18,31,30,24,17,7
5,10,6,3,5,27,12,11,13,2,26
6,5,10,8,23,13,30,14,1,31,18
7,8,5,19,6,14,29,9,20,2,4
*ELSET,ELSET=CLIP
1
2
3
4
5
6
7
*MATERIAL,NAME=HDPE
*ELASTIC,TYPE=ISOTROPIC
1000000000,0.46
*SOLID SECTION,ELSET=CLIP,MATERIAL=HDPE
*BOUNDARY
1,1,0
1,2,0
1,3,0
5,1,0
5,2,0
5,3,0
8,1,0
8,2,0
8,3,0
14,1,0
14,2,0
14,3,0
17,1,0
17,2,0
17,3,0
18,1,0
18,2,0
18,3,0
22,1,0
22,2,0
22,3,0
23,1,0
23,2,0
23,3,0
24,1,0
24,2,0
24,3,0
*STEP
*STATIC
*CLOAD
3,2,0.01374873524481
25,2,-0.005515414433518
6,2,-0.008211682490108
15,2,0.3442674578994
12,2,0.3406962805137
16,2,0.3150146232657
*NODE FILE,GLOBAL=YES
U
*NODE FILE
RR
*END STEP
Hi!
I’ve done some testing. I’ve compared the results of the current upstream (b5ecbd6 “adjusted some test examples”) and my (ff7f8a7) version of your example. I’ve used a single-threaded SPOOLES solver in both cases.
The results:
U\RF - two *NODE PRINT/*NODE FILE cards in separate lines
U,RF - one *NODE PRINT/*NODE FILE card, keys separated by comma
etc…
*NODE PRINT
upstream (U)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
upstream (U\RF)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
RF: 3 -2.320892E-01 -1.392228E-02 4.219515E-01
upstream (U,RF)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
RF: 3 -2.320892E-01 -1.392228E-02 4.219515E-01
patch (U)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
patch (U\RF\RR)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
RF: 3 -2.320892E-01 -1.392228E-02 4.219515E-01
RR: 3 0.000000E+00 0.000000E+00 0.000000E+00
patch (U\RR)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
RR: 3 0.000000E+00 0.000000E+00 0.000000E+00
patch (U,RF,RR)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
RF: 3 -2.320892E-01 -1.392228E-02 4.219515E-01
RR: 3 0.000000E+00 0.000000E+00 0.000000E+00
patch (U,RR)
U: 3 2.881197E+08 3.280582E+07 -7.318501E+08
RR: 3 0.000000E+00 0.000000E+00 0.000000E+00
*NODE FILE
upstream (U)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
upstream (U\RF)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
RF: 3-2.32089E-01-1.39223E-02 4.21952E-01
upstream (U,RF)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
RF: 3-2.32089E-01-1.39223E-02 4.21952E-01
patch (U)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
patch (U\RF\RR)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
RF: 3-2.32089E-01-1.39223E-02 4.21952E-01
RR: 3 0.00000E+00 0.00000E+00 0.00000E+00
patch (U\RR)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
RR: 3 0.00000E+00 0.00000E+00 0.00000E+00
patch (U,RF,RR)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
RF: 3-2.32089E-01-1.39223E-02 4.21952E-01
RR: 3 0.00000E+00 0.00000E+00 0.00000E+00
patch (U,RR)
U: 3 2.88120E+08 3.28058E+07-7.31850E+08
RR: 3 0.00000E+00 0.00000E+00 0.00000E+00
I permuted the positions as well (RF,U,RR;RR,RF,U;…) and they yield the same results.
As you can see U does not change.
Did you “rm *.o”-d the build directory before rebuilding? Your case looks like memory corruption, it may happen if you link the wrong version of the function.