[Gmsh] MeshFormat Version number
Christophe Geuzaine
cgeuzaine at ulg.ac.be
Thu Sep 3 11:54:37 CEST 2009
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