[Gmsh] MeshFormat Version number

[j s]

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.  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 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?

Juan

On Wed, Sep 2, 2009 at 2:46 PM, Christophe Geuzaine <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>> 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>> 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>
>>        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>
>>    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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20090902/34be14aa/attachment.html>