July 2010 - itaps-parallel - mailman3.cels.anl.gov

Re: itaps-parallel Two options from today's iMeshP phone conference
by Carl Ollivier-Gooch 19 Jul '10

19 Jul '10

On 10-07-19 08:38 AM, Saurabh Tendulkar wrote: > > > On 07/16/10 20:00, Carl Ollivier-Gooch wrote: >> On 10-07-16 04:21 PM, Devine, Karen D wrote: >>> >>> A. Change the iMesh_createEnt function to include an entity set handle >>> argument PH. For serial applications, PH would be the root set; that is, >>> entities are added only to the root set. For parallel applications, PH >>> would be a part handle; the created entity would be added to the part >>> identified by the part handle. Since iMesh_createEnt is an iMesh >>> function >>> (not an iMeshP function), we would use entity set handle as the argument >>> type, so that serial users would not have to include iMeshP.h nor >>> link with >>> iMeshP. This option was generally accepted by Carl, Simmetrix, Sandia >>> and >>> RPI. Tim is in favor of adding the argument, but does not like the >>> restriction of the handle to be either the root set or a part handle. My >>> fear in allowing arbitrary entity set handles to be used is as >>> follows: if >>> a service uses the entity set handle to, say, add entities to a boundary >>> condition set, that service could not be used in parallel, as its >>> iMesh_createEnt calls would not add the entities to a part. >>> >>> B. Add a new iMeshP function iMeshP_createEnt that takes as input a part >>> handle. Parallel services would need to use iMeshP_createEnt to add >>> entities, include iMeshP.h, and link with an iMeshP library; >>> iMesh_createEnt >>> would return an error. Serial services would continue to use >>> iMesh_createEnt. This option is more explicit than option A, but >>> requires >>> more work on the user's part if the user wants code to work both with >>> and >>> without iMeshP. > > I think for A, we proposed that the argument be NULL in case of serial. > If we want no restriction in iMesh, then maybe we can instead pass an > array of entity sets to iMesh_createEnt, and then in iMeshP stipulate > that one of them has to be a part. In practice, that NULL would have to be the root set handle, since not all implementations use pointers as set handles. >>> One point we didn't discuss but, perhaps, should have was when and how >>> entity ownership should be assigned. The proposed changes add >>> entities to >>> parts, but do not address determining the ownership or copy-status of an >>> entity. I am not sure where these issues should most appropriately be >>> resolved; can they be postponed until iMeshP_syncPartitionAll? >> >> I had assumed that we were talking about setting ownership, since >> that's the >> real sticking point: entities that don't have an owner can't be >> modified (as I >> interpret the current spec). >> >> Carl > > Actually, no, we create different entities (ie. pointers) on different > parts on the part boundary but only one part has the right to modify. > The part is not modifying the entity in the _create function. So we really do have two separate questions here: 1. What part should an entity be stored in, and 2. What part owns the entity. In most cases, these are the same, but entities on part bdrys are different. One way to deal with this would be to specify a part at creation time, with that part being set as owner, then call the (currently non-existent) setOwner function for entities on part bdrys. This latter call would have the advantage of explicitly identifying non-owned copies to the implementation, and could be useful when partitioning or reading a parallel mesh, as well as when modifying one. Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: cfog(a)mech.ubc.ca University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------

1 0

Re: itaps-parallel Two options from today's iMeshP phone conference
by Carl Ollivier-Gooch 19 Jul '10

19 Jul '10

On 10-07-16 04:21 PM, Devine, Karen D wrote: > Today's attendees: Carl, Seegyoung, Misbah, Jason, Tim, Vitus, Karen, Mark > Beall, Saurabh > > In today's iMeshP phone conference, we discussed options that would > associate entities with parts during the entities' creation. This > association is desirable to provide consistency of the data base for > parallel applications and for efficiency in some implementations. And, > indeed, for parallel operations to make sense, entities must belong to some > part. In addition, we'd like to allow serial iMesh services to be applied > to all entities in a part; having a mechanism to add entities to a part > during the creation process allows the serial service to be used. > > We discussed services that one might like to use in serial within a part. > Mesh smoothing was one example; however, because it does not create > entities, it is not relevant to this discussion. Other options, like mesh > generation and edge swapping, need to have some parallel awareness when they > are used in parallel. We envisioned that some serial kernels could be used > under a parallel-aware wrapper for these types of services, provided that > the serial kernels could add entities to the desired part. > > Note that below, I refer to "serial" and "parallel" services. Serial > services are those that do not use iMeshP; they view the root set as the > entire mesh, with no concept of partitions, part boundaries or ghosts. > Parallel services use iMeshP and recognize that the mesh is distributed > across one or more processors. > > We identified two options: > > A. Change the iMesh_createEnt function to include an entity set handle > argument PH. For serial applications, PH would be the root set; that is, > entities are added only to the root set. For parallel applications, PH > would be a part handle; the created entity would be added to the part > identified by the part handle. Since iMesh_createEnt is an iMesh function > (not an iMeshP function), we would use entity set handle as the argument > type, so that serial users would not have to include iMeshP.h nor link with > iMeshP. This option was generally accepted by Carl, Simmetrix, Sandia and > RPI. Tim is in favor of adding the argument, but does not like the > restriction of the handle to be either the root set or a part handle. My > fear in allowing arbitrary entity set handles to be used is as follows: if > a service uses the entity set handle to, say, add entities to a boundary > condition set, that service could not be used in parallel, as its > iMesh_createEnt calls would not add the entities to a part. > > B. Add a new iMeshP function iMeshP_createEnt that takes as input a part > handle. Parallel services would need to use iMeshP_createEnt to add > entities, include iMeshP.h, and link with an iMeshP library; iMesh_createEnt > would return an error. Serial services would continue to use > iMesh_createEnt. This option is more explicit than option A, but requires > more work on the user's part if the user wants code to work both with and > without iMeshP. I think this is a pretty accurate description. > One point we didn't discuss but, perhaps, should have was when and how > entity ownership should be assigned. The proposed changes add entities to > parts, but do not address determining the ownership or copy-status of an > entity. I am not sure where these issues should most appropriately be > resolved; can they be postponed until iMeshP_syncPartitionAll? I had assumed that we were talking about setting ownership, since that's the real sticking point: entities that don't have an owner can't be modified (as I interpret the current spec). Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: cfog(a)mech.ubc.ca University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------

4 13

Two options from today's iMeshP phone conference
by Devine, Karen D 16 Jul '10

16 Jul '10

Today's attendees: Carl, Seegyoung, Misbah, Jason, Tim, Vitus, Karen, Mark Beall, Saurabh In today's iMeshP phone conference, we discussed options that would associate entities with parts during the entities' creation. This association is desirable to provide consistency of the data base for parallel applications and for efficiency in some implementations. And, indeed, for parallel operations to make sense, entities must belong to some part. In addition, we'd like to allow serial iMesh services to be applied to all entities in a part; having a mechanism to add entities to a part during the creation process allows the serial service to be used. We discussed services that one might like to use in serial within a part. Mesh smoothing was one example; however, because it does not create entities, it is not relevant to this discussion. Other options, like mesh generation and edge swapping, need to have some parallel awareness when they are used in parallel. We envisioned that some serial kernels could be used under a parallel-aware wrapper for these types of services, provided that the serial kernels could add entities to the desired part. Note that below, I refer to "serial" and "parallel" services. Serial services are those that do not use iMeshP; they view the root set as the entire mesh, with no concept of partitions, part boundaries or ghosts. Parallel services use iMeshP and recognize that the mesh is distributed across one or more processors. We identified two options: A. Change the iMesh_createEnt function to include an entity set handle argument PH. For serial applications, PH would be the root set; that is, entities are added only to the root set. For parallel applications, PH would be a part handle; the created entity would be added to the part identified by the part handle. Since iMesh_createEnt is an iMesh function (not an iMeshP function), we would use entity set handle as the argument type, so that serial users would not have to include iMeshP.h nor link with iMeshP. This option was generally accepted by Carl, Simmetrix, Sandia and RPI. Tim is in favor of adding the argument, but does not like the restriction of the handle to be either the root set or a part handle. My fear in allowing arbitrary entity set handles to be used is as follows: if a service uses the entity set handle to, say, add entities to a boundary condition set, that service could not be used in parallel, as its iMesh_createEnt calls would not add the entities to a part. B. Add a new iMeshP function iMeshP_createEnt that takes as input a part handle. Parallel services would need to use iMeshP_createEnt to add entities, include iMeshP.h, and link with an iMeshP library; iMesh_createEnt would return an error. Serial services would continue to use iMesh_createEnt. This option is more explicit than option A, but requires more work on the user's part if the user wants code to work both with and without iMeshP. One point we didn't discuss but, perhaps, should have was when and how entity ownership should be assigned. The proposed changes add entities to parts, but do not address determining the ownership or copy-status of an entity. I am not sure where these issues should most appropriately be resolved; can they be postponed until iMeshP_syncPartitionAll? Please email the list if you think I did not get the descriptions correct. Karen

1 0

Reminder: iMeshP phone conference at noon PDT today
by Devine, Karen D 16 Jul '10

16 Jul '10

866-914-3976 The passcode is 662912#

1 0

IMeshP Phone conference
by Devine, Karen D 16 Jul '10

16 Jul '10

Please reserve July 16 at noon PDT for the next iMeshP phone conference. Thanks for voting. Karen

2 1