When MOAB loads a mesh file, the mesh elements have a certain order in EntityHandle space. I'd like to know how reliable/repeatable this ordering is. (Note I'm asking about the order of handles, not their specific values.) For a given mesh file, what guarantees do I get about the order of EntityHandles... * ...between separate runs of the same program? (i.e. May I assume the order of entity handles will be the same every time MOAB loads a file?) * ...between runs of two different programs using the same MOAB library? (Does the order of entities loaded from a file depend on the program that is calling MOAB?) * ...between runs of two programs using different versions of MOAB? (Does the order of entities depend on changes to MOAB, even if those changes do not affect the specific file reader that loads the mesh?) What I am looking for is a way to consistently refer to "the 1st/2nd/nth tetrahedron" in a given file, preferably without resorting to tags. ~S
In most cases, I think order is conserved. The exception will be if the particular reader changes, but you knew that. Another exception will be comparing order between an application where the mesh is generated vs. where the mesh is read in clean, but your cases didn't really cover that. - tim On 02/09/2011 05:06 PM, Steve Jackson wrote:
When MOAB loads a mesh file, the mesh elements have a certain order in EntityHandle space. I'd like to know how reliable/repeatable this ordering is. (Note I'm asking about the order of handles, not their specific values.)
For a given mesh file, what guarantees do I get about the order of EntityHandles...
* ...between separate runs of the same program? (i.e. May I assume the order of entity handles will be the same every time MOAB loads a file?)
* ...between runs of two different programs using the same MOAB library? (Does the order of entities loaded from a file depend on the program that is calling MOAB?)
* ...between runs of two programs using different versions of MOAB? (Does the order of entities depend on changes to MOAB, even if those changes do not affect the specific file reader that loads the mesh?)
What I am looking for is a way to consistently refer to "the 1st/2nd/nth tetrahedron" in a given file, preferably without resorting to tags. ~S
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
Hello, I still have a question: What about if the mesh is read in parallel? Also, for example mbconvert accepts multiple input files. The order within each input file is preserved, isn't it? Another question: Assume some mesh is already in memory. A load_mesh() command will look for empty sequences for node handles, element handles. The order of element handles will be preserved, I assume (it is the job of the ReadUtilIface class) ----- Original Message -----
In most cases, I think order is conserved. The exception will be if the particular reader changes, but you knew that. Another exception will be comparing order between an application where the mesh is generated vs. where the mesh is read in clean, but your cases didn't really cover that.
- tim
On 02/09/2011 05:06 PM, Steve Jackson wrote:
When MOAB loads a mesh file, the mesh elements have a certain order in EntityHandle space. I'd like to know how reliable/repeatable this ordering is. (Note I'm asking about the order of handles, not their specific values.)
For a given mesh file, what guarantees do I get about the order of EntityHandles...
* ...between separate runs of the same program? (i.e. May I assume the order of entity handles will be the same every time MOAB loads a file?)
* ...between runs of two different programs using the same MOAB library? (Does the order of entities loaded from a file depend on the program that is calling MOAB?)
* ...between runs of two programs using different versions of MOAB? (Does the order of entities depend on changes to MOAB, even if those changes do not affect the specific file reader that loads the mesh?)
What I am looking for is a way to consistently refer to "the 1st/2nd/nth tetrahedron" in a given file, preferably without resorting to tags. ~S
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3
Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
I believe that in most cases, MOAB will append handles on the end of the handle space within each type, though we'll want to confirm with Jason next week. That's one reason why I asked Steve whether one of the sides of the comparison was mesh generation. If in parallel, it'll depend on what's generating the decomposition. Multiple files, the order will be preserved within files. On 02/09/2011 07:33 PM, Iulian Grindeanu wrote:
Hello, I still have a question: What about if the mesh is read in parallel?
Also, for example mbconvert accepts multiple input files. The order within each input file is preserved, isn't it?
Another question: Assume some mesh is already in memory. A load_mesh() command will look for empty sequences for node handles, element handles. The order of element handles will be preserved, I assume (it is the job of the ReadUtilIface class)
I'll have to look this up on what actually is done. - tim
----- Original Message -----
In most cases, I think order is conserved. The exception will be if the particular reader changes, but you knew that. Another exception will be comparing order between an application where the mesh is generated vs. where the mesh is read in clean, but your cases didn't really cover that.
- tim
On 02/09/2011 05:06 PM, Steve Jackson wrote:
When MOAB loads a mesh file, the mesh elements have a certain order in EntityHandle space. I'd like to know how reliable/repeatable this ordering is. (Note I'm asking about the order of handles, not their specific values.)
For a given mesh file, what guarantees do I get about the order of EntityHandles...
* ...between separate runs of the same program? (i.e. May I assume the order of entity handles will be the same every time MOAB loads a file?)
* ...between runs of two different programs using the same MOAB library? (Does the order of entities loaded from a file depend on the program that is calling MOAB?)
* ...between runs of two programs using different versions of MOAB? (Does the order of entities depend on changes to MOAB, even if those changes do not affect the specific file reader that loads the mesh?)
What I am looking for is a way to consistently refer to "the 1st/2nd/nth tetrahedron" in a given file, preferably without resorting to tags. ~S
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3
Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
On 02/09/2011 07:40 PM, Tim Tautges wrote:
I believe that in most cases, MOAB will append handles on the end of the handle space within each type, though we'll want to confirm with Jason next week.
If there are sufficiently large holes in the handle space (e.g. due to deletion) those handles might get re-used instead.
That's one reason why I asked Steve whether one of the sides of the comparison was mesh generation. If in parallel, it'll depend on what's generating the decomposition. Multiple files, the order will be preserved within files.
participants (4)
-
Iulian Grindeanu -
Jason Kraftcheck -
Steve Jackson -
Tim Tautges