[MOAB-dev] (Un-)Expected behavior of DMMoabOutput

[Gerd Heber]

Vijay, I think this is a showstopper. After all, the GLOBAL_ID
is the only thing that users/applications care about and it'd
be utterly confusing if it is changed behind peoples' back.
For example, in applications where you have to (logically) stitch
multiple meshes together, this would be a non-starter.

G.

-----Original Message-----
From: Vijay S. Mahadevan [mailto:vijay.m at gmail.com] 
Sent: Monday, May 11, 2015 11:52 AM
To: Gerd Heber
Cc: MOAB dev
Subject: Re: [MOAB-dev] (Un-)Expected behavior of DMMoabOutput

Oh, I understand your question better now. Yes, this is due to a reordering when DMMoabSetUp is called internally when we load the file. I might be calling assign_global_ids when I load, which might be the cause for renumbering. The original motivation for this was that we had to check if contiguous sequences are available so that we can natively use a MOAB tag for vectors if there is only one sequence. But I think this probably doesn't have to depend on renumbering explicitly (will check if this is an assumption internally).

Is this a problem ? If not, I can update the documentation to explicitly mention this.

Vijay

On Mon, May 11, 2015 at 11:40 AM, Gerd Heber <gheber at hdfgroup.org> wrote:
> Vijay, the problem is not that the GLOBAL_ID tags aren't there.
> The problem is that they don't match between the original and the new 
> file. For example, have a look at the GLOBAL_ID tag for Tet10. In the 
> original file the minimum element ID is 2202 and the maximum is 6229. 
> In the "copied" file it goes from
> 1 to 4028, which tells me that DMMoabOutput generates tags of the 
> right sizes, but reinitializes them rather than copy the original 
> values. Does that make sense?
>
> G.
>
> -----Original Message-----
> From: Vijay S. Mahadevan [mailto:vijay.m at gmail.com]
> Sent: Monday, May 11, 2015 11:12 AM
> To: Gerd Heber
> Cc: MOAB dev
> Subject: Re: [MOAB-dev] (Un-)Expected behavior of DMMoabOutput
>
> Gerd, I'm not sure how you're verifying that the GLOBAL_ID tag is not copied but they are.  Here's my output and they look identical, as they should. The LoadFromFile and Output routines in DM internally just call MOAB functions unless you pass some options and so if you see an issue, we should be able to track this down.
>
> Can you verify if the following commands give similar results from your MOAB installation ?
>
> mahadevan at Tachyon ~/Desktop/moabplay > $MOAB_DIR/bin/mbsize -t no_template_test.h5m File no_template_test.h5m:
>       Tag Name   Vertex      Tet EntitySet
> -------------- -------- -------- ---------
>   MATERIAL_SET        0        0         1
>    NEUMANN_SET        0        0         0
>  DIRICHLET_SET        0        0         0
> GEOM_DIMENSION        0        0         0
>      GLOBAL_ID     6772     4028         0
>           NAME        0        0        25
>       SHAPE_ID        0        0         1
> mahadevan at Tachyon ~/Desktop/moabplay > $MOAB_DIR/bin/mbsize -t no_template_test.out.h5m File no_template_test.out.h5m:
>       Tag Name   Vertex      Tet EntitySet
> -------------- -------- -------- ---------
>   MATERIAL_SET        0        0         1
>    NEUMANN_SET        0        0         0
>  DIRICHLET_SET        0        0         0
> GEOM_DIMENSION        0        0         0
>      GLOBAL_ID     6772     4028         0
>           NAME        0        0        25
>       SHAPE_ID        0        0         1
>
> Vijay
>
> On Mon, May 11, 2015 at 7:46 AM, Gerd Heber <gheber at hdfgroup.org> wrote:
>> This is maybe just a documentation issue, but I find the behavior 
>> somewhat counter-intuitive. The attached program just calls 
>> DMMoabLoadFromFile followed by DMMoabOutput. The in- and output files are attached as well.
>> My expectation was that the output file would be pretty much a copy 
>> of the input file. Not quite. The most notable difference is that the 
>> GLOBAL_ID tags don't get copied. Is that the expected behavior? If 
>> so, what's the reasoning behind not copying the GLOBAL_ID tags?
>>
>> Thanks for your help.
>>
>> G.