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

Vijay S. Mahadevan vijay.m at gmail.com
Mon Dec 7 17:21:13 CST 2015


The vtk file does not have a GLOBAL_ID point data defined. So MOAB
defaults this to 0 I think for all vertices when you do the
conversion. This isn't quite a bug but just that your input file is
not what MOAB expects, in a sense.

Iulian, can we add an option in mbconvert to assign global ID's ?
Should be a simple call to pcomm->assign_global_ids for all entities,
if the user wants it.

Vijay

On Mon, Dec 7, 2015 at 6:11 PM, Nico Schlömer <nico.schloemer at gmail.com> wrote:
> 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


More information about the moab-dev mailing list