Archives now visible from outside ANL
Itaps-parallel archives are now visible from outside ANL, at http://www-unix.mcs.anl.gov/web-mail-archive/lists/itaps-parallel/maillist.h.... - tim -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
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. - A discussion of parts versus processors. In my experience, it is easier for both application and tool developer to deal with only parts/partitions as much as possible, rather than present both parts and processors. Clearly some mapping is needed, but I think it is good to have operations defined as much as possible on parts and partitions only. Both Carl and Onkar alluded to this idea as well in their separate processor and ProcPart layers. So we will discuss whether we should tie "global" operations to a partition rather than an MPI communicator. We may cover this ground in Carl's discussion above; if so we'll move on to.... - Uses that we need to support, and what exactly is a root set? I can think of several uses that we might want to support. The easiest is a single mesh with a single partition of it; in this case, what is in the root set? Is there one root set per part? Or one per processor? Another case is having a single mesh with multiple partitions of it (e.g., crash simulations where the elements are partitioned one way and the surfaces are partitioned differently). Does the root set change? Does our parallel model support multiple "Partition Instances"? Third, suppose we have multiple meshes that are partitioned as if they were one mesh (e.g., a multiphysics simulation where one partition is applied to multiple meshes). What does the root set contain in this case? Would we have a single "Partition Instance" with multiple Mesh Instances? Should the relationship between Partitions and Meshes be strictly hierarchical? Fourth, suppose we have multiple meshes, each with their own partition. Am I making you crazy yet? If we get through these three points in one phone conference, you are permitted to celebrate and break into the trick-or-treat candy early. If there are other hairy, scary, big-picture issues we should discuss, please email them to me. Thanks. Karen
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 -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 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
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
Mark Shephard wrote:
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)?
That is NOT what I'm doing. I have repeatedly said I support both the classification and reverse classification approaches, and in fact have implemented that long ago (a similar concept is used in smoothing, as you know). What I'm trying to do is fit the notion of a partition model into our current interface and data model, so that we don't have to inflict yet another interface on applications. The big question, which I think is getting lost in the details, is whether that's possible and how it compares to a parallel partition-specific interface.
Both Karen and Carl are working hard toward something that should meet all needs, it would be nice to try to let that work!!!
I would like the same consideration to be given to the data model used in ITAPS (interface/entities/tags/sets), which has been around for quite some time now. - tim
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
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
Hi All, Just in case you don't have these memorized yet... the number: 866-213-1863 participant code: 956751 At 11:53 AM 10/30/2007, 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.
participants (4)
-
Devine, Karen D. -
Lori Freitag Diachin -
Mark Shephard -
Tim Tautges