I'm trying to verify the code-checks performed in moses.
For the purpose I set up a simple cantilever beam (with the axis along the Z-coordinate), loaded at the free end (axial compression load and lateral load causing bending on the strong axis). The analysis is linear static (disregarding p-delta effects).
The beam is a "french section" HEB300, long 10 m. The failure mechanism is the lateral-torsional buckling, with a length factor (KFAC) equal to 2 (cantilever beam).
In the annexed "cl.zip" file, the configuration files. The two models are expected to produce exactly the same results: in particular
The computed reactions at the restrained end are exact, i.e.
for all the models. So far so good.
In the following table, displacements (due to the lateral load, in the XY plane, i.e. orthogonal to the beam axis) are acceptable. Indeed the results compare well with an independent calculation performed with SAP2000. Anyway I find a difference (not negligible, not justifiable by round-off errors) between the results computed in the two moses models, that should give exactly the same displacement. Please clarify this difference (about 0.6%).
The two moses model should give exactly the same results if comparing the unity checks. Herebelow the results summary.
It is evident that, comparing the unity checks between the two moses models, the results are strongly different.
RP2A on the cly model is 0.79 and on clz is 1.07. The result should be the same. Please clarify.
AISC on the cly model is 0.73 and on clz is 0.17. The result should be the same. In particular 0.17 is surely wrong (SAP2000 gives 0.832). Please clarify.
NORSOK and ISO perform the same check, based on eurocode 3: on the cly model is 0.12 and on clz is 0.15. The result should be the same. Both checks are too low and surely wrong (SAP2000 gives 0.908). Please clarify.
Moses results cite equation H1-2: in AISC the lateral-torsional buckling check is equation H1-3 (For the limit state of out-of-plane buckling and lateral-torsional buckling).
AISC on the cly model is 0.73 and on clz is 0.17. With SAP2000, the unity check is 0.832.
The reference equation cited by moses on the eurocode checks should be 6.62 for both checks (not 6.61 as in "moses cly" model), and seems to be uncorrectly applied. Herebelow the detailed code check performed by SAP2000:
cl.zip
Appreciated for your interest in MOSES and detailed material.
I had a quick review and got to know that the problem stems from a malfunction of that option(HEBY/Z) in the post processing stage. To be specific, the switch in major/minor axis is not being accounted for in the structural post processor whereas it works fine in the structural solver. I`ve reported this to the programmers for the fix.
Best regards,
Bitna
Thank you Bitna,
the bug you reported to the programmers only partially fixes the issues.
There is an outstanding issue: the EUROCODE 3 check gives totally wrong results. Please look carefully at the code check performed with the ISO / NORSOK method. In the example the usage factor computed is 0.12 underestimating the real condition (independent calculations give an usage factor of about 0.9, details in my first post).
Hello Bitna
Bit-na Seo said:No worries, that is also on the list.
Fine.
Bit-na Seo said:As for the small difference in the displacement, by changing the axis with that option, the dimension is changed inside the MOSES. That make the arithmetic order different. We can expect those kind of small difference due to the numeric itself, not round-off.
I'm really doubtful that simply changing the order of operations, if performed with double-precision real arithmetic, can propagate to an error that is 0.6%. As a further prove, if, instead of using the HEBZ300 beam, I simply "rotate" the HEBY300 beam (-CA 90), the displacements are exactly those expected. So, again the problem is due to the ..."Z"... beam.
The correct explanation is the following: MOSES uses the Timoshenko beam theory (i.e. accounts for shear deformations), so also shear areas are relevant for forming the stiffness matrix (and consequently the deformations).
In this case, if the section is not "rotated" properly (like for the HEBZ...), then we get wrong results (due to incorrect structural FEA matrices assemblage on the structural solution phase).
Bit-na Seo said:To be specific, the switch in major/minor axis is not being accounted for in the structural post processor whereas it works fine in the structural solver.
This is not true, as I just explained. This bug has implications also on the structural solver (shear deformation, according to Timoshenko beam theory).
Regards
Ig
You do not need to spend your time on the guess and tries here. We will start our own investigation in the near future. Thank you for bringing this to our attention.
Bit-na Seo said:You do not need to spend your time on the guess and tries here. We will start our own investigation in the near future.
Sorry but I don't agree. Maybe I'm wrong, but in more than 20 years of experience in offshore structural dynamics, we always verify and check the tools before we use them.
It is also a legal issue: at the end of the day, if MY design fails due to a wrong code check, who will be charged guilty? Me or the software house? Obviously, when I sign a project I assume all responsibilities.
The "bugless" code simply does not exist, and in that moses makes no difference. So when I identify a bug, apart from reporting it, I search for a RIGOROUS explanation to it (see the analysis I did about lateral displacements), and a possible workaround (instead of using the ...Z... beam I can use the ...Y... beam with 90 degrees rotation and performing a code check with AISC instead of eurocode - with manual eurocode checks on specific members).
Reporting, isolation and workaround are obviously to be performed until we get a fix from the software house. If we don't do that procedure, should we suspend all design work waiting for a bugfix?
Apart of that, I can tell you that more often we are getting requests to perform our code checks according to the Eurocode 3, and in particular adhering to specific "national annexes". In particular it would be great if at least the gammaM0 and gammaM1 factors could be set for moses unity checks (also other parameters in Eurocode 3 are susceptible to variation - see below, but these two are fundamental).
Hello Mr. Ig,
I would like to start by stating that communication is an art. This thread has involved communication across time-zones, languages, and cultures.
There has been a misunderstanding. Bitna's last communication was stating that you have provided sufficient information for Bentley to classify this as a defect and we start working towards a fix. The tone in his message is friendly Maybe you were expecting a serious tone.
We take your report very seriously.
MOSES has over 400 tests that are run prior to release. As you stated, bugless software does not exist. We are always adding to the test suite. The files we used to investigate your report, along with any other needed files to test a fix, will be added to the test suite.
All members of the MOSES support team have also been engineers. We understand the pressure and the legal issues you reference. We want MOSES to be your tool of choice. We will work toward restoring your confidence in our software.
We are working towards a fix. I hope we can continue to count you as a MOSES user.
Georgina Maldonado
Bentley MOSES User support team
Answer Verified By: the ig
Hello Mr. The Ig,
Let me start by saying the communication is an art. This thread has been communicating across languages, time zones, and cultures. Bitna's response was in a friendly tone. Perhaps you were expecting a serious tone. Thank you for bringing this up to our attention.
We take your reports seriously. The information you have provided was used to develop files for the developers. The developers are aware of this defect and have started the process to provide a fix.
As you said, there is no such thing as defect-free software. As part of the release process there are over 400 files that are run before each release. The files test everything from colors, engineering results, to command sequences. As a result of your report a file will be added to the test suite to test the properties on the HEB beams. The above procedure is done with the intent to reduce defects.
If you have further concerns, please contact me directly via message on this forum or contact me directly via email.
Georgina Maldonado-Aguirre
Manager MOSES AE Software Support