<br><div class="gmail_quote">On Thu, Sep 3, 2009 at 4:54 AM, Christophe Geuzaine <span dir="ltr"><<a href="mailto:cgeuzaine@ulg.ac.be">cgeuzaine@ulg.ac.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">j s wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
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. <br>
</blockquote>
<br></div>
Non, that's incorrect.</blockquote><div><br>That is where we disagree. The nature of the Physical Names section in the mesh format made the implicit requirement that the physical id's be different.<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
The ambiguity only existed for physical *names*, not numerical ids.</blockquote><div><br>The ambiguity transcends the whole mesh format. I was under the impression that there was nothing preventing 1d, 2d, and 3d element from existing in the same group.<br>
</div><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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?<br>
</blockquote>
<br></div>
Again, nothing prevents you to define *your* physical ids to be unique across all dimensions.<br></blockquote><div><br>Will the graphical user interface continue to make the physical id's unique across dimensions? Issues, such as loop orientation of elements, make it nearly impossible for me to assign physical id's by hand.<br>
<br>
What is the added benefit of making the physical id's non-unique across dimensions?<br><br>Regards,<br><br>Juan<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Juan<div><div></div><div class="h5"><br>
<br>
On Wed, Sep 2, 2009 at 2:46 PM, Christophe Geuzaine <<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a> <mailto:<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a>>> wrote:<br>
<br>
j s wrote:<br>
<br>
My gmsh reader relies on the fact that each physical number is<br>
unique across dimensions. Are you saying this is no longer<br>
happening?<br>
<br>
<br>
Hi Juan - Physical entity ids have *never* been unique across<br>
dimensions---cf. the documentation. As with elementary entity ids,<br>
they must be unique per dimension. (You cannot have Nurbs(1) and<br>
Spline(1), but you can have Point(1) and Spline(1). This is deeply<br>
rooted in the boundary representation model used by Gmsh.)<br>
<br>
Of course, nothing prevents you from *choosing* unique physial ids<br>
gobally... This was basically what we forced when assigning names<br>
instead of numerical ids to physicals in the previous version of the<br>
mesh file. This was an oversight, since it could lead to ambigious<br>
cases when reading a mesh.<br>
<br>
<br>
<br>
This is going to be a few hours effort to change my algorithm,<br>
so please help me understand all of the ramifications correctly.<br>
I then need to check the dimensionality of each element I am<br>
reading in and assign it to a different group according to<br>
number and dimension? Why can't we just use names instead of<br>
numbers, and ensure that the names are unique across all<br>
dimensionalities?<br>
Juan<br>
<br>
On Wed, Sep 2, 2009 at 7:59 AM, Christophe Geuzaine<br>
<<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a> <mailto:<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a>><br></div></div><div class="im">
<mailto:<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a> <mailto:<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a>>>> wrote:<br>
<br>
Geordie McBain wrote:<br>
<br>
On Mon, Aug 31, 2009 at 11:07 AM, Rui<br>
Maciel<<a href="mailto:rui.maciel@gmail.com" target="_blank">rui.maciel@gmail.com</a> <mailto:<a href="mailto:rui.maciel@gmail.com" target="_blank">rui.maciel@gmail.com</a>><br></div><div class="im">
<mailto:<a href="mailto:rui.maciel@gmail.com" target="_blank">rui.maciel@gmail.com</a> <mailto:<a href="mailto:rui.maciel@gmail.com" target="_blank">rui.maciel@gmail.com</a>>>> wrote:<br>
<br>
Does anyone know what changed between the previous<br>
and the<br>
new file format<br>
version?<br>
<br>
<br>
The motivation,according to doc/VERSIONS.txt is `bumped<br>
mesh version<br>
format to 2.1<br>
(small change in the $PhysicalNames section, where the group<br>
dimension<br>
is now required)'.<br>
<br>
<br>
Exactly: it's a very small change, only affecting the optional<br>
$PhysicalNames/$EndPhysicalNames section.<br>
<br>
The problem was that with version 2, we did not save a dimension<br>
(0D, 1D, 2D or 3D) together with the name. Hence we could not<br>
guarantee a one-to-one mapping between physical names and<br>
physical<br>
numbers. Indeed, physical numbers need only to be unique per<br>
dimension (you can have Physical Point(1) and Physical Line(1)).<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
gmsh mailing list<br>
<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a> <mailto:<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a>><br></div>
<mailto:<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a> <mailto:<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a>>><div class="im"><br>
<br>
<a href="http://www.geuz.org/mailman/listinfo/gmsh" target="_blank">http://www.geuz.org/mailman/listinfo/gmsh</a><br>
<br>
<br>
<br>
<br>
-- Prof. Christophe Geuzaine<br>
University of Liege, Electrical Engineering and Computer Science<br>
<a href="http://www.montefiore.ulg.ac.be/%7Egeuzaine" target="_blank">http://www.montefiore.ulg.ac.be/~geuzaine</a><br></div>
<<a href="http://www.montefiore.ulg.ac.be/%7Egeuzaine" target="_blank">http://www.montefiore.ulg.ac.be/%7Egeuzaine</a>><br>
<br>
<br>
_______________________________________________<br>
gmsh mailing list<br>
<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a> <mailto:<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a>> <mailto:<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a><div class="im">
<br>
<mailto:<a href="mailto:gmsh@geuz.org" target="_blank">gmsh@geuz.org</a>>><br>
<br>
<a href="http://www.geuz.org/mailman/listinfo/gmsh" target="_blank">http://www.geuz.org/mailman/listinfo/gmsh</a><br>
<br>
<br>
<br>
<br>
-- Prof. Christophe Geuzaine<br>
University of Liege, Electrical Engineering and Computer Science<br>
<a href="http://www.montefiore.ulg.ac.be/%7Egeuzaine" target="_blank">http://www.montefiore.ulg.ac.be/~geuzaine</a><br></div>
<<a href="http://www.montefiore.ulg.ac.be/%7Egeuzaine" target="_blank">http://www.montefiore.ulg.ac.be/%7Egeuzaine</a>><br>
<br>
<br>
</blockquote><div><div></div><div class="h5">
<br>
<br>
-- <br>
Prof. Christophe Geuzaine<br>
University of Liege, Electrical Engineering and Computer Science<br>
<a href="http://www.montefiore.ulg.ac.be/%7Egeuzaine" target="_blank">http://www.montefiore.ulg.ac.be/~geuzaine</a><br>
</div></div></blockquote></div><br>