I found some diferences between sum forces from FEMAP and the output oload from nastran. Both check sum of external forces. Both methods give the same answer for the forces but for the moments no. Only if the the chosen point for the moments is 0,0,0,. In nastran I set up large field format.
In the word "FEMAP" document can be seen the diference. For FEMAp the model is "balanced" in moments (My) but for nastran oload no. The are slight diferences in this case. But for the real case the diference are larger
I attached the model. It is a simple model just to verify the oload in the f06. There is a node ID190, where the forces are checked in FEMAP and then in nastran bulk data GRDPNT is set to 190 to have the same forces balance.
After reviewing your model and the results, I'll try to summarize my findings.
Sum forces/moments about basic system origin in both Femap and Nastran: answers agree on CG location and the force/moment summation.
Sum forces/moments about the CG location(via node created using Femap/check/mass properties/mesh), since this is gravity load only,moments should be zero about the CG: Femap MY=zero, Nastran MY= not zero, However, Nastran CG location relative to the previous calculated CG is not zero. However, the MY is correct considering FX * z moment arm.
Conclusion: In Nastran, when using a node location as reference point, the CG location is not identical to the calculation using basic origin, some kind of accuracy issue has crept in. So, there seems to be no issue with Nastran summations, the issue seems to be the CG location has changed slightly when using a reference node vs basic origin.
Just to reinforce:
Z location of CG when reference is basic origin = -1.644929E+04
Create node with z=-1.644929E+04, and use that node as reference, then new CG z location = -9.789106E-04(it should be zero).
You may say this is close, but since the force applied is 2.299176E+05, the moment is -2.250688E+02(not zero)
I will file PR to Nastran Development since I do not understand why the CG location changes between the basic origin reference and the nde location reference.
I also feel the need to comment on some modeling issues that I see in the test model provided. These issues do not really affect this oload resultant issue, but they may affect a real model using these techniques.
1) RBE3 connecting all 6 dof's at the independent nodes. This is not considered good practice, and non-intuitive results are likely. Better practice is to only connect the 3 translation dof's on the independent nodes. Also connecting an RBE3 to every node in the model can result in dense, inefficient matrices to deal with.
2) just from inspection of the property titles etc, it appears the reason for the RBE3's is to distribute various non-structural mass contributions to the model. Since things like paint etc are smeared over the entire model, a better method for accomplishing this would be to use either nonstructural mass on the shell property entries, or possible even better(especially if you need to study effects with/without this extra mass) use nonstructural mass regions which are more flexible and easier to define/change. Nonstructural mass regions can be found in the model info tree under "Connections" and can be easily enabled/disabled to create runs with different mass distributions.
I haven't looked at this as thoroughly as fembrackin, but just by looking at his summary, then every calculation, and/or location specified would need to done in double precision to avoid a discrepancy. For example, he mentioned the CG location of Z= -16449.29, which is single precision and clearly only two decimal places in this format. When he specified a node at that location, then it is clear that double precision was required to specify the precise location in order to hit the exact CG, highlighted by the "error" in the CG location in the fourth decimal place. Based on the size of that "error", at least 14 significant figures were needed to define a node at the exact CG.
I see there a few situations with Femap when things are listed (eg. in the message window), they might only be shown at single precision, even though the internal calcs are double precision. Eg. if you list displacements to the message window, these are shown as single precision. But if global / local modelling is done using enforced displacement, fortunately the displacements are internally transferred by double-precision, but (as you note), the local model must then be analysed using large field format to ensure that the double precision enforced displacements find their way into the Nastran analysis.
regarding the model:
- you are right about the REB3 dof. It was just an example extracted from the real model. I forgot to remove the rotaional dof
- I did not know about this option of non strcutural mass. I will explore it. In fact I have a problem with real model. When I perform modal analysis the solver has problems and the reason is this constranit equations due to the RBE3, that the solver must use. So I will change to this non structural mass. I am new with FEMAP so I have to learn all options
About the problems with moments. Ok The probelm is not the foces/moments calculation but the CG calculation. If I had had more time. I would have been realized about it. I checked just the forces/moments balance and I realized about the difference because I was expecting "balanced" model in moments. In fact in the real model , also the forces are slightly different comparing with FEMAP.
Everything in nastran it is done with large format
Hello again fembrackin,
Is there any news from Nastran developer about this issue with Oload when you change the location of the evaluation.
It is strange that something that is used for many users nobody has realizad about it .