I have an Excel file with which I track our testing status including all above examples: Unique Download Link | WeTransfer
For your developments updates I recommend to just focus on a single issue (like for the OUTPUT=3D option) . Once you provided an update I can easily rerun all earlier test cases. I will now focus on some tests for cylindrical coordinate systems and will share the results and input files once available. Thank you!
Attached (Unique Download Link | WeTransfer) some of my recent test cases with results and inp files for:
*BUCKLE analysis
*TRANSFORM card being used
The xlsx file includes the test status and test case specific observations. Summary in a nutshell:
*BUCKLE files include the RR outputs!
Using the *TRANSFORM card the RR outputs seem to be missing in the dat file.
Thank you!
Wow! Impressive work, thank you! I’ll try to test OUTPUT=3D.
It is a bit more complicated then I thought. I’ll try a different approach, it’ll take a couple of days. Please do not waste your time testing the current build.
I’ve restructured the code. The I’m not sure about the result. The .dat looks okay, but the .frd is strange to me.
Please run some of your tests @johanngil .
I checked some of the problem cases where I struggled in the past with the “RF” output. Some of them dealt with gravity loads (e.g. CCX gravity problem? ). For the mentioned gravity problem example the output for RF and RR is equal because there is no point load, only a distributed load through *DLOAD. Is that what you want to achieve through your development as you mentioned in your initial post in this thread to adress the point loads only?
Here the box gravity model with some additional output like mass and RR:
*node
1, 0., 0., 0.
2, 10., 0., 0.
3, 10., 10., 0.
4, 0., 10., 0.
**
5, 0., 0., 10.
6, 10., 0., 10.
7, 10., 10., 10.
8, 0., 10., 10.
**
9, 5., 0., 0.
10, 10., 5., 0.
11, 5., 10., 0.
12, 0., 5., 0.
**
13, 5., 0., 10.
14, 10., 5., 10.
15, 5., 10., 10.
16, 0., 5., 10.
**
17, 0., 0., 5.
18, 10., 0., 5.
19, 10., 10., 5.
20, 0., 10., 5.
**
*nset, nset=bottom
1, 2, 5, 6, 9, 13, 17, 18
**
*element, type=c3d20, elset=cube
1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
16, 17, 18, 19, 20
**
*material, name=steel
*density
7.8E-09
*elastic
210000, 0.28
**
*solid section, elset=cube, material=steel
**
** +++++++++++++++++++++++++++++++++++++++
*step
*static
1.,1.,1.E-05,1.
**
*boundary, op=new
bottom, 1, 3, 0
**
*Dload
cube, Grav, -9800., 0.0, 1.0, 0.0
**
*node print, nset=bottom, totals=Yes
rf, RR
**
*node file
rf, u, RR
*el file
s, e
*EL PRINT, TOTALS=YES, ELSET=CUBE
EVOL, EMAS
*end step
Thanks! I’ll test it.
Good question. I think feature parity with Abaqus would be a reasonable goal. I think I’ll try to match .dat files first, .frd seems more tricky.
I’ve compared the results of the gravity example:
Abaqus:
THE FOLLOWING TABLE IS PRINTED FOR NODES BELONGING TO NODE SET BOTTOM
NODE FOOT- TF1 TF2 TF3
NOTE
1 8.4233004E-04 -5.1218225E-03 8.4233004E-04
2 -8.4233004E-04 -5.1218225E-03 8.4233004E-04
5 8.4233004E-04 -5.1218225E-03 -8.4233004E-04
6 -8.4233004E-04 -5.1218225E-03 -8.4233004E-04
9 9.3581259E-19 2.4231822E-02 3.4691995E-03
13 -2.0274263E-18 2.4231822E-02 -3.4691995E-03
17 3.4691995E-03 2.4231822E-02 1.0119926E-17
18 -3.4691995E-03 2.4231822E-02 1.3020590E-17
TOTAL 2.1684E-18 7.6440E-02 -3.3140E-18
THE FOLLOWING TABLE IS PRINTED FOR NODES BELONGING TO NODE SET BOTTOM
NODE FOOT- RF1 RF2 RF3
NOTE
1 8.4233004E-04 -5.1218225E-03 8.4233004E-04
2 -8.4233004E-04 -5.1218225E-03 8.4233004E-04
5 8.4233004E-04 -5.1218225E-03 -8.4233004E-04
6 -8.4233004E-04 -5.1218225E-03 -8.4233004E-04
9 9.3581259E-19 2.4231822E-02 3.4691995E-03
13 -2.0274263E-18 2.4231822E-02 -3.4691995E-03
17 3.4691995E-03 2.4231822E-02 1.0119926E-17
18 -3.4691995E-03 2.4231822E-02 1.3020590E-17
TOTAL 2.1684E-18 7.6440E-02 -3.3140E-18
CalculiX:
forces (fx,fy,fz) for set BOTTOM and time 0.1000000E+01
1 8.423300E-04 4.433178E-03 8.423300E-04
2 -8.423300E-04 4.433178E-03 8.423300E-04
5 8.423300E-04 4.433178E-03 -8.423300E-04
6 -8.423300E-04 4.433178E-03 -8.423300E-04
9 -2.005615E-18 1.149182E-02 3.469199E-03
13 -4.551796E-18 1.149182E-02 -3.469199E-03
17 3.469199E-03 1.149182E-02 -6.138871E-19
18 -3.469199E-03 1.149182E-02 -1.704654E-18
total force (fx,fy,fz) for set BOTTOM and time 0.1000000E+01
1.734723E-18 6.370000E-02 -5.838175E-19
reaction forces (rfx,rfy,rfz) for set BOTTOM and time 0.1000000E+01
1 8.423300E-04 4.433178E-03 8.423300E-04
2 -8.423300E-04 4.433178E-03 8.423300E-04
5 8.423300E-04 4.433178E-03 -8.423300E-04
6 -8.423300E-04 4.433178E-03 -8.423300E-04
9 -2.005615E-18 1.149182E-02 3.469199E-03
13 -4.551796E-18 1.149182E-02 -3.469199E-03
17 3.469199E-03 1.149182E-02 -6.138871E-19
18 -3.469199E-03 1.149182E-02 -1.704654E-18
total reaction force (rfx,rfy,rfz) for set BOTTOM and time 0.1000000E+01
1.734723E-18 6.370000E-02 -5.838175E-19
Numerically different (nodes 9 and 13), but the behaviour is the same. I did not change the calculation of “RF”, so I accept this result.
There’s still a problem:
In Abaqus, TF, isn’t supposed to include gravity for some reason. From the Abaqus manual:
Total force is the sum of the reaction force and point loads.
so it’s different from CCX’s external force. From the CCX manual:
The external forces (key RF) are the sum of the reaction forces, concentrated loads (*CLOAD) and distributed loads (*DLOAD) in the node at stake.
That’s why Abaqus’s RF = TF. Both their totals are equal in magnitude to the weight (9800* 7.8e-9* 1000 = 0.07655)
However, CCX’s reaction force total is not equal in magnitude to the weight so it’s both inconsistent with Abaqus and not what anybody would expect.
I see, thank you for the clarification.
I ran further analysis types (e.g. modal dynamics, steady state dynamics), laminates, transformed coordinate types and checked if the reaction forces RR appear in the resulting dat files which they always did. I did not invest much time of the analysis of the frd file content as I am using Prepomax which had some problems (individual RR force components are displayed, but not the total force) to show this new variable.
Here ( Unique Download Link | WeTransfer ) an example which I ran with a transformed cyclindrical coordinate system which has for all nodes except the BOUNDARY nodes the forces in local and global coordinate systems. Although requested for local coordinates both force types RR and RF only appear in the global coordinate system in the dat file for the BOUNDARY nodes. I don’t know why that happens, but it is consistent for both force types RR and RF. Hence this behaviour does not seem to be related to your development.
Thank you!
Thank you! Did you encounter a crash?
The .frd output is valid for the non-expanded elements (like C3D20).The expanded cases (beams, shells) report more forces than they should. Could you please collect some beam/shell exaples to debug this issue?
Yes, the RF external forces were always in global coordinates even on transformed nodes, so that’s good the RR forces are too.
I’ve come to the conclusion that my current knowledge of the inner workings of CalculiX and FEM
programming is not enough to achieve the goal.
The current state:
RR is RF if DOF is constrained, otherwise 0.
It is sufficient enough for some cases (see added tests), but not for others (gravity example).
The .frd output is wrong for expanded elements (beams, shells).
I’ll keep my PR as a draft, maybe I can finish it someday.
Thank you @johanngil and @vicmw for your help!
Many thanks to @gmb for the development efforts to provide additional force output for ccx. Your work is not lost, but a starting point to continue it in the future maybe by others. I keep the code and the list of changed subroutines as I have a high interest to get the further force measures EF (external forces) implemented in ccx.
Sorry to hear that. It seemed to become unexpectedly complicated in lot of ways. There was certainly value in trying so thanks for your effort.