Mesh refinement of edges with gmsh

First of all i wish everybody a happy new year 2024 :boom:

Okay my first feature request of the year is this:

Actually, when applying different refinements to geometries with sharing areas, prepomax can not create a mesh. See the example with sharing nodes at the edges.

Therefore it might be a good idea (if possible) to include additional the refinement possibility from Gmsh for edges: Transfinite → curve. The number of nodes will be entered which also leads to a more controlled refinement.
I think many users would be happy having this feature especially for mapped meshes.

Thanks

2 Likes

Is it possible to share the file for testing?

Sure attached the file.
shaper.zip (23.6 KB)

Also in prepomax the default Transfinite Arrangement for faces seems to be “left”. I think changing it to “Alternated” would fit better in most situations, especially if you compare it to meshes created with femap (see the bottom pictures). Femap uses the same pattern as default for 4 sided faces.

First, thank you for the model.

This was actually a bug :frowning:
I have fixed it and it will be added to the new developer version I am preparing.

In the last developer versions and when using Gmsh the mesh refinement on edges is internally converted to Transfinite curve.

Now, there are two possibilities:

  1. the user interface of the Mesh refinement setup entry must be changed to enable the setting of a number of elements per curve (instead of the size of the elements) and to enable edge only selection in 3D view.
  2. A new mesh setup entry called “Elements per edge” could be added.

That is true. PrePoMax uses Left orientation. I was doing some tests to determine the best option. The problem arises when using Transfinite mesh on compound parts and without recombination (tetra mesh). It happens, that the mesh on the common surface for one compound is oriented differently than for the other compound. The nodes coincide but the element edges do not. So I tried to fix this using the correct orientation but failed to find a solution and I left it to Left.

But now it makes sense to use an alternate orientation to remove the global alignment of the mesh. I will change it and do some tests.

I would prefer an option in Mesh refinement settings to use element number specification instead of element size. That seems to be more intuitive and won’t unnecessarily clutter the interface.

Local seed settings in Abaqus for reference:

local seeds

Actually, an option to specify the number of elements for a given edge is IMO very useful and I’ve mentioned it long time ago but now there might be a good occasion to implement it (possibly for all meshers, not just Gmsh).

Thank you for working on this feature!

Honestly, I wouldn’t care. I thought of a separate menu entry since the existing refinement can now be applied to surfaces and edges at the same time. If you then subsequently switch to “Elements per edge”, this would lead to a conflict with selected surfaces (or the option would then have to be grayed out). Therefore I would suggest to add an additional menu entry “Refinement of edges” where you can choose and switch afterward between element size and elements per edge. Also, a separate entry “Refinement of edges” could then be higher weighted than “Mesh Refinement” to avoid conflicts for sharing (or double selected) edges. So i prefer option 3 :slight_smile:

Unless the edges of those surfaces would have the number of elements prescribed. That’s how it works in Abaqus.

Sorry but there is still an other refining bug:
If you use gmsh as mesher and then select a cylinder edge or surface for refinement, the error occurs:

This can be solved when the surface will be splitted.

Splitted cylinder faces also have the advantage that they are taken into account when using “Transfinite Yes”:

So… it would be nice to have a feature where selected cylider surfaces will be splitted automatically by projecting the existing edge to the opposite. This operation could be based of the “split a face using two points” feature, it just needs to be changed in a way to project the endpoints to the “farthest distance” instead.

2

model for testing
test.zip (18.1 KB)

You are right. Thank you. I have also fixed this bug now.

In the meantime, I have reworked the topology identification from PrePoMax to Gmsh to make it more robust. It is still based on finding the same vertex coordinates but now it works much better.

The problem with the unsplit surface is in the PrePoMax data structure for visualization where such surfaces are recognized as 3-sided instead of 4-sided surfaces (the line connecting both circles should be counted twice). And this will be very hard to change.

Yes, but the current split surface feature uses Netgen and is very hard to manage and upgrade. So I will add such functionality using Gmsh at some stage.

Just that you don’t misunderstand me, i know that gmsh can not transfinite closed cylinder faces, so it would be too much to expect this from prepomax. I know that you are planing a new partitioning system and i guess this will take some time. So i thought it could be a “fast” solution to add a “little” modification to the actual feature, but probably it is not :slight_smile:

Currently any other projectable points can be used so it’s not an important feature:

But again, i thought adding the projection method to “farthest distance” would be a simple option that could also be added when selecting the splitting points:

2

Sorry I don’t want to appear impatient and thank you for the explanations :slight_smile:

I am very happy when someone (like you) properly tests the software and reports them here so I can solve them.

For geometry preparation, I am using Solidworks, and when I import such geometry into PrePoMax, all cylindrical faces are split into 180° patches. So, I usually miss such problems with 360° cylindrical patches. I was unaware that such faces cannot be meshed as transfinite using Gmsh, but I found this out by trying it before you explained it (I have been using Gmsh for a couple of months only).

So, I think a better tool would be to find all cylindrical faces automatically and split all of them in 180° patches. Maybe even at the import of the geometry. Or are there any drawbacks? Maybe the creation of small edges or faces when other geometry is nearby.

I thought Open Cascade does this splitting automatically (since it happens when importing from Solidworks - which modeling software are you using?), but I was wrong and could not find a built-in feature that takes care of that.

Thank you! I cannot contribute much to this great project but at least I can post any bugs.
​

I have exactly the same concerns. Also the automatism could have a negative effect for the needed time for importing the geometry or lead to unexpected results (what if the model has hundreds of holes?). I would prefer a separate feature where you have the chance to decide “select all” or select only the ones you need.

Private for testing i use Salome, at my job I’m using NX for CAD and Salome-Meca for FEM.
NX uses the same modelling kernel as SolidWorks (Parasolid), so I would have expected the same results for the geometric representation. But probably the step translator makes the different, because when i import a step file created with NX to prepomax (salome or freecad), the faces are not splittet. The same applies to models created in salome or freecad - not splitted in prepomax.

May I ask why are you using PrePoMax if you are already using Salome-Meca at work?

I follow this project for personal interest. I use FEM to estimate my designs “on the fly”, I am mainly CAD engineer. I doubt that calculix can be used as respectable tool in the industry from a legal perspective: “This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE”

Did you ever use code aster? When it comes to setting up a simulation, prepomax is so much faster and more intuitive to use, the time advantage is enormous - also the solver is much faster (we are using salome-meca for windows). For example, compared to code aster it is incredibly easy to perform non-linear simulations in calculix.
For me it has become a more practical alternative to salome-meca. But I know that “die-hard” code aster users smile about calculix - but judging that is beyond my competence :slight_smile:

it’s normal condition due to complexity of the software and user competences, anyone also can easily find the disclaimer similarity in many commercial FE even it has ISO 9001 certificates.

or,

1 Like

Yes, now i know it’s a standard formulation from the GNU license

In fact, the 1st order optimization is now active even though this option is set to “None”

Ok, I will take a look at it.

It’s maybe too early for posting bugs for the actual development Version 2.0.3, but Gmsh is no longer working for compounds. No matter which options you chose, always fails with error:

M10x20.zip (45.1 KB)

I have found the problem and now the optimization is turned off by default.