[Gmsh] nonmonotonic tags for nodes

[Christophe Geuzaine]

> On 22 May 2019, at 08:33, Christophe Geuzaine <cgeuzaine at uliege.be> wrote:
> 
> 
> Hi guys,
> 
> Indeed, currently we only renumber nodes and elements (if Mesh.Renumber is set) at the end of the main mesh generation pipeline (Mesh 1, 2, 3). The renumbering is not done when the order of the mesh is changed interactively in the GUI, or when other mesh modifications are performed interactively (refinement, adaptation, ...): the renumbering has to be performed explicitly in those cases.
> 
> We could add the renumbering step for all these operations as well.

PS : this has been merged in master.


> What do you think?
> 
> Christophe
> 
> 
>> On 22 May 2019, at 04:43, G. D. McBain <gdmcbain at protonmail.com> wrote:
>> 
>> In https://github.com/nschloe/meshio/issues/388 ‘MSH 4.1: nodes have wrong tags in some cases’, 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, Swiss-based encrypted email.
>> 
>> 
>> <ordering-cl.msh><ordering-gui.msh><ordering.geo>_______________________________________________
>> gmsh mailing list
>> gmsh at onelab.info
>> http://onelab.info/mailman/listinfo/gmsh
> 
> — 
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science 
> http://www.montefiore.ulg.ac.be/~geuzaine
> 
> 
> 
> 
> _______________________________________________
> gmsh mailing list
> gmsh at onelab.info
> http://onelab.info/mailman/listinfo/gmsh

— 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine