itaps-parallel Reminder: Phone Conference Wednesday Oct 31 at 9am PDT

[Mark Shephard]

Tim,

A number of the functions you want to through out are quite central to 
doing parallel mesh adaptivity. Just because they are not in iMesh does 
not mean that they are not important in a partition model for dealing 
with parallel operations for a classification based implementation.

Is there some reason why it is so unacceptable to define a partition 
model method that will support both a classification and 
reverse-classification based way of operating?

Would it not make more sense to work toward an iPart that can work for 
both approaches instead of an approach that appears to be, lets throw 
out the thing I do not use (irrespective of the fact that someone else 
does use it and needs it)?

Both Karen and Carl are working hard toward something that should meet 
all needs, it would be nice to try to let that work!!!

Mark

Tim Tautges wrote:
> 
> 
> Devine, Karen D. wrote:
>> Reminder:  We will have a subcommittee phone conference on Wednesday 
>> Oct 31
>> at 9am PDT.  Lori will host using the usual phone numbers.
>>
>> Here is a tentative agenda.  We'll stick to big picture issues, rather 
>> than
>> deal with frightening syntax or ghostly spiritual issues.
>>
>> -  Having just caught up on the email discussions, I have to thank 
>> Carl for
>> doing a great job of putting the discussions into a consistent framework.
>> In the "no good deed goes unpunished" spirit, I'd like Carl to begin the
>> discussions by summarizing his model.  Then I'd like Onkar, Tim and 
>> Vitus to
>> say whether or not Carl's description supports the functionality they 
>> need
>> and whether their subsections of the interface (submitted for draft zero)
>> are, or can be made to be, consistent with that description.
>> HOMEWORK:  Read Carl's latest email and be prepared to say how it fits 
>> with
>> your subsection of draft zero.
>>
> 
> Hairy, scary big-picture issue:
> 
> I'd also like a discussion of the proposal I've put forward, which I've 
> attached (in a format derived from Carl's writeup, hope that helps 
> compare).  This isn't a comment that Carl's description doesn't work, 
> just that IMO it may not be the best way to do it.
> 
> - tim
> 
> 
> ------------------------------------------------------------------------
> 
> Parallel iMesh data model:
> 
>   Machine level: collection of iMesh instances, one per processor,
>      communicating through MPI_COMM_WORLD (default) or other specified
>      communicator (which is a tag on the mesh instance)
>   Processor level: one iMesh instance/processor
>   Partition: set of sets with an application-specified tag (by
>      name or by tag handle)
>   Part: entity set(s) in instance with partition tag specified by
>      application
> 
> iMesh basic interface extension:
>   getEntsByTypeAndTag, getNumEntsByTypeAndTag: get number/entities having
>     designated type, tag, and, optionally, tag value
>   getSetsByTypeAndTag, getNumSetsByTypeAndTag: get number/entity sets having
>     designated type, tag, and, optionally, tag value
> 
> 
> Partition level:
>   . partition representation: 
>     . set which includes part sets
>     . marked with "PartitionSet" tag to identify as partition
>     . optionally contains "MPICommunicator" tag which identifies
>       communicator associated with this partition
>   . available as tag conventions: "ProcAssignment" (part-proc,
>     entity-proc assignment), "PartitionSet" (identifies handle as a
>     partition), "MPICommunicator" (identifies communicator associated
>     with partition handle), "ParGlobalId" (for part ids)
>   . handled by existing iMesh functions: getTotNumOfParts
>     (getNumEntSets), getNumOfPartsArr (getNumEntSets),
>     add/rmvPartOnProc (createEntSet/destroyEntSet), create/destroyPart
>     (createEntSet/destroyEntSet), 
> 
>   . New functionality: 
>     . getEntSetsPar (global part list)
>     . getDataPar (handles part-proc mapping for non-local parts)
>     . getNumEntsPar, getNumEntSetsPar, getNumEntsProcPar,
>       getNumEntSetsProcPar
>     . getTagsPar, getTagsProcPar, get by tag
>     . global reduce on tags
>     . get/setGlobalIDSize
> 
> Processor level:
> 
>   . handled by existing iMesh functions: getNumOfPartsOnProc
>     (getNumSetsByTypeAndTag), getPartsOnProc (getSetsByTypeAndTag),
>     local ID <-> part handle (getSetByTypeAndTag, getData), what
>     partition (
>   . entity-part classification: "PartOwner" tag
>   . not necessary: 
>     . part iterator (don't have a set iterator in iMesh)
>     . iMesh instance/handle (partition functions part of iMesh, no
>       need for separate iPart interface instance)
> 
> Part level:
> 
>   . handled by existing iMesh functions: owned entities (getEntities
>     on Part handles), getNghbPartIds (getChldn-getPrnts from Part handles),
>     part bdry size (getNumChldn on Part handles) 
> 
>   . available as tag conventions: getOwnerOfEnt ("PartOwner"),
>     getCopies/CopyOfEnt ("RemoteHandle"), getNumOfCopiesOfEnt
>     ("NumProcs"), entity categorization ("ProcBdyCategory" =
>     in/out/bdy), what partition ("PartitionClassifications"),
>     get/set/createGlobalID[Arr] ("ParGlobalId")
> 
>   . not necessary:
>     . part bdry iterator (don't have set iterators now in iMesh)
>     . copies of non-owned interpart bdry entities (entities exist in
>       iMesh instance and are not in Part handle)
> 
>   . new functionality:
>     . addCopyOfEnt, rmvCopyOfEnt (i.e. ghosting functions)
>     . disambiguate ownership of shared entity
>     . createGlobalID[Arr]
>     . getEntHandle[Arr] from global ID
> 
>   . convenience functions: 
>     . owned/bdy/ghost entities on Part handle
>