Vertex numbering is dense
 

Hello foamers,

I always wondered what the meaning of

is, when importing a *.msh file into gmsh. Is this an error message? What does ist mean?

Here you can find my complete output:

And as an additional question: Why can't I see my 64 imported vertices in the tree browser tab of the visibility window?

Best regards,

Kate

Hi,

If you look into GModelIO_MSH2.cpp:

I guess what author would like to say is "vertex numbering is contiguous". I.e. there is no gaps in vertex numbering and we can use vector instead of map to store them.

Concerning second question: could you provide example file? Just opened MSH file and all entities were in visibility tree browser. Or should I merge MSH file from GEO file?

Hi Alexey,

Thank you for your answer. Regarding the vertex numbering, that's what I assumed too. Only it looks like some kind of error message in gmsh. I googled for vertex numbering is dense but couldn't find anything useful. How do you search for such a term in the source code? This would be very helpful for the future.

I attached cone.zip to this post which contains my *.stl file which I created in Blender (cone.stl). I opened this file in gmsh and hit save mesh. The cone.msh file is also attached, as well as my test.geo.
When i open the cone.msh file with a text edit app, I can see 64 vertices, which is the same number as the points I can count in Blender. In the gmsh tree browser in the visibility window, I can only see 17 points. Some of these were created in the geo file to define the wind tunnel. Point 1 and 2 are on the cone I guess but why they have that exact position or what they are here for, I never found out. And I can't even find point 5 and 9.
I don't really get the logic how gmsh handles geometry imported as stl. But it's getting better every day.

Best regards and thanks for your help,

Kate

Hi,

I use grep, nothing fancy. So to find the lines from previous post I used:

Since you question was about MSH, I have chosen Geo/GModelIO_MSH2.cpp file.

Well, STL and Gmsh is something special and in fact a little bit beyond my knowledge. Yet, Google helped me to find:

1. It is not enough to call CreateTopology, you need to create compound lines and surfaces. Like in t13.geo from demos.

2. If you use the same procedure as in t13.geo on your cone.stl (or cone.msh) Gmsh finds only 2 vertices.

3. There is "Reclassify 2D" tool in Gmsh GUI. It greatly improves handling of STL (see attached screenshots). Unfortunately it is not accessible through the scripting interface.

Hi Alexey,

Thanks for that very helpful answer.

I have a few questions about this. In which directory do you execute this command? What does daphne mean? Is this possible when running gmsh on OS X too?

Yes, I have played around with this "Reclassify 2D" tool too. Originally my question was aiming at why gmsh handles stl files this way? What is the logic behind it? But thanks anyway!

I have still problems with a default patch which appears after using gmshToFoam. This patch contains some undefined faces which are located at a problematic location of the mesh (cut trailing edge of an airfoil). When I view this default patch in ParaView, the cells seem to be part of my prismatic region. I am not allowed to share my files here but I try to create a minimal example over the weekend.

In the meantime I am trying to understand the gmsh output better:

Everything up to here is clear.

Volume 1 is my extruded prismatic layer. Volume 2 is my farfield from the extruded surface 14 to the boundaries of my wind tunnel. What does
mean then?
What does
mean? Does this mean that there are no volume elements before the 3D meshing? Well, this is obvious, isn't it?

This means that all of my Surface Elements are open. So my assumption is that this is okay?
What are internal rules?
What is blockfill local h?
What is SwapImprove?
At the end I have 242 open elements. I guess these are 2D elements. How does an open 2D element look like?
The meshed than starts tetmeshing with 242 open faces? Doesn't gmsh need to close them first?
I don't understand this peace of code. El stands for element? Can someone explain these lines? Is a smaller volume better?

This looks promising in the first place. But as I wrote already, checkMesh complains about the mesh.

I am aware of this being a huge post with a lot of questions. If you, Alexey, or anyone else could provide some answers, I would be very grateful!
Sadly the gmsh Guide doesn't.

Best regards,

Kate

Hi,

Since the messages are from particular meshing algorithm (guess, they will change if you select different values in Options -> Mesh -> General -> 2D and 3D algorithm drop-downs), it is possible to locate the reason for concrete message in source code, but there is almost no comments in the code ;)

Guess, the easiest way to find meaning of the messages is to use Gmsh mailing list (http://www.geuz.org/mailman/listinfo/gmsh/) and ask authors of software directly.

Hi Alexey,

I've previously posted on the mailing list but sadly I almost never got an answer. However, I'll give it another try.

Can you please answer the first of my questions?

Hi,

Oh, sorry, overlooked these questions.

1. I execute the command in project's root folder. I.e. if I checked out sources in $HOME/Sources/gmsh, I execute command in $HOME/Sources/gmsh. See read-only svn clause in http://www.geuz.org/gmsh/#Download, on how to get project sources.

2. daphne is the host name of my laptop, so it is irrelevant to the problem. 'alexey at daphne in gmsh' is a prompt of my shell, which consists of user name, host name and current folder.

3. Since project sources and OS X compiled binaries are separate entities, you can search source code on any platform you like.