cancel
Showing results for 
Search instead for 
Did you mean: 

“meshing strategy” document in Nx.CAE?

Phenom
Phenom

To all,

 

Does anyone know if there is a “meshing strategy” document for Nx.CAE?

Nx is driving me nuts because it can never fully updated the meshes if one changes/corrects the (idealised) geometry.

 

For example is one better off starting with the 2D or 3D meshes?

things like that

 

Thansks in advance

Regards

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)
2 REPLIES

Re: “meshing strategy” document in Nx.CAE?

Valued Contributor
Valued Contributor

I don't know of an official "meshing strategy" document other then the documentation that is in the NX Help file, but the approach I take is to only use geometric components (i.e. faces, edges, bodies, etc.) when building the mesh and not FEM components (i.e. nodes and elements). Using that approach pretty much ensures that the FEM/SIM will update after changes are made to the idealized geometry.

 

Oh, I also don't use any of the Polygon Geometry tools in Advanced Simulation unless I absolutly have to (such as for stitching midsurfaces) as those don't automatically update after the polygon bodies/faces update following changes to the idealized geometry.

Re: “meshing strategy” document in Nx.CAE?

Siemens Phenom Siemens Phenom
Siemens Phenom

I know of  no meshing strategy document. If there was one, I probably would have been asked to provide input to it. There are many ways to mesh geometry and different analysis needs will best be served with different approaches. Such a document would need to account for different analysis needs and approaches. I can see it being a significant task to get a thorough review. In the past I've created documents and workshops related to producing 2D meshes from complex solids such as plastic molded parts and welded plate structures. Sometimes the more you abstract the CAE model, the more challenging it is to create and update the mesh. I'm thinking in terms of starting with 3D CAD and then representing that geometry as 3D free mesh, 3D swept/brick mesh, 2D mesh, or 1D mesh. The further down the abstraction chain you go, the more difficult it is for the individual creating the mesh. Life is easy for the guy doing 3D free meshing. Not so much for the person creating a beam model.

 

You’re indicating a difficulty with updates after geometry changes, so I will give you some background into the update strategy.

 

Polygon Geometry Update

Polygon geometry is not the same as the geometry in the PRT. It is a tessellated version that is much easier to edit in terms of merging faces and collapsing short edges/regions. Initially polygon geometry and CAD geometry has a 1-1 edge and face relationship. After meshing, if you’ve set the Small Feature Tolerance to something greater than 0% of the target element size, it is likely that your polygon geometry and CAD geometry won’t match topologically. So, the software maintains pointers between the existing polygon geometry and CAD geometry. For example if a polygon face is a result of a merge face operation (2 faces become 1), the software retains the knowledge that the polygon face originated from the 2 CAD faces. The software uses this information to manage polygon geometry updates and tries to retain polygon geometry edits where no CAD edits have taken place. You may have noticed during update that polygon geometry is “surgically updated”. This means that polygon faces related to CAD faces that have changed are deleted from their polygon body, and the new faces from the CAD are stitched into the existing polygon body. This procedure limits the amount of re-work that may need to be done in the polygon geometry for meshing or LBC purposes. If a CAD change has no impact on the CAD faces that define the polygon face in the merge face example above, that polygon face will not be affected by the update. However if an adjacent face had a hole punched through it, that face is deleted and the new face with the hole is stitched  into the polygon body.

 

Mesh Update

Meshing is very much an order dependent process. What you do initially sets the stage for downstream operations. So, it is important to retain the order in which meshes were created so that they can be replayed in a similar manner during updates. The software retains the order in which meshes are created and will use that information during updates. However, if you have several meshes on a body and make a geometry change, you may notice that not all of the meshes are flagged for update. If a mesh’s underlying geometry doesn’t change, the mesh isn’t updated. Users tend to not want regions that didn’t change to remesh. That’s fine, but it does mean that during update, certain constraints are imposed on the meshes being updated. Consider this situation.

 

  1. A polygon body is fully 2D meshed with 5 meshes (1-5)
  2. A geometry change causes meshes 1 and 5 to require updates
  3. Meshes 1 and 5 are adjacent to one or more of meshes 2-4
  4. The update will happen in the order that the out of date meshes were created. So, mesh 1 is updated first, followed by mesh 5.
  5. The meshes that don’t update impose constraints on the boundaries of meshes 1 and 5. If mesh 1 is adjacent to mesh 2, mesh 2 will impose its boundary on mesh 1. That’s opposite from a forward create perspective, but since the boundary didn’t change, in theory you should have ended up with the same boundary if mesh 1 updated followed by mesh 2.
  6. If mesh 4 is adjacent to mesh 5, mesh 4’s boundary is imposed on mesh 5, just as it was on forward create
  7. If a mix of 0D, 1D, 2D, and 3D meshes all exist in the same model and perhaps on the same body, then update will proceed beginning to update the lowest to highest dimension

 

Where can the process go astray? Free mapped meshes, mapped meshes and swept meshes. Consider a case where a user defined edge density is controlling a mapped mesh distribution, and the edge on which the user defined edge density is defined was removed by the CAD change. I can see that the update would want to place a different element count on the resulting geometry, thus causing problems for update. Another example is that of swept meshes that are a couple volumes removed from one another. An updated mesh may need to flow into several other meshes that are frozen. However the update may lead to a different mesh distribution on the updated mesh such that it cannot flow into the frozen meshes. Naturally update will fail. To address these situations, the software tries to identify dependencies in mapped and swept meshes so that all dependencies are updated. Initially you may see only 2 meshes needing to be updated due to geometry changes, but during update several more meshes may be added to the update list because they were flagged by the dependency trace. It’s not fool proof though, and sometimes an update will fail.

 

Mesh Connections

This is a huge topic by itself. Mesh connections can be made through sharing of geometric entities (non-manifold faces and edges via mesh mating conditions and edge-edge or edge-face stitching). Connections can be defined with 1D elements. Connections can be defined via boundary conditions like contact and glue. If your using mesh mating, or stitching, then updates of those entities would be considered as part of the polygon geometry update. Mating conditions are updated automatically. Automatic stitch operations are too (these operations produce a "recipe" in the Simulation Navigator). Manual stitch operations are not updated. If one is affected by an update, it will be lost. From a robustness point of view, it is easiest to update the LBCs. There you are not performing geometry operations to connect the meshes, but just relying on geometry on separate bodies to exist before and after an update. On the other hand, a stitch operation has the same requirement as the LBC, plus the stitch operation has to update successfully.

 

For more details, I’d have to consult with our developers, but that is a fairly good view of mesh update from my product management perspective. Could you share with us a typical example where update is not behaving as you’d hoped? Perhaps we can give you guidance for your specific situation. GTAC may also be able to study this with you in more detail.

 

Regards,

Mark

 

 

Mark Lamping

Simulation Product Management

Simulation and Test Solutions

 

Siemens Industry Sector

Siemens Product Lifecycle Management Software Inc.

mark.lamping@siemens.com

www.siemens.com/plm