[MOAB-dev] Errors reading more than 1 mesh file

Robert Smith smithrm at mcs.anl.gov
Fri Apr 9 12:49:08 CDT 2010


I have been having problems testing the Coupler.  It asserts in  
ParallelComm::pack_shared_handles() because the sharedEnts Range from  
the ParallelComm object does not equal the all_shared Range  
constructed in the function.  This Range is constructed by getting all  
entities in the Core via get_entities_by _handle(0, all_shared).  Then  
those entities with PSTATUS tag not set (i.e. not shared) are  
subtracted from the Range.

This all looks reasonable and works no matter how many meshes you read  
in as long as you have the same ParallelComm and Core objects for each  
mesh load.

But in the coupler test it reads 2 mesh files using 1 Core object and  
2 different ParallelComm and ReadParallel pairs of objects as follows:
   for (unsigned int i = 0; i < filenames.size(); i++) {
     pcs[i] = new ParallelComm(mbImpl);
     rps[i] = new ReadParallel(mbImpl, pcs[i]);

     result = rps[i]->load_file(filenames[i], 0,  
FileOptions(opts.c_str()));
     PRINT_LAST_ERROR;
   }

In this scenario, the second ReadParallel::load_file() call fails when  
doing PARALLEL_RESOLVE_SHARED_ENTS.   It calls pack_shared_handles()  
during that operation.  The value of all_shared will have ALL entities  
from BOTH meshes, whereas the sharedEnts range from the ParallelComm  
object and will only have the shared entities for the mesh just read.

My conclusion is either

A - You should not read in multiple meshes in the manner described  
above.

or

B - ParallelComm::pack_shared_handles() should either construct  
all_shared differently to only look at the shared entities associated  
with the mesh(es) read by this ParallelComm or the assertion just  
isn't valid and should be removed.

I've tried removing the assertion and the Coupler seems to work (I'm  
trying to interpret the results).
However I'd like some feedback on this analysis and whether this is  
the fix or is there some deeper problem.

--Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100409/fbe3d635/attachment.htm>


More information about the moab-dev mailing list