[MOAB-dev] GLOBAL_IDs, building map from moab mesh

[Vijay S. Mahadevan]

Well mbconvert is a static conversion i.e., we do not change any
data/layout or partition information from your source file and we just
propagate it to the target. mbpart is intrusive in this respect and
re-partitioning relies on assigning GLOBAL_ID's for creating the right
partition data.

So yes, the defaults "should" be different. I think the relevant
question is whether we need an extra option for mbconvert ?

On Mon, Dec 7, 2015 at 6:32 PM, Nico Schlömer <nico.schloemer at gmail.com> wrote:
>> maybe we should change the default.
>
> I'd agree to that. It's a little weird that mbconvert and mbpart have
> different defaults right now.
>
> Cheers,
> Nico
>
> On Tue, Dec 8, 2015 at 12:27 AM Grindeanu, Iulian R. <iulian at mcs.anl.gov>
> wrote:
>>
>> OK,
>> this file did not have global ids before
>> "default" for global id is 0, so all global ids are filled with 0
>>
>> maybe we should change the default.
>>
>> We have some methods to assign global ids, if they are not present; maybe
>> it should be part of converting  (actually reading from vtk format?)
>>
>> we need to discuss about this
>>
>> ________________________________
>> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on
>> behalf of Nico Schlömer [nico.schloemer at gmail.com]
>> Sent: Monday, December 07, 2015 5:11 PM
>> To: Vijay S. Mahadevan
>> Cc: moab-dev at mcs.anl.gov
>> Subject: Re: [MOAB-dev] GLOBAL_IDs, building map from moab mesh
>>
>> Nope, not playing around with anything. Simply run
>> ```
>> mbconvert pacman.vtk pacman.h5m
>> ```
>> on [1] and find the GLOBAL_IDs all zeroed out. Can you confirm? If yes,
>> I'll be happy to file a bug.
>>
>> Cheers,
>> Nico
>>
>> [1] http://chunk.io/f/ea2a0f63adf04a2bb57338fe853ab05b
>>
>> On Mon, Dec 7, 2015 at 10:29 PM Vijay S. Mahadevan <vijay.m at gmail.com>
>> wrote:
>>>
>>> Using GLOBAL_ID for finding matching entities is the simplest way to
>>> address your use case.
>>>
>>> > I now bumped into a bug in serial execution. I noticed that the output
>>> > of
>>> > `mbconvert somefile.vtk somefile.h5m` generates GLOBAL_ID list full of
>>> > 0s,
>>> > as opposed to the nice list of 1, 2, 3,... as generated by `mbpart`.
>>> > Apparently you're not supposed to rely on GLOBAL_ID after all? Is there
>>> > a
>>> > better approach that also works in serial?
>>>
>>> This seems fishy. Are you overwriting the GLOBAL_ID or setting it
>>> yourselves in memory ?
>>>
>>> Vijay
>>>
>>> On Mon, Dec 7, 2015 at 4:13 PM, Nico Schlömer <nico.schloemer at gmail.com>
>>> wrote:
>>> > Hi everyone,
>>> >
>>> > To build a map for multi-process meshes, I need to be able to identify
>>> > that
>>> > node N on proc 0 is the same as node M on proc 1. For this, I'm using
>>> > the
>>> > GLOBAL_ID property. I know that this list isn't necessarily contiguous
>>> > or
>>> > 1-based, but that's fine.
>>> >
>>> > I now bumped into a bug in serial execution. I noticed that the output
>>> > of
>>> > `mbconvert somefile.vtk somefile.h5m` generates GLOBAL_ID list full of
>>> > 0s,
>>> > as opposed to the nice list of 1, 2, 3,... as generated by `mbpart`.
>>> > Apparently you're not supposed to rely on GLOBAL_ID after all? Is there
>>> > a
>>> > better approach that also works in serial?
>>> >
>>> > Cheers,
>>> > Nico