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

[Vijay S. Mahadevan]

Gerd,

If I comment out the following call in dmmbutil.cxx:

merr = pcomm->assign_global_ids(dmmoab->fileset,dim,1,true,true,true);MBERRNM(merr);

Both the region and the vertex IDs are preserved. If the call exists,
then obviously renumbering happens. Can you make sure that the
recompilation/linkage was successful ?

I am also working on my feature branch with other fixes and so unsure
if a bug was fixed elsewhere specific to this problem in some of my
changes. I will try on PETSc master next and confirm the behavior.

Vijay

On Thu, May 14, 2015 at 6:15 AM, Gerd Heber <gheber at hdfgroup.org> wrote:
> Vijay, I've commented that line, recompiled, rebuilt the program
> and reran. Looking at the output file, it made no difference, i.e.,
> the problem is still there. What else could I try?
>
> Thanks, G.
>
> -----Original Message-----
> From: Vijay S. Mahadevan [mailto:vijay.m at gmail.com]
> Sent: Monday, May 11, 2015 1:06 PM
> To: Gerd Heber
> Cc: MOAB dev
> Subject: Re: [MOAB-dev] (Un-)Expected behavior of DMMoabOutput
>
> Gerd, in src/dm/impls/moab/dmmbutil.cxx, can you search for the line that calls "assign_global_ids" in DMMoabLoadFromFile, re-run your simulation and see if all other solution parameters are maintained ?
> As I mentioned, this call is not an absolute requirement for the DM setup and so can be removed. But I just want to make sure that this doesn't break anything else.
>
> I can't test this right now since I'm busy with other things. But if commenting out that call fixes your issue, I'll add it to a PR that I'm working on for PETSc. Let me know.
>
> Vijay
>
> On Mon, May 11, 2015 at 1:00 PM, Gerd Heber <gheber at hdfgroup.org> wrote:
>> 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.