In https://github.com/nschloe/meshio/issues/388 ‘[MSH 4.1: nodes have wrong 
tags in some cases](https://github.com/nschloe/meshio/issues/388#)’, it was 
reported that sometimes the nodes weren't tagged monotonically.
My reading of the specification was that this shouldn't happen:

    By default, for non-partitioned, single file meshes, Gmsh will create files 
with a
    continuous ordering of node and element tags, starting at 1.

Is that right?

A simple two-dimensional GEO file, ordering.geo, attached and listed

    SetFactory("OpenCASCADE");
    Rectangle(1) = {0, 0, 0, 1, 0.5, 0};
    Transfinite Curve {1, 2, 3, 4} = 3 Using Progression 1;

was provided that when run to produce 6-node triangles in the GUI didn't tag 
the nodes sequentially in the output MSH 4.1 file whereas it does when run from 
the command line with

   gmsh -2 -order 2 ordering.geo

The 'Transfinite Curve' doesn't affect the phenomenon, but omitting it here 
does increase the number of nodes and elements, so it's handy for keeping the 
output easier to inspect at a glance.

Specifically, in the $Nodes block, the one-dimensional entity blocks have 
deranged tags for the nodes; e.g., lines 30–33 of ordering-gui.msh, generated 
in the GUI, are

1 1 0 3
5
11
12

whereas in ordering-cl.msh, generated from the command line, they are

1 1 0 3
5
6
7

I guess meshio should be rewritten to cope with this, but I thought I'd report 
it here in case it was anomalous and unexpected.

It was originally reported for Gmsh 4.2 and I've reproduced it with the latest 
git master, 4.4.0-git-bea1e5dde.

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

Attachment: ordering-cl.msh
Description: Mesh model

Attachment: ordering-gui.msh
Description: Mesh model

Attachment: ordering.geo
Description: application/vnd.dynageo

_______________________________________________
gmsh mailing list
[email protected]
http://onelab.info/mailman/listinfo/gmsh

Reply via email to