itaps-parallel removal of

[Mark Miller]

Hi All,

I am not sure whether to interpret total silence on these last
two emails from me as either everyone is very busy with SIAM conf. or
maybe they just dropped off people's radar after last week's
bootcamp, or...

However, I've made two pretty fundamental requests here and I'd
like to here what others think of them -- maybe I just just take
the hint ;)

Mark
 
>  
> 
> 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.
> 
>  
> 



> i All,
> 
>  
> 
> On page 16 of Karen's talk made at the ITAPS bootcamp on monday,
> 
> we all agreed on the 'Duplicated information for copies' which was
> 
> - owner of an entity knows part-/entity-handles of all its copies
> 
> - all copies know remote part-/entity-handle of the owned entity
> 
> - all boundary entities know part-/entity-handles of all its copies
> 
>  
> 
> While I can understand that portions of this information are useful
> 
> for various applications that may need to modify the mesh, none
> 
> of it is useful for read-only applications, like a viz. tool. So,
> 
> I'd like to make a pitch to allow applications to indicate to iMesh
> 
> if some or all of this information is needed. In other words, will
> 
> the application even engage in the operations for which we determined
> 
> this information is essential? If not, then why are we going to the
> 
> trouble of storing it? Yes, viz-tools need ghost entities. And, viz-tools
> 
> need the ability to create ghost entities (as well as tag or field
> 
> data defined on those entities). But, viz-tools don't need a concept
> 
> of 'owner' for an entity nor do they need to know where all
> 
> the copies of entities are. Its extra information they don't need.
> 
> Even though its only going to happen on the 'boundaries', its still
> 
> worth NOT storing it if we don't need it.
> 
>  
> 
> Mark

-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)