Validation Program - PrePoMax vs. SAP2000 (shell)

[Josileissu]

Hi, i’m new to PrePoMax, and i’m initialize to study this program with examples.

First of all, i’m drawing an geometry of study on autocad and export two types of files, iges and stl.

For stl, it import as an complete part without separate parts. And it not matter if i set the units of drawing cad is unitless, inches, milimeters, etc. It imports correctly.

For iges, it import with separate parts and i create a compound part. For the drawing cad, it is important to set the unit for milimeters for correct import. When i not seted this, it was set to inches unit and i’ve needed to scale.

On SAP2000 i’m using shell elements to analysis the tension of Von Mises…

For loads and boundary conditions, i’m using two load cases to study, but for comparing i’m only applying the two loads, gravity (-9810 mm/s²) and an force (-1800kg*9,81m/s² → 17658 N). My vertical axis is ‘z’.

The boundary conditions is similarly to sap2000, i’m restrict the displacements 1, 2, 3, of the edges. On PrePoMax, i restricted the same locations, but restricted the surface. Maybe it create an difference situation for analysis.

For results, the displacement for the corner was:
SAP2000 0,4190mm.
PrePoMax 0,4494mm.

It goes well, but the tensions i dont understand…

The local it occurs is different.

Iges_model file: Unique Download Link | WeTransfer
Iges drawing file: Unique Download Link | WeTransfer

[FEAnalyst]

WeTransfer is not good to store the whole posts, especially since it deletes the files after a few days. So I edited your post and pasted everything from that Word document directly here.

Regarding your problem, first of all, I would recommend STEP format whenever possible for import to FEM software. STL is the worst option and only used when there’s no other choice (like working with models from 3D scans).

When it comes to your analysis setup, why is gravity load set to 12.2625 mm/s^2 ? The rest looks good in general. Apart from the mesh - you may have to improve it since it’s rather coarse. Shell elements could help since all parts are thin-walled but you would have to change your CAD model from solids to surfaces.

Of course, to compare the results, you have to make sure everything is set in the same way in both programs. Here the main difference is mesh (that’s also what leads to such discrepancies in most cases) so either refine it in PrePoMax or, better, use shells in this software too, as I’ve mentioned above. There will be a difference in BCs here since shell elements’ nodes have rotational DOFs while solids don’t have them.

[synt]

@Josileissu

The boundary conditions is similarly to sap2000, i’m restrict the displacements 1, 2, 3, of the edges. On PrePoMax, i restricted the same locations, but restricted the surface. Maybe it create an difference situation for analysis.

indeed, it may cause of discrepancy due to additional fixed out of plane rotation at support. Using shell element at both model can give consistency between SAP2000 and CalculiX, mesh conversion needed but some problem may occur for triangular shell since SAP2000 doing overlaps in last fourth node’s definition, if i’m right. Starting a mesh model is more convenient from GMSH to be imported in SAP2000 as STAAD file by external mesh conversion.

btw, previously i do similar comparison but less complex in model, linear elastic only. Result shown well agreement between CalculiX (S4 and US3) with SAP2000 quad shell element. It may be interesting to extend to plasticity materials and large deformation.

[Josileissu]

Oh, thanks guys. I got what i can do now.
I will studies this and others topics in the future and i will share with you.
Thanks!!

Ah, the value of -12.2625 for gravity is for simulate 1.25DL+1,5PL, so 1,25*9,81 is 12,26… And the correct, in truly, cause the units is -12262,5mm/s². Correct not?

[FEAnalyst]

@Josileissu

1.25DL+1,5PL

What do those parameters (DL and PL) mean ? If it’s actual gravitational acceleration, it should just be 9810 mm/s^2 for the whole model. Unless you want to simulate the loading of x*g (e.g. 3g) acting in any direction (like acceleration in the direction of the motion). I guess the surface traction load represents the weight of some parts not included in the FE model ?

[synt]

gravitational multiplication may work and allowed but may affect another cases, using material unit weight multiplication seems more appropriates in this case. Regarding support in solid model for comparison, maybe it can be comparable using rigid body and reference nodes.

[Josileissu]

Truly, but the most of my combinations and analysis is static and for civil works. Is hard to analysis other situations, like a contact or other simulations…

DL is dead load and PL is permanent load, in Brazil we works with combinations to validated an structure and work with a margin for unexpected situations… Got it?

[Victor]

The location and value of maximum stress is usually pretty useless. Most models have stress singularities so it ends up depending on the mesh. In this case, it looks like it’s at the edge of a rigid constraint which is probably a singularity that would be hidden on the coarser SAP2000 mesh.

Also, you should make a reference model with known low error. If your SAP2000 mesh is too coarse or too shelly, which it looks like it might be, you won’t know which software is more correct. I wouldn’t use a shell mesh as a reference because they’re inherently less correct than solids.

[synt]

as i know, shell element in SAP2000 had advances in material nonlinearity and large deformation over solid element. Also, internal meshing algorithm can generate fully unstructured quad shell element (example below), maybe i can try to reproduce when sketch of problems available. My experiences shown linear quad shell element of SAP2000 still comparable to linear triangular user element US3 of CalculiX. However, these elements type have limitation in linear elastic material and small deformation. Direct comparison between two FE solvers seems not an easy task, since different implementation can exist, but still usable to give insight at least.