itaps-parallel removal of

[Mark Miller]

Onkar pointed out to me that he thinks 

the decsion to remove iMeshP_getPartsOnRank from the interface

yesterday makes it impossible for a processor to obtain the part

handle for any part that is both a) remote and b) not a 'neighbor'.

If you look at any of the methods that return part handles, I think

you'll find that they all require that either the associated part is local

or that it is the 'stored with' a 'copy' of an entity.

 

This is bad for a parallel mesh decomposer, for example, which

needs to be able to 'assign' entities to 'any' parts. It will need to

be able to identify parts to 'send' entities to that are neither local

nor neighbors of the 'initial' decomposition. I suppose one could

argue that it could achieve this by sending entities on a 'journey'

through all the part neighbors between the originating and destination

parts. But, that wouldn't be too efficient.

 

So, somehow, processors need to be able to obtain part handles

for any parts in the decomposition. At the same time, Mark M. 

argued that we can't design things in such a way that O(num_parts)

storage is required on any processor -- which is what iMeshP_getPartsOnRank

sort of implies. 

 

Yesterday, I argued that the requirements for iMeshP_PartHandle data

type is that a) it identifies a part that is unique across all
parts/processors

and b) it is creatable without communication, I was thinking *only* in terms

of a processors need to create part handles for parts that are 'local'.

Given the above discussion, I think there is a new requirement and that is

that it is possible for a processor to obtain/create part handles for parts

that are 'distantly' remote WITHOUT communication. Now, I can think

of implementations of iMeshP_PartHandle, that make meeting all these

requirements trivial. But, I think this all means that part handles are
integral

values into which a processor rank and local part index that 'fits' in

the same space as a void* or it is a pointer to some such data.

 

Finally, I think we still need some method like

 

iMeshP_getHandleForPart(int part_number)

 

or some such thing.

 

Mark

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/itaps-parallel/attachments/20080312/f36d2263/attachment.htm>