Forum Replies Created
-
Posts
-
Hello,
the differences you registered are not related to integration method or extrapolation method, but more generally to the beam formulation the solver uses. In that sense, the result are solver-dependent, and they should be referred to the built-in solver rather than to NextFEM.
In particular, you’re showing the results form OOFEM (the default solver); please refer to their website to get more info on beam formulation and how results are recovered. You can try running the model with OpenSees directly in NextFEM Designer, by changing Solver options.
Finally, by our experience, linear analyses with beams can differ from one solver to another: OOFEM shows little difference with CSI product solvers, while it has good agreement with others. Don’t expect the same stiffness matrix for the same element in all solvers.
In addition, some statistical remarks: you cannot refer the COV (Coefficient of Variation) on null values: your last red row shows a difference that, in absolute terms, is comparable to the other lines.Thanks for it, we’ll solve in the next minor patch (File / Update / Check for minor updates…).
Currently we don’t support initial imperfection as per 1st mode.Can you share your file telling between which nodes you created the link? Can you descrive the operations you do in detail?
Dear Akshay,
to clarify about internal constraints:
– rigid links bounds all degrees of freedom (DoFs), while
– rigid floor involves only x,y and rz.
Looking at your screenshot, the issue you encounter is not clear enough; I believe you should try to directly draw the rigid links by selecting the “Draw link” option in the same mask.Your script does the same thing as Wood-Armer moments do in NextFEM Designer. We already have such kind of checks in paid Concrete module.
Hi, can you send it in this format?
https://github.com/NextFEM/Scripting/blob/main/WoodArmer-elements.nvvDear Luciano,
thank you for the Python script, it has been published here: https://github.com/NextFEM/NextFEMpy/tree/main/samples
best regardsHello,
that’s exactly what I told in my previous reply – you have to assign a planar section (thickness) to shell in order to proceed with analysis. You can find it in Edit / Sections mask.Hello,
sure you can – in Rhino, the hull has to be a simple mesh to be imported correctly via NextFEM-Grasshopper plugin.
Then you can assign thickness from Sections mask, or do a simple parametric design with a few python lines.in Control Panel, open International Settings. In Administration options mask and Non-Unicode program language, click Change system locale setting… and set the language to English.This should not be required anymore since version 2.5.0.3.
Hello,
yes, in Control Panel, open International Settings. In Administration options mask and Non-Unicode program language, click Change system locale setting… and set the language to English.
Then restart the program.Version 2.3 was accounting a reduction factor by means of Eurocode 2 on quasi-permanent combos, which is not actually considered in NTC. Our internal rules prevent us to act on past versions (v2.3 does not receive updates since the end of June), however we understand your needs and we decided, exceptionally, to release a small update for your version. Please check for minor updates from inside the program.
Thanks, we checked element 623 in v2.4 and we confirm there’s no issue. Compared with v.2.3, the current version has been revised for SLS verifications, both for Eurocode and Italian codes.
As a workaround, you could run the checking set “NTC_CA” included for SLS combinations.