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

Fwd: [hpc-announce] Call For Papers: WOLFHPC12
by Tim Tautges 14 Sep '12

14 Sep '12

Somebody from the iMeshP effort should submit to this if they're still going to SC. Of course, I work at a National Lab, so I'm not in that group going to SC, otherwise I'd do it. - tim -------- Original Message -------- Subject: [hpc-announce] Call For Papers: WOLFHPC12 Date: Fri, 14 Sep 2012 07:49:16 -0700 From: Krishnamoorthy, Sriram <sriram(a)pnnl.gov> To: hpc-announce(a)mcs.anl.gov <hpc-announce(a)mcs.anl.gov> [Apologies if you got multiple copies of this email. If you'd like to opt out of these announcements, information on how to unsubscribe is available at the bottom of this email.] [Apologize for any duplicated posts] CALL FOR PAPERS ================================================================= Second International Workshop on Domain-Specific Languages and High-Level Frameworks for High Performance Computing (WOLFHPC) http://hpc.pnl.gov/conf/wolfhpc/2012 November 16th, 2012, Salt Lake City In conjunction with the 2012 ACM/IEEE Supercomputing Conference (SC'12) ================================================================= WORKSHOP DESCRIPTION -------------------- Multi-level heterogeneous parallelism and deep memory hierarchies in current and emerging computer systems make their programming for high-performance applications very difficult. The task is made more challenging by the changing landscape of system architecture mandated by power and micro-architecture considerations. Domain-specific languages (DSLs) and high-level frameworks (HLFs) provide convenient abstractions, shielding application developers from much of the complexity and variability of explicitly programming in standard programming languages like C/C++/Fortran. Effective design of such abstractions for the high-performance computing context requires close interaction between researchers developing such languages and frameworks and domain experts with a deep understanding of the problem to be solved. While a number of other venues exist that address domain-specific languages and high-level programming abstractions, none of them focus on the challenges to performance optimization and implementation on parallel systems. This workshop seeks to bring together developers and users of DSLs and HLFs to identify challenges and discuss solution approaches for their effective implementation and use on a variety of platforms, including massively parallel systems. We solicit submissions on all aspects relating to domain-specific languages and high-level frameworks for the HPC context, including, but not limited to, the design, implementation, evaluation, or use of: * Application frameworks * Domain-specific languages and libraries * High-level data structures * High-level aspects of programming languages * Directive-based optimization approaches SUBMISSION GUIDELINES --------------------- Extended abstracts should be two or more pages in pdf format and follow IEEE conference formatting guidelines. In addition to new ideas, experience stories, challenges faced, and overview of prior work are encouraged. At least one of the authors of each accepted submission is expected to attend and present at the workshop. The final manuscripts of papers will be made available in IEEExplore as part of SC12 proceedings. The authors of accepted papers will be also invited to submit extended versions of their work to a special issue of the Journal of Parallel and Distributed Computing (JPDC) on High-level Languages and Frameworks for High Performance Computing that is planned for publication in 2013. Submissions can be made online at https://www.easychair.org/conferences/?conf=wolfhpc12 IMPORTANT DATES --------------- Submission deadline : 1 Oct 2012 Author notification : 8 Oct 2012 WOLFHPC workshop : 16 Nov 2012 Final papers due : 26 Nov 2012 WORKSHOP ORGANIZATION --------------------- Sriram Krishnamoorthy, Pacific Northwest National Laboratory J. (Ram) Ramanujam, Louisiana State University P. (Saday) Sadayappan, The Ohio State University PROGRAM COMMITTEE ----------------- Bronis de Supinski, Lawrence Livermore National Lab James Dinan, Argonne National Lab Paul H.J. Kelly, Imperial College London Rishi Khan, ET International Rob Knauerhase, Intel Kamesh Madduri, Penn State University Robert van de Geijn, University of Texas at Austin CONTACT ------- Please contact the program chairs at: wolfhpc12(a)easychair.org ******************************************************************************** The hpc-announce mailing list has been setup to have a common mailing list to share information with respect to upcoming HPC related events. You are included in this mailing list based on your participation or interest in a previous HPC conference or other event. The purpose for providing a single mailing list is to allow participants to easily identify such emails, and handle them appropriately. Some options include: 1. If you feel that the number of such emails is too many, filter them to less-frequently-read folders in your email client. 2. Change your subscription to a digest option (https://lists.mcs.anl.gov/mailman/listinfo/hpc-announce) which will consolidate emails sent that week into a single summary email. 3. Finally, if you do not wish to receive any emails from hpc-announce, you can unsubscribe from the mailing list (https://lists.mcs.anl.gov/mailman/listinfo/hpc-announce) Once unsubscribed, we guarantee that you will not be added back in through participation in a different HPC related conference or event. You will need to send an email to hpc-announce-owner(a)mcs.anl.gov to be added back on. If you need help with any of the above, please email us at hpc-announce-owner(a)mcs.anl.gov. ********************************************************************************

1 0

Re: itaps-parallel Proposal for Requiring Save/Restore of Sets and Tags
by Carl Ollivier-Gooch 21 Oct '10

21 Oct '10

On 10/21/2010 12:35 PM, Jason Kraftcheck wrote: > On 10/21/2010 02:10 PM, Carl Ollivier-Gooch wrote: >> On 10/21/2010 11:45 AM, Jason Kraftcheck wrote: >>> On 10/21/2010 01:30 PM, Carl Ollivier-Gooch wrote: >> >>>> The -real- issue is that there are internal checks that should be done >>>> to help API users with debugging. This is why we return errors. Yes, >>>> this is something the compliance tests check for, but that's not why >>>> they're there. >>>> >>> >>> We return errors when things fail. That is an obviously well accepted >>> programming practice. Failure to return an error flag of some kind >>> when an >>> operation fails is a bug (regardless of whether or not one is in a >>> "release" >>> mode.) That is distinct from helping users with debugging, which >>> should be >>> an implementation issue. >> >> But those error returns are precisely the debugging aid to which I >> refer. > > > No, success or failure is not the same as verifying conformance (of the > application) with the iMesh spec. No, it isn't, in that some failures aren't due to violation of the spec. But violations of the spec (including bizarre input) are errors, and if the spec mandates that certain requests aren't legal, those errors should be identified by the implementation (perhaps with user control of the degree of checking for efficiency). >> If the iMesh spec says that an error code should be returned >> when someone tries to iterate over all faces of topology prism, then >> users should get that error code when they make that silly mistake. > > I'm not sure why that would be an error, but anyway keeping with your > example: If moab cannot return a valid result given the input (e.g. because > the spec specifically prohibits us from doing so), that is an error and that > is why we have error codes. If on the other hand the spec did not prohibit > us from satisfying that request we could certainly return the faces of a > prism (or any other region element.) If the spec said that getting the > faces of a prism is not supported but does not mandate that implementations > fail in that case, we could still successfully handle that query. Not > returning an error code in that case would be more of a refusal to do > conformance testing for the application than a failure of MOAB to conform to > the standard. I was referring to the case of requesting an -iterator- over faces that are also prisms. That's pretty clearly a malformed call. Retrieving the faces of a prism is equally clearly not. >> Same >> goes for other behavior the spec says is erroneous. This is different >> than returning failures for internal errors, which, as you say, an >> implementation should also do. >> > > I didn't say anything about internal errors. I've been discussing only > validation of user input. We must return an error code if the user input is > such that the request cannot be satisfied. And the distinction between > those that are due to invalid input vs. implementation limitations vs. those > that are neither but must fail because the standard mandates that they do. In many (most?) cases, the existence of your third case is a matter of definition of invalid input, IMO. (There may be cases I'm not thinking about.) In principle, the standard should describe what constitutes valid input, so things that fail because the standard mandates that they do are by definition invalid input -for- -this- -API-. We have to be careful to avoid definitions that make people point and laugh, of course... the case that Jason thought I was describing above would be one of those. >>> If the implementation is unusable in "testing" mode because it is >>> doing some >>> O(n^2) checking operation then have we really helped the developer? >> >> No. But I don't know that mandate any error checking that's that >> expensive, at least with good implementation. >> > > But this whole thread of discussion started out of the proposal that the > spec mandate that we must do an O(n) check that will result in O(n^2) > behavior. And then got into your and Mark's recommendations about best > practices for how one should implement error checking in libraries and how > if our implementation conformed to those practices we could avoid this whole > issue by conforming to the standard only in a "debug" build. Okay, I'll concede that one can construct a graph for which this test would be O(n) --- a graph that can be mapped onto a straight line. And for balanced trees, I guess the check is still O(log n), for total complexity of O(n log n). That still isn't great, but it's no worse than the complexity for constructing the tree itself. I will say that this is a fairly strong argument --- at least when combined with the principle that implementations should always check for all error conditions that the spec describes --- in favor of changing the semantics of whatever we end up calling what's currently parent-child relationships. >> Checks for conditions that the iMesh spec says should return an error >> don't fall into the category of implementation choices, > > I certainly agree. Thus the discussion of whether or not this check should > be mandated in the spec. And if it were mandated in the spec, I'd be > somewhat dubious about disabling it for "release" builds, regardless of > whether or not the conformance test checked for it. Good point. >> I suppose not in a practical sense. But in this case, users who are >> developing against your implementation may be doing things that aren't >> supported by other implementations. This is something we should avoid >> wherever we can. >> >> Coming back to the present case, we seem to have two choices: >> >> 1. Keep the present semantics and (to keep interoperability) mandate >> the check. >> > > This isn't keeping interoperability. It is requiring implementations do > interoperability checks for applications. If they want those checks then > they can test with reference implementation. Huh? If the spec says that X must happen, and all implementations but one do that, then an implementation that doesn't isn't interoperable with the others, in the sense that code written to exploit that feature of that implementation fails on the others. As you've all probably gathered, I'm in favor of narrowing down the possibilities of this sort of thing in the API; after all, we're advertising interoperability as a major selling point. >> 2. Change the current semantics, rendering the check irrelevant. If >> we're going to do this, we face the issue of supporting both directed >> and undirected graphs, presumably. Here the interoperability problem >> would be limited to a transition period when we have some >> implementations that don't fully support undirected and/or cyclic >> graphs. I think I could support cyclic directed graphs by removing a >> check. Undirected graphs could be really easy or could require >> significant re-write; I'm not sure without dissecting the code. >> > > 3. Don't mandate that implementations refuse to create cyclic graphs. If this is made interoperable, in the sense of my last paragraph, how does it differ from 2 (leaving aside the directed/undirected issue)? For what it's worth, I can imagine a use case for -undirected- cyclic graphs of sets of entities: lumped partitioning and related tasks. That's two changes in semantics, but we actually get a use case for our trouble this way. 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/ ------------------------------------------------------------------------

2 1

Re: itaps-parallel Proposal for Requiring Save/Restore of Sets and Tags
by Carl Ollivier-Gooch 21 Oct '10

21 Oct '10

On 10/21/2010 11:45 AM, Jason Kraftcheck wrote: > On 10/21/2010 01:30 PM, Carl Ollivier-Gooch wrote: >> The -real- issue is that there are internal checks that should be done >> to help API users with debugging. This is why we return errors. Yes, >> this is something the compliance tests check for, but that's not why >> they're there. >> > > We return errors when things fail. That is an obviously well accepted > programming practice. Failure to return an error flag of some kind when an > operation fails is a bug (regardless of whether or not one is in a "release" > mode.) That is distinct from helping users with debugging, which should be > an implementation issue. But those error returns are precisely the debugging aid to which I refer. If the iMesh spec says that an error code should be returned when someone tries to iterate over all faces of topology prism, then users should get that error code when they make that silly mistake. Same goes for other behavior the spec says is erroneous. This is different than returning failures for internal errors, which, as you say, an implementation should also do. >> And yes, the implementation that's used is practice should be the one >> that's tested. What I'm saying is -specifically- that the -test- can be >> disabled in production mode. By this time, presumably the API user has >> code that is functioning properly and all those tests will pass anyway, >> so they're a waste of time. The only exception, I suppose, would be >> differences in behavior for different input, but those strike me as >> likely to be rare. >> > > If the implementation is unusable in "testing" mode because it is doing some > O(n^2) checking operation then have we really helped the developer? No. But I don't know that mandate any error checking that's that expensive, at least with good implementation. >> I don't know about you, but when I use #ifndef NDEBUG, I -only- put >> things in those blocks that are pure tests with no side effects. The >> code that produces useful results (i.e., the production code) goes >> outside these. > > Is there something you're trying to imply? :) Not at all, but if you think the shoe fits... :-) >> The debug-mode code does a lot of work on the side >> without affecting any output. That's the programming style I think >> makes sense here, too: write production code and decorate it with the >> necessary checks, some or all of which will be disabled in production >> code, without affecting what the production code does. >> > > That's a great coding practice. However, I a) don't think it is appropriate > for this particular case and b) don't see why you consider it part of the > iMesh API rather than an implementation choice that we made. Checks for conditions that the iMesh spec says should return an error don't fall into the category of implementation choices, IMO. You seem to be saying the same thing when you talk about appropriateness for this case. Recognizing that some checks may be expensive (hopefully not n^2!), we've currently given implementations the option of not checking everything in production code. This may be something we need to consider, or at least make a statement like "all tests that are constant time must always be done". This is probably most of them, actually... >> So no, I don't think this is the beginning of a slippery slope. And I >> certainly disagree that there's anything involved that's focused >> specifically at compliance tests. >> > > So if users never enable our "strict conformance" mode and we don't > otherwise test for this does it really matter that the compliance test > checked this and that our implementation passed? I suppose not in a practical sense. But in this case, users who are developing against your implementation may be doing things that aren't supported by other implementations. This is something we should avoid wherever we can. Coming back to the present case, we seem to have two choices: 1. Keep the present semantics and (to keep interoperability) mandate the check. 2. Change the current semantics, rendering the check irrelevant. If we're going to do this, we face the issue of supporting both directed and undirected graphs, presumably. Here the interoperability problem would be limited to a transition period when we have some implementations that don't fully support undirected and/or cyclic graphs. I think I could support cyclic directed graphs by removing a check. Undirected graphs could be really easy or could require significant re-write; I'm not sure without dissecting the code. 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/ ------------------------------------------------------------------------

2 1

Re: itaps-parallel Proposal for Requiring Save/Restore of Sets and Tags
by Jason Kraftcheck 21 Oct '10

21 Oct '10

On 10/21/2010 01:30 PM, Carl Ollivier-Gooch wrote: > > Get off the point of conformance testing, as that's a side issue. > I'm not sure that it is. But I'll try to avoid mentioning it again. > The -real- issue is that there are internal checks that should be done > to help API users with debugging. This is why we return errors. Yes, > this is something the compliance tests check for, but that's not why > they're there. > We return errors when things fail. That is an obviously well accepted programming practice. Failure to return an error flag of some kind when an operation fails is a bug (regardless of whether or not one is in a "release" mode.) That is distinct from helping users with debugging, which should be an implementation issue. > And yes, the implementation that's used is practice should be the one > that's tested. What I'm saying is -specifically- that the -test- can be > disabled in production mode. By this time, presumably the API user has > code that is functioning properly and all those tests will pass anyway, > so they're a waste of time. The only exception, I suppose, would be > differences in behavior for different input, but those strike me as > likely to be rare. > If the implementation is unusable in "testing" mode because it is doing some O(n^2) checking operation then have we really helped the developer? > I don't know about you, but when I use #ifndef NDEBUG, I -only- put > things in those blocks that are pure tests with no side effects. The > code that produces useful results (i.e., the production code) goes > outside these. Is there something you're trying to imply? :) > The debug-mode code does a lot of work on the side > without affecting any output. That's the programming style I think > makes sense here, too: write production code and decorate it with the > necessary checks, some or all of which will be disabled in production > code, without affecting what the production code does. > That's a great coding practice. However, I a) don't think it is appropriate for this particular case and b) don't see why you consider it part of the iMesh API rather than an implementation choice that we made. > So no, I don't think this is the beginning of a slippery slope. And I > certainly disagree that there's anything involved that's focused > specifically at compliance tests. > So if users never enable our "strict conformance" mode and we don't otherwise test for this does it really matter that the compliance test checked this and that our implementation passed? - jason

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

IMeshP Phone conference
by Devine, Karen D 29 Jun '10

29 Jun '10

I'm still trying to schedule the next iMeshP phone conference. We had a NULL set of times that worked for everyone in the last poll. Please vote again with this new poll: http://www.doodle.com/i4dnfh3bcnuvktef Thanks. Karen

1 0