[Gmsh] MeshFormat Version number

[Christophe Geuzaine]

j s wrote:
> Hello,
> 
> It would been far better  to require unique physical id's across 
> dimensions and change the documentation.  The nature of the old mesh 
> format made an implicit requirement that the physical numbers be 
> unique. 

Non, that's incorrect.

> If I had found that small piece of information concerning 
> non-uniqueness of id's a year ago, I would have pointed out the 
> ambiguity then.

The ambiguity only existed for physical *names*, not numerical ids.

> 
> The added complexity is encoding the dimensionality of each element when 
> parsing the file format.  Perhaps you should consider placing the 
> highest order dimensionality as a parameter in the mesh format as well?

Again, nothing prevents you to define *your* physical ids to be unique 
across all dimensions.



> 
> Juan
> 
> On Wed, Sep 2, 2009 at 2:46 PM, Christophe Geuzaine <cgeuzaine at ulg.ac.be 
> <mailto:cgeuzaine at ulg.ac.be>> wrote:
> 
>     j s wrote:
> 
>         My gmsh reader relies on the fact that each physical number is
>         unique across dimensions.  Are you saying this is no longer
>         happening?
>          
> 
> 
>     Hi Juan - Physical entity ids have *never* been unique across
>     dimensions---cf. the documentation. As with elementary entity ids,
>     they must be unique per dimension. (You cannot have Nurbs(1) and
>     Spline(1), but you can have Point(1) and Spline(1). This is deeply
>     rooted in the boundary representation model used by Gmsh.)
> 
>     Of course, nothing prevents you from *choosing* unique physial ids
>     gobally... This was basically what we forced when assigning names
>     instead of numerical ids to physicals in the previous version of the
>     mesh file. This was an oversight, since it could lead to ambigious
>     cases when reading a mesh.
> 
> 
> 
>         This is going to be a few hours effort to change my algorithm,
>         so please help me understand all of the ramifications correctly.
>          I then need to check the dimensionality of each element I am
>         reading in and assign it to a different group according to
>         number and dimension?  Why can't we just use names instead of
>         numbers, and ensure that the names are unique across all
>         dimensionalities?
>          Juan
> 
>         On Wed, Sep 2, 2009 at 7:59 AM, Christophe Geuzaine
>         <cgeuzaine at ulg.ac.be <mailto:cgeuzaine at ulg.ac.be>
>         <mailto:cgeuzaine at ulg.ac.be <mailto:cgeuzaine at ulg.ac.be>>> wrote:
> 
>            Geordie McBain wrote:
> 
>                On Mon, Aug 31, 2009 at 11:07 AM, Rui
>                Maciel<rui.maciel at gmail.com <mailto:rui.maciel at gmail.com>
>         <mailto:rui.maciel at gmail.com <mailto:rui.maciel at gmail.com>>> wrote:
> 
>                    Does anyone know what changed between the previous
>         and the
>                    new file format
>                    version?
> 
> 
>                The motivation,according to doc/VERSIONS.txt is `bumped
>         mesh version
>                format to 2.1
>                (small change in the $PhysicalNames section, where the group
>                dimension
>                is now required)'.
> 
> 
>            Exactly: it's a very small change, only affecting the optional
>            $PhysicalNames/$EndPhysicalNames section.
> 
>            The problem was that with version 2, we did not save a dimension
>            (0D, 1D, 2D or 3D) together with the name. Hence we could not
>            guarantee a one-to-one mapping between physical names and
>         physical
>            numbers. Indeed,  physical numbers need only to be unique per
>            dimension (you can have Physical Point(1) and Physical Line(1)).
> 
> 
> 
> 
> 
>                _______________________________________________
>                gmsh mailing list
>                gmsh at geuz.org <mailto:gmsh at geuz.org>
>         <mailto:gmsh at geuz.org <mailto:gmsh at geuz.org>>
> 
>                http://www.geuz.org/mailman/listinfo/gmsh
> 
> 
> 
> 
>            --    Prof. Christophe Geuzaine
>            University of Liege, Electrical Engineering and Computer Science
>            http://www.montefiore.ulg.ac.be/~geuzaine
>         <http://www.montefiore.ulg.ac.be/%7Egeuzaine>
> 
> 
>            _______________________________________________
>            gmsh mailing list
>            gmsh at geuz.org <mailto:gmsh at geuz.org> <mailto:gmsh at geuz.org
>         <mailto:gmsh at geuz.org>>
> 
>            http://www.geuz.org/mailman/listinfo/gmsh
> 
> 
> 
> 
>     -- 
>     Prof. Christophe Geuzaine
>     University of Liege, Electrical Engineering and Computer Science
>     http://www.montefiore.ulg.ac.be/~geuzaine
>     <http://www.montefiore.ulg.ac.be/%7Egeuzaine>
> 
> 


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