Forum Replies Created
-
Posts
-
You wrote:
“So, we may conclude that, although the implemented finite element has the advantage of avoiding stress concentrations and peaks (which is the case in many situations, for example concentrated loads on shells), if there is some real peak, we must use a refined mesh, with very small size.”Yes, and this is the desired behaviour. The element is linear (4 nodes); results in the middle of the span are quite good, while at fixed supports you have actually only 1 element to represent the transition from positive to negative moment.
Hello,
it seems that the latest version has been compiled with uncompatible runtime libraries. Please check this version out (https://shorturl.at/loEGI), which has simply been recompiled from the original source code against vc2015 libraries.Dear Luciano,
thanks for your inquiry. Despite the theoretic shell behaviour is well-known, numerical applications with shell elements need a lot of care in implementation, because results can vary on the base of adopted mesh, element formulation, and so on.
In particular, we use MIC4 shells for quad elements, which are integrated also along thickness. They have the advantage of avoiding stress concentrations and peaks, which are very unlikely in reality. You’re comparing a theoretical result (peak values, max and min) with an approximate solution – you get such a difference with 10×10 shell model, if you use a 20×20 you get Mmax=7.58 and Mmin=-15.47 (hence you get closer).
Therefore, the way is to use more shells – unlike beams, their results are strongly mesh-dependent.
ps. other solvers (you can try with OpenSees) gives the same results.
ps2. you can get nodes on sides of the shells (to apply BCs) without counting them with
https://nextfem.it/api/html/M_NextFEMapi_API_getNodesOnSides.htmHello,
we’re not responsible for OpenSees development, and by our side it’s all fine (all OpenSees tests are working with 3.6.0). You can revert to the previous version of OpenSees or compile a copy by your own – I suspect an installation issue on your pc.regards
Hello,
I understand you need more decimals in the Model data mask.
By now it’s not possible, but we’ll add it in the next minor patch.
regardsHello,
no, the modelling with solid does not mean to have eccentricity – you’re simply using distorted elements. Yes, hexa should have the same size for each dimensions, but modelling a thin plate with solids is not advised; the best is to stay with shell elements.Hi,
thanks for sharing the model – indeed the eccentricity plays an important role, please note that in the static loadcase you have out-of-plane displacements.
As told, we get the same buckling factors with other solvers (we used CalculiX) – you have to consider that you’re using distorted hexa elements: 1 dimension (thickness) is much shorter that the other 2, hence the elements is not in its ideal condition to work properly.Thanks for your comparisons. We corrected buckling on tria, this will be released in the next patch.
As we use OOFEM as default solver, we forwarded your check request to OOFEM team.ps. please upload one model with solid elements just to see your assumption about restraints and loading; other solvers confirm the correctness of OOFEM approach to solid buckling.
Hello,
please upload your non-working models with shells and a sample with solids at the bottom of the Support page.No, the complete versioning cannot be written in the download page, that page always hosts the latest version. You don’t need to use it to upgrade, simply press Updates / Check for minor updates… in the program!
Hello,
please try version 2.3.0.3; the patch for quad elements has been released. For tria, we’re still getting lower results, we’ll get in deep. For quads, we get a good agreement with results you already have. Always use a proper mesh (at least 5 quads per side).You can also run a parametric analysis automatically with Python in this version, please see the sample at https://github.com/NextFEM/API-Python/blob/main/wall_buckling.py
Hello,
we fixed a bug on quad elements that was causing the low factor you got – we’ll release the fix during this week, hopefully.
Regarding the comparison, results depend also on mesh fineness. We suppose you have the same mesh size and load (20kN) on all models. Another thing that affect results is the element formulation: in the built-in solver, tria elements are built by a membrane and plate, while quad elements have MITC4 formulation, which is generally more reliable.
Before releasing the patch we’ll do a parametric test on shell buckling, we’ll let you know when the update will be available.