[MOAB-dev] Creation of parallel tags

[Jed Brown]

On 2009-02-28, Tim Tautges <tautges at mcs.anl.gov> wrote:
> So, the status of MOAB's parallel stuff in general is dicey right now,
> mostly because I haven't gotten any time to do code stuff.  That's the first
> thing.  The second thing is that iMeshP is an interface developed by
> committee, and in this case, the committee didn't choose to do things with
> sets (even though, IMO, most of it could be done with sets already).  So, if
> you're not planning on switching out MOAB for something else, I'd recommend
> using only iMesh and looking for the right sets and tags to get parallel
> info.

I agree that MOAB's sets model is more natural and I don't have plans
to replace it.  I will look at iMeshP_MOAB.cpp more carefully to see
what what steps I am missing (since AFAIK there are no parallel
examples using iMesh).

Are the parallel tags still supposed to exist by default when
iMesh_load is given the parallel options?  Would it be possible for
them to still exist in a serial run, so as to minimize the number of
places the code needs to check whether it is parallel?  (I haven't
thought about this part carefully, but I think the logic is simpler if
I just find empty sets rather than nonexistant tags.  I wouldn't think
there is any performance hit.)

> iMeshP in theory supports multiple parts per processor with distinct part ids.  I
> believe MOAB is not ready for multiple parts per proc.  If you send the normal
> options to loadall you should get one part per process

Then I must have run into a bug.  iMeshP_loadAll adds the usual
parallel options.  The result is two distinct parts (two distinct part
handles, each containing different entities) but only one part ID.

Jed