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

[Nico Schlömer]

> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20151207/c5948383/attachment.html>