Problem reading old(?) gmsh mesh files

[petroo]

Hello to all,

I am running into problems when reanimating Elmer after about a year of non-usage. Target system is a quad-core Ubuntu 9.04 system. I had an up and running Elmer at the end of 2008 when the same machine was still an Ubuntu 8.10.
The meshes I prepared with gmsh 2.2.5, as show in the first uploaded image, worked at that time.

I fetched the newest version from SVN right today, and it compiled right through. ElmerGUI came up as well, and environment tests all performed as necessary. Compilation was directly done with the OpenMPI compiler suite, in order to utilize the quad-core as before.

But if I load an old gmsh mesh file it produces a completely wrong grid, as shown in the 2nd uploaded image. Even though the Solver seems to run there is no reasonable output.

Has there been a change in gmsh mesh supports, or what else might be going wrong here?

Kind regards,

Peter

[raback]

Hi Peter

Last change was almost exactly one year ago (based on svn history). For example, the numbering of entities was improved when physical groups are not defined (applies to the new format only). These were intended as improvements. Perhaps you could sent the file for inspection. Are you sure that you didn't use some flag to clean the mesh?

-Peter

[petroo]

Hello Peter,

thanks for your very fast response - I had a day on alternative tasks, so I can come back to this topic just now.

Last change was almost exactly one year ago (based on svn history). For example, the numbering of entities was improved when physical groups are not defined (applies to the new format only). These were intended as improvements. ... Are you sure that you didn't use some flag to clean the mesh?

No, I am not sure at all, at least if this might happen unintentionally. What I did (if I recall it correctly): I defined the geometry in gmsh by setting the appropriate corner pooints, defined the edges, areas and volumes, defined the required surfaces (and volumes?) as physical, had gmsh do the 3-d meshing, and finally imported the resulting one by simply opening it in ElmerGUI. There I attributed the boundary conditions to the surfaces/interfaces of interested and started the simulation.

For differently parameterized cases (heat conduction in differently structured walls) I afterwards changed only the thermodynamic conditions in the SIF file and started the simulations anew. This worked flawlessly so far, and I obtained reasonable results for the tested configurations.

But after a distribution upgrade from Ubuntu 8.10 to 9.04 (intending to proceed to 10.04 in due time this year), and fetching the newest SVN version (I compiled the trunk, not the 5.4.1 branch) things would not restart as anticipated.

In the meantime I fetched the newest gmsh version 2.4.2 and will try today to remesh the old points with them and give it another try. I think I'll do this tinkering first before sending you some dysfunctional mess.

Should the cooperation of the newer program variants work as it should I'll post the results in this thread again! Cross your fingers, please!

Kind regards,

Peter

[petroo]

Okay, back again ...

I just created a new "brick stack" mesh, from an old geo file, with gmsh 2.4.2 (geo file attached). The same fubar mesh is displayed in Elmer as previously shown.

After that I completely started a net generation by gmsh anew from scrap (simplest possible tetraeder config, both geo and msh files are attached), with the same visual Elmer output after loading the mesh.

Perhaps you can take a look at this?

Kind regards,

Peter

[raback]

Hi

I had no problems in the four-tet-mesh you attached. However, there seems to have been a update in Gmsh format in version 2.4.0 in Aug 2009. Quotation from gmsh pages: "bumped mesh version format to 2.1 (small change in the $PhysicalNames section, where the group dimension is now required);" Now version 2.1 is treated as version 2 (I assumed the version to be an integer when the choices where just 1 or 2). But as I understand you have problems even without the physical names?

-Peter

[petroo]

Hello Peter,

as I said: I tested both old gmsh meshes (from a 2.2.x version) and the new mini mesh (created with gmsh 2.4.2), and they both rendered unusable when importing them into Elmer, taken from a freshly compiled trunk version.

After this fussing around with (for me) untraceable content errors I think I'll switch over to the programs distributed as CAE-Linux. I intend to give the Salomé CAD a try whose exports are reported to work with the Elmer version (5.5) that is also included in this distribution.

If you don't read any further whining from me again it works. If not, I'll delight you with yet another error thread ...

Kind regards,

Peter

[raback]

Hi Peter

Ok, looking back on your simple test case it seems that the physical entities are not numbered using all the numbers i.e. 1,2,3,... This seems to create problems later on. Typically the physical entities are numbered intentioanally and therefore their automatic renumbering was removed when visiting the import maybe 2 years ago. The geometric entities are still renumbered as their numbering doesn't make sense to Elmer.

So to take care of this problem you can either skip defining the physical entities in Gmsh, or in ElmerGUI / Configure / elmergrid use the flags "-autoclean" or "-bulkorder" do to the job.

-Peter

[petroo]

Hello @all,

after a lot of tinkering around with different versions of different related programs the conclusion is as follows:

The Elmer DEB package in Ubuntu 9.10 is not broken, but changed with respect to the correct display of meshes, and hence visual mesh interactions are not possible for directly loaded GMSH meshes. Instead, an anteceding call of ElmerGrid is necessary to adapt the meshes for ElmerGUI, and the meshes must be loaded by "File->Load mesh.

Gmsh was, contrary to my former assumption, not the culprit.

Kind regards,

Peter