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

[Nico Schlömer]

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/2f873417/attachment.html>