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

[Fwd: iMesh_getAdjEntities (yet another proposed iMesh change)]
by Lori A. Diachin 12 Mar '09

12 Mar '09

Here's the second outstanding issue that Jason brought up for discussion. I've also attached the latest iMesh.h and iBase.h to this email from the repository - I believe those are up to date with all the other changes we've agreed to.. Lori -------- Original Message -------- Subject: iMesh_getAdjEntities (yet another proposed iMesh change) Date: Wed, 04 Feb 2009 11:33:26 -0600 From: Jason Kraftcheck <kraftche(a)cae.wisc.edu> To: TSTT Interface <tstt-interface(a)mcs.anl.gov> I think that we should either drop the iMesh_getAdjEntities function entirely, or if not, then remove the 'offset' argument. This function returns entities of the "requested" type, but not the entities of the "requestor" type/topology. For the "offset" information to be useful, one must also have the entities of the "requestor" type/topology in the appropriate order. Presumably to get that list the application must call iMesh_getEntities with the implicit assumption that the order will be correct. But if the application has the ordered "requestor" list, then it could just as easily call iMesh_getEntAdjArr to get the adjacent entities without needing to make any assumptions about functions returning entities in a consistent order. The only case where that might be inefficient is if one wanted something like the list of vertices adjacent to all of the entities in a set but didn't care about the entities. But for this use case, presumably the application would rather have a single list of unique vertex handles and would have no use for the offset list. - jason

2 1

[Fwd: dropping iBase_UNDETERMINED]
by Lori A. Diachin 12 Mar '09

12 Mar '09

Reminder - here's one of the issues we'll be discussing during today's telecon at 12:30 pacific. Lori -------- Original Message -------- Subject: dropping iBase_UNDETERMINED Date: Mon, 16 Feb 2009 10:47:22 -0600 From: Jason Kraftcheck <kraftche(a)cae.wisc.edu> To: TSTT Interface <tstt-interface(a)mcs.anl.gov> I have yet another change proposal for simplifying the iMesh and iGeom interfaces. I think we should remove the "iBase_UNDETERMINED" value from the iBase_StorageOrder enum, and make all storage order arguments "in" rather than "inout" (pass by copy rather than by pointer in C). The feature that making the argument "inout" is intended to facilitate is optimization where the application can allow the implementation to choose the storage order in which it passes back values. The application sets the value to iBase_UNDETERMINED and the implementation sets it to whatever storage order the returned data is in. I think that: a) This feature is unlikely to be used much. b) The optimization is somewhat dubious. c) Making the argument "inout" is not the simplest way to facilitate this feature. d) The API will be easier to use for the vast majority of codes that do not utilize this optimization if the argument is "in". e) The API will be easier to understand. This feature is unlikely to be used much in practice because it requires the application to have two versions of the code that processes the results. There would have to be a clearly demonstrable performance improvement to make it worth writing and maintaining the code to utilize this feature. Given that the implementation must copy the data regardless of the storage order, the performance gained from matching the internal storage order is unlikely to be large, particularly for small numbers of values. Combined with the fact that most applications will either query large numbers of entities infrequently or small numbers of entities frequently, there is unlikely to ever be a justification for coding the application to allow the implementation to determine the storage order. Further, it just isn't necessary for the implementation to pass back its default storage order from every such call. If the application wants to utilize this feature, it can call getDfltStorage once at startup and pass the resulting value into any function that it would have passed in iBase_UNDETERMINED. This change makes the API a little more convenient for the applications that specify a particular storage order. Rather than needing to declare a temporary integer so the storage order can be passed by value, the application may specify the storage order literally as one of its arguments. For example: iMesh_getVtxArrCoords( instance, handles, num_handles, iBase_INTERLEAVED, &coord_arr, &junk1, &junk2, &err ); rather than: int order = iBase_INTERLEAVED; iMesh_getVtxArrCoords( instance, handles, num_handles, &order &coord_arr, &junk1, &junk2, &err ); This change would also make the API easier to understand. I think that if I saw a pass-by-value storage order argument and two possible values for iBase_StorageOrder, the behavior would be clear without the need for any additional documentation. I don't think the same is true with the current API. - jason

1 0

iMesh/iBase Telecon this Thursday
by Lori A. Diachin 10 Mar '09

10 Mar '09

Hi All, As I mentioned in my earlier TODO email, we need to have a telecon this week to finalize any outstanding issues with iMesh.h and iBase.h to allow implementations to get them ready for testing with the services and for eventual release onto the web site (including documentation). I'm proposing Thursday at 12:30-1:30pm pacific (3:30 eastern). I could do it earlier in the day if someone critical absolutely cannot make this time. I view Jason as critical as has some proposals we need to consider and at least one 'responsible' party for each of the implementations and services. The telecon number remains the same - 1-866-914-3976 passcode 662912# Please let me know ASAP if there are serious issues with this time. Thanks, Lori

2 1

TO DO list for ITAPS review
by Lori A. Diachin 06 Mar '09

06 Mar '09

Hi All, My apologies if you get this email more than once from the various email lists - I'm no longer sure who is on which one and want to be sure I have complete coverage (perhaps I could create a new email list called itaps-all :-) ). While on the first leg of my trip home from CSE09 I had plenty of time to devise our schedule of events to prepare for the review. I've included below fairly aggressive timelines for updating/testing our software (note the threatened bootcamp!), writing our review document, updating our web pages, and preparing for the review presentation. I am hopeful that there is not too serious an overlap on writing the review document and the software as both of those activities will take some serious effort over the next 3-4 weeks. Feel free to print this out and post it near your computer so that you can be inspired! Lori TO DO before the review ---------------------------- Software ----------------- Expected Primary Participants: Jason, Vitus, Ting, Onkar, Martin, Mark M, Ryan, Harold, Carl (if possible) Expected Secondary Particpants: Carl, Tim, Lori, Karen, Xiaolin March 10-12 Telecon to finalize iMesh.h for next release March 15 iMesh.h documentation finalized and released March 18 - Telecon to discuss iMesh update progress March 20 - iMesh implementations updated and finalized March 23 - Telecon to discuss services update - March 23 - Decision on Bootcamp necessity March 25 - iMesh implemetnations tested by all; tarballs updated to web page March 26 - Services updated March 30 - Telecon to discuss Services update and testing March 30 - Software web pages updated; documentation of iMesh; services; tutorial April 3 - Services tested by all against implementations April 6-8 - Hold for possible boot camp if remote work doesn't go well April 7 - Services tarballs updated to the web page Review Document ----------------- Expected Primary Participants: Lori, Karen, Mark, Tim, Roman, Xiaolin, Ken, Harold, Ahmed, Carl March 6 Outline distributed to everyone (Lori) March 8 Document repository created March 8 Latex structure in place March 9-10 Telecon to discuss Outline (All) March 10 Collaboration letters drafted and requested of app partners March 13 First draft of all primary materials due (All) March 16 First draft of edited document text (distributed by Lori) March 18 Telecon to discuss document (All) March 18 Draft of review questions answered March 20 Milestones and deliverables Table (All) March 20 Institutional milestones (1 page bulleted list each) March 20 Collaboration letters due to Lori March 23 Final draft of review document distributed March 24 Final feedback due (morning) March 25 Review Document Due (All) Web pages ----------------- Expected Primary Participants: Lori Expected Secondary Partipants: Karen, Mark, Tim, Roman, Xiaolin, Ken, Harold, Ahmed, Carl March 8 First draft of revised web pages based on SciDAC review article March 18 Update of web pages based on proposal material March 18 Update of presentations/publications list March 30 Software web pages updated; documentation of iMesh; services; tutorial Review Presentation --------------------- Expected Primary Participants: Lori, Karen, Mark, Tim, Roman Exptected Secondary Participants: Xiaolin, Ken, Harold, Ahmed, Carl March 25 Review Document Due (All) April 10 First draft of Review slides April 15 Knowledge of reviewers obtained April 17 Revision of review slides April 21 Dry Run in DC (Lori, Mark, Tim, Karen, Roman) April 22 Review in DC (Lori, Mark, Tim, Karen, Roman)

1 0

[Fwd: mailing list archives for ]
by Tim Tautges 02 Feb '09

02 Feb '09

FYI, official statement that mailing list has moved (though the address to send messages to is the same). - tim -------- Original Message -------- Subject: mailing list archives for itaps-parallel Date: Mon, 2 Feb 2009 12:56:52 -0600 (CST) From: root(a)mcs.anl.gov (root) To: tautges(a)mcs.anl.gov Hi, If you're receiving this email, it means that a mailing list that you own (itaps-parallel(a)mcs.anl.gov) has moved from Majordomo to our Mailman list server. Along with the list configuration, we've imported the archives from your list into Mailman's archiver. If your list is configured for web archiving, visit https://lists.mcs.anl.gov/mailman/listinfo/itaps-parallel to find a link to your list's archives. Please update any links to your list's archives to point to this new location. If you have any issues, please let us know at systems(a)mcs.anl.gov. Thanks! Ken Raffenetti MCS Systems -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

1 0

Meeting at SIAM CSE Conf
by Lori A. Diachin 21 Jan '09

21 Jan '09

Hi All, It looks like we will be able to get a smaller meeting room on Wednesday, March 4 at the Hilton (SIAM has all the bigger rooms booked). Pat reminded me that I'm involved in two talks on Wednesday morning, so we will be starting at 12:30 and going until we're done. The primary purpose of this meeting is to prepare for the upcoming review in April and to continue discussions on our plans for the next two year. I envision the following format for the meeting - Attendees: All senior PIs either in person or by telecon; more junior participants as we can fit them into the room - Please let me know if you are planning to attend (I'm guessing 15 attendees, but they can apparently adjust the room slightly if we need more). - Format: Short (15-20 minutes only) presentations from each site highlighting activities to date, major accomplishments and plans; followed by discussions regarding the review and planned activities/collaborations for the remaining two years of ITAPS I have been informed that we will be able to get a speaker phone, but will not have internet access. A projector is available, but expensive - does anyone have a small one that they wouldn't mind bringing to the meeting? A new Starbucks opened up a few blocks up the street. :-) Stay tuned for more information. I am leaning toward preceding this face to face meeting with a short 1 hour telecon in the mid-Feb time frame to ensure that we're all on the same page with what we need to accomplish at this meeting so that we can make the most effective use of our time possible. Also, to follow up on the first action item for the review - if you have not yet sent me your publication lists for the past 2.5 years, please do so by Monday, Jan 26. Thanks, Lori

1 0

Re: itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]
by Ting Xie 20 Jan '09

20 Jan '09

Hi Jason, We still do not know what are indices of adjacent entities in the new proposed function. Thus we make a simple example to demonstrate the problem, and try to clarify what are the inputs and outputs. Please correct me if you find any mistakes. Thanks. The attached is a simple mesh picture of two adjacent hexes. We call iMesh_getAdjEntIndices to get two following requests. 1. To get adjacent edge indices for the hexes INPUT: type=region, topo=hex, adj_type=edge OUTPUT: hex_handles: H1, H2 adj_edge_handles: e1, e2, ..., e12, e1', e2', ..., e12' adj_indices: 1, ..., 12, 1', 2', ..., 12' offset: 0, 12, 24 2. To get adjacent vertex indices for the hexes INPUT: type=region, topo=hex, adj_type=vertex OUTPUT: hex_handles: H1, H2 adj_edge_handles: v1, v2, ..., v8, v1', v2', ..., v8' adj_indices: 1, ..., 8, 1', 2', ..., 8' offset: 0, 8, 16 Since we do not know what are adj_indices. We guess that it has two options: (1) 1,..., 8 (The order of adjacent edges local to the hex, should that start from 0 or 1? If this is the case, we do not have any problem. ) (2) the unique integer ids of the edges in the mesh (If mesh database has dynamic storage because of mesh modification, like FMDB, and it does not store the unique ids for entities, what should return in the adj_indices array? ) Thanks, Ting > Ting Xie wrote: >> Hi all, >> >> Our (RPI team) concerns on the iMesh.h and iBase.h changes are listed as >> follows. Please let us know if you have any questions. Thanks. >> >> >> -------------------------------------------------- >> >> We sort the item number in Jason's proposal in the order of priority. >> The >> function with the higher priority means that we have more confusion and >> it >> might need more effort in the implementation. >> >> >> 1. Item #6 >> >> ------------------------------------------- >> Replace two old functions: >> FUNC_1 iMesh_getAllVtxCoords >> FUNC_2 iMesh_getVtxCoordIndex >> with one new function: >> FUNC_3 iMesh_getAdjEntIndices >> >> ------------------------------------------- >> Functionality of these functions (abstracted from iMesh user-guide and >> Jason's proposal): >> >> * FUNC_1 Gets the coordinates of the vertices contained in the entity >> set >> as an array of doubles in the order specified by the user. >> >> * FUNC_2 Returns the indices of the vertices that define all entities >> of >> a given type or topology in the mesh or entity set. >> >> * FUNC_3 Returns the indices of the adjacent entities of specified >> type, >> for all entities of a given type or topology in the mesh or entity >> set. >> >> ------------------------------------------- >> OUR CONCERNS: >> >> *** 1.1 FUNC_3 does not return the vertex coordinates, i.e., it can >> not >> replace FUNC_1. >> >> To get the coordinates for vertex array returned from FUNC_3, we >> still >> have to call iMesh_getVtxArrCoords function. This was already indicated >> in the example in Jason's proposal. >> >> >>> The same code in the new API will be: >> >>> iMesh_getAdjEntIndices( instance, root_set, ...... >> >>> iMesh_getVtxArrCoords( instance, ..... >> >> >> But iMesh_getVtxCoords can not replace FUNC_1 either. Because it only >> gets the coordinates for an array of vertices, which is not >> entity_set_handle. To get the coordinates of all the vertices in the >> entity_set through iMesh_getVtxCoords, we have to call >> iMesh_getEntities first, which needs extra work (iterate all vertices >> in the entity_set). >> > > Is this a problem? If so, why? > > >> One good thing: if we call iMesh_getVtxArrCoords, and use vertex >> array >> returned from FUNC_3 as the input, the problem size is reduced. >> >> >> *** 1.2 FUNC_3 can return the indices for adjacent entities of any >> type, >> not only verices. >> >> This increases the flexibility of FUNC_3. But do we need that? Does >> the >> adjacency index important for other topological entity type? Or most of >> the time the applications just want to obtain the adjacent entities. If >> that is the case, we can use iMesh_getAdjEntities instead of FUNC_3. >> > > Reducing the functionality by allowing it to only return vertex handles > does > little to reduce the complexity of the API. And it seems unlikely that it > would dramatically reduce the complexity of the implementation. So why > limit the functionality? > > And yes, the original two functions can be removed without adding any new > functions. The same result can be accomplished using other API functions. > However, this type of functionality seems to be expected by some > applications and convenient for others. > > As for an example of using iMesh_getAdjEntIndices to query for a type > other > that vertices, consider writing a file containing elements of type > iMesh_POLYHEDRON. > >> Even if we want to get the adjacency indices, the indicies defined in >> those functions (both old version and new verion) are still not clear. >> Are >> these functions based on the assumption that each mesh entity, >> particular vertex, has an unique integer id. This assumption might not >> be true or right, especially in larger mesh cases. >> > > No such assumption is made. I apologize if you find the documentation > unclear. I reviewed it and could find nothing that I thought indicated > that > IDs were being assigned to vertices, so I'll need some help in correcting > this deficiency. > >> >> *** 1.3 Jason's proposal used a simple hex mesh to claim the >> advantages >> of FUNC_3, but the real applications can be much more complex, >> especially for mixed topological mesh and non-manifold meshes. >> Considering all kinds of situations added from the flexibility, the >> implementation of FUNC_3 will be much more complex. >> > > I do not agree that the common case for using these functions will involve > more complex meshes. But regardless of that, I do not see why > iMesh_getAdjEntIndices (FUNC_3) would need to be any more complex. An > application might also need to call iMesh_getEntArrTopo. Can you provide > examples of the functionality you think this function is missing? > >> >> *** 1.4 Compare the argument lists of FUNC_3 and iMesh_getAdjEntities: >> FUNC_3 returns both entity_handles of requested type/topo and >> adj_entity_handles of specified type, while FUNC_2 does not. >> >> The extra outputs eliminate a lot of unnecessary extra work within >> the >> implementations. But this might be a problem if application does not >> want to get entity_handles and adj_entity_handles info. And the outputs >> will take a lot of memory, especially when the two arrays are huge. >> > > If the application does not want adj_entity_handles, then it should call > iMesh_getEntities instead. If by this you are repeating your concern from > your "1.1" point above, then yes I agree that an additional array of > vertex > handles must be populated. However, I still do not see this as an issue. > While the vertex handle array will be large for a large mesh, it will be > small relative to the other arrays passed back form this function > (coordinates, indices, etc.) And the target applications for this > functionality will not be calling these functions often (e.g. once at > startup.) And there are too many cases where the application will need > the > vertex handles anyway (e.g. tag data, modifying vertex coordinates, etc.) > > If you're concerned about allocating extra arrays, I'd be much more > concerned about the "in_entity_set" arguments. The functions returning > them > probably get called much more frequently and the number of cases where the > application wants the additional data is a much smaller fraction. > Further, > the cost of pupulating it is often much more. The fact that > iMesh_getAllVtxCoords had such an argument and the new functions do not is > in my opinion more than sufficient to offset the cost of creating and > populating the extra vertex handle array. > > >> >> *** 1.5 FUNC_1 and FUNC_2 are coupled together. The coordinate index >> from FUNC_2 depends on the order of the vertex coordinates being >> returned from FUNC_1 (indicated in iMesh user-guide). >> >> One reason to introduce FUNC_3 is to eliminate the coupling. But in >> fact, the index order from FUNC_3 should be consistent with the entity >> order returned from iMesh_getEntities. >> > > Why? > >> >> >> *** 1.6 entity_topologies argument is not provided in FUNC_3, as that >> in >> FUNC_2. >> >> This is a minor problem. And yes, we can use iMesh_getEntArrTopo to >> get >> the info, as Jason mentioned. >> >> --------------------------------------------- >> >> >> 2. Item #4 >> >> It is not clear about what is the definition about vertex geometric >> dimension. >> >> For example, a surface mesh which only has mesh faces, edges and >> vertices, the coordinates of the vertices can have (x, y, z) (curved >> surfaces). In such case, what's right vertex dimension size, 2 or 3? >> > > This has already been defined in the spec for the existing > getGeometricDimension function. And it is implied by the "geometric" part > of the name. The *geometric* dimension of such a mesh is 3. > The topological dimension for the mesh you define is 2. > >> 3. Item #8 >> >> It is not clear about how to replace iBase_EntityHandle with >> iBase_EntitySetHandle where appropriate. >> > > For those functions for which the passed handle is a handle for an entity > set, the type of said argument should be iBase_EntitySetHandle. In some > cases it is incorrectly specified as iBase_EntityHandle. > >> 4. Item #5 >> >> This is a little confused. Yes, the value of the entity_set_handle >> (the pointer itself) is not changed. But the content of the entity_set >> (the value it points to) is changed (because of the remove/add >> operation). >> > > The const-ness of the argument only guarantees that the function will not > change the value of the entity_set_handle (the pointer *if* it is a > pointer.) Specifying it as const or not const does not say anything about > what is done contents of the set. Your misunderstanding is with the C > language, but I'll try to explain it anyway. Let's assume that the > handles > are pointers (as I think that is what FMDB does). If I have this: > typedef void* handle_type; > then this: > const handle_type h; > is equivalent to this: > void* const handle_type h; // the memory address in handle_type cannot > be > // changed > not this: > const void* handle_type h; // the thing pointed to cannot be changed. > > To specify what you want using typedefs in C, it would be necessary to > have > an additional typedef: > typedef const void* const_handle_type; > > However, doing that would be a bad idea for other reasons. The most > important being that it completely contradicts the whole idea of opaque > handles as it only makes sense for pointers. If the handle is an integer > index into some array of entity sets, then there is no use of const that > can > possibly prohibit the modification of the referenced set by the > application. > > If the handle type is opaque, then there just isn't a way to specify that > the set contents cannot change using C syntax. Declaring the arguments in > these functions non-const in a "we wish we could indicate that in C and > are > going to redefine 'const' to mean that" way will just confuse application > developers. The implementation does not change the value of the pointer, > putting const before the argument guarantees this to the application, and > therefore not putting it there implicitly declares an intention to modify > the handle value. > >> >> 5. Item #7 >> >> New function: iMesh_isEntArrContained, raised from Item #6. It is >> an >> array version for iMesh_isEntContained. >> > > And the issue with this is...? > > - jason >

2 1

Re: itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]
by Ting Xie 20 Jan '09

20 Jan '09

Hi all, Our (RPI team) concerns on the iMesh.h and iBase.h changes are listed as follows. Please let us know if you have any questions. Thanks. -------------------------------------------------- We sort the item number in Jason's proposal in the order of priority. The function with the higher priority means that we have more confusion and it might need more effort in the implementation. 1. Item #6 ------------------------------------------- Replace two old functions: FUNC_1 iMesh_getAllVtxCoords FUNC_2 iMesh_getVtxCoordIndex with one new function: FUNC_3 iMesh_getAdjEntIndices ------------------------------------------- Functionality of these functions (abstracted from iMesh user-guide and Jason's proposal): * FUNC_1 Gets the coordinates of the vertices contained in the entity set as an array of doubles in the order specified by the user. * FUNC_2 Returns the indices of the vertices that define all entities of a given type or topology in the mesh or entity set. * FUNC_3 Returns the indices of the adjacent entities of specified type, for all entities of a given type or topology in the mesh or entity set. ------------------------------------------- OUR CONCERNS: *** 1.1 FUNC_3 does not return the vertex coordinates, i.e., it can not replace FUNC_1. To get the coordinates for vertex array returned from FUNC_3, we still have to call iMesh_getVtxArrCoords function. This was already indicated in the example in Jason's proposal. >>> The same code in the new API will be: >>> iMesh_getAdjEntIndices( instance, root_set, ...... >>> iMesh_getVtxArrCoords( instance, ..... But iMesh_getVtxCoords can not replace FUNC_1 either. Because it only gets the coordinates for an array of vertices, which is not entity_set_handle. To get the coordinates of all the vertices in the entity_set through iMesh_getVtxCoords, we have to call iMesh_getEntities first, which needs extra work (iterate all vertices in the entity_set). One good thing: if we call iMesh_getVtxArrCoords, and use vertex array returned from FUNC_3 as the input, the problem size is reduced. *** 1.2 FUNC_3 can return the indices for adjacent entities of any type, not only verices. This increases the flexibility of FUNC_3. But do we need that? Does the adjacency index important for other topological entity type? Or most of the time the applications just want to obtain the adjacent entities. If that is the case, we can use iMesh_getAdjEntities instead of FUNC_3. Even if we want to get the adjacency indices, the indicies defined in those functions (both old version and new verion) are still not clear. Are these functions based on the assumption that each mesh entity, particular vertex, has an unique integer id. This assumption might not be true or right, especially in larger mesh cases. *** 1.3 Jason's proposal used a simple hex mesh to claim the advantages of FUNC_3, but the real applications can be much more complex, especially for mixed topological mesh and non-manifold meshes. Considering all kinds of situations added from the flexibility, the implementation of FUNC_3 will be much more complex. *** 1.4 Compare the argument lists of FUNC_3 and iMesh_getAdjEntities: FUNC_3 returns both entity_handles of requested type/topo and adj_entity_handles of specified type, while FUNC_2 does not. The extra outputs eliminate a lot of unnecessary extra work within the implementations. But this might be a problem if application does not want to get entity_handles and adj_entity_handles info. And the outputs will take a lot of memory, especially when the two arrays are huge. *** 1.5 FUNC_1 and FUNC_2 are coupled together. The coordinate index from FUNC_2 depends on the order of the vertex coordinates being returned from FUNC_1 (indicated in iMesh user-guide). One reason to introduce FUNC_3 is to eliminate the coupling. But in fact, the index order from FUNC_3 should be consistent with the entity order returned from iMesh_getEntities. *** 1.6 entity_topologies argument is not provided in FUNC_3, as that in FUNC_2. This is a minor problem. And yes, we can use iMesh_getEntArrTopo to get the info, as Jason mentioned. --------------------------------------------- 2. Item #4 It is not clear about what is the definition about vertex geometric dimension. For example, a surface mesh which only has mesh faces, edges and vertices, the coordinates of the vertices can have (x, y, z) (curved surfaces). In such case, what's right vertex dimension size, 2 or 3? 3. Item #8 It is not clear about how to replace iBase_EntityHandle with iBase_EntitySetHandle where appropriate. 4. Item #5 This is a little confused. Yes, the value of the entity_set_handle (the pointer itself) is not changed. But the content of the entity_set (the value it points to) is changed (because of the remove/add operation). 5. Item #7 New function: iMesh_isEntArrContained, raised from Item #6. It is an array version for iMesh_isEntContained. 6. Item #1 - #3 Agree without any problem. --------------------------------------------- Ting > Hi All, > > I'd like to check in on the status of everyone's changes wrt to the > iMesh.h and iBase.h files that Jason sent out back in October. We > decided to defer these until after SC08 and gave ourselves an internal > deadline of Dec 15... so, are we done yet? :-) > > Seriously - it was my understanding that folks had agreed in principle > to all of these changes; the one exception was what to do about item #6 > below. It may very well be that we need a quick telecon to discuss > this as well as get an update on status. Carl is planning to send out > the iMesh paper by Jan 23, so we may want to touch base before then.. > when are folks available for a telecon? To narrow it down a bit, please > send me the times you are not available on Monday/Tuesday Jan 12th and > 13th, or Tues/Wed the 20th and 21st. > > Thanks, > Lori > > -------- Original Message -------- > Subject: **** iMesh.h and iBase.h changes **** > Date: Fri, 24 Oct 2008 18:13:11 -0500 > From: Jason Kraftcheck <kraftche(a)cae.wisc.edu> > To: TSTT Interface <tstt-interface(a)mcs.anl.gov> > > > > Here is the list of proposed changes to iMesh.h (yes, not just iMeshP.h) > that were a) agreed upon during the latest telecon and b) may need to be > completed by all implementations by SC'08. If you object to any of this, > please speak out soon. I've attached copies of the interface definitions, > updated as described below. > > > 1) Version defines: Beginning with version 0.8 of iMesh.h, we will add > the > following C preprocessor macros. This will allow, going forward, > applications to be compatible with more than one version of the > interface*. > #define IMESH_MAJOR_VERSION 0 > #define IMESH_MINOR_VERSION 7 > > 2) Zero set handle: All mention of passing 'zero' for a set handle in all > iMesh.h documention should be replaced with the root set handle*. > Implementations for which a) the root set handle is not zero and b) that > actually followed the documentation in that they check for zero rather > than > the root set will need to be updated. > > 3) Handle types*: The current handle definitions: > typedef void* iBase_Instance; > typedef void* iBase_EntityHandle; > typedef void* iBase_EntitySetHandle; > typedef void* iBase_TagHandle; > > typedef void* iMesh_Instance; > typedef void* iMesh_EntityIterator; > typedef void* iMesh_EntityArrIterator; > will be replaced with: > typedef struct iBase_Instance_Private* iBase_Instance; > typedef struct iBase_EntityHandle_Private* iBase_EntityHandle; > typedef struct iBase_EntitySetHandle_Private* iBase_EntitySetHandle; > typedef struct iBase_TagHandle_Private* iBase_TagHandle; > > typedef struct iMesh_Instance_Private* iMesh_Instance; > typedef struct iMesh_EntityIterator_Private* iMesh_EntityIterator; > typedef struct iMesh_EntityArrIterator_Private* iMesh_EntityArrIterator; > > > 4) New Function: > /**\brief Set geometric dimension of vertex coordinates > * > * Set the geometric dimension of the mesh. Notes: An application > * should not expect this function to succeed unless the mesh database > * is empty (no vertices created, no files read, etc.) > *\param instance Mesh database from which to request change. > *\param geom_dim Requested geometric dimension. > */ > void iMesh_setGeometricDimension( iMesh_Intance instance, > /*in*/ int geom_dim, > /*out*/ int* err ); > > > 5) Changed Functions: There are several functions for which an entity set > handle is treated as 'inout' where it should be 'in'*. These include: > iMesh_addEntToSet > iMesh_rmvEntFromSet > iMesh_addEntArrToSet > iMesh_rmvEntArrFromSet > iMesh_addEntSet > iMesh_rmvEntSet > iMesh_addPrntChld > iMesh_rmvPrntChld > The argument shoudl be 'in' because the argument (the value of the > handle) is not changed. > NOTE: The changes described in 3) will ensure that this change results > in compile-time errors. Without the changes in 3), changing the real > type from void** to void* for the arguments would still compile, > which could be disastrous. > > 6) The following two functions: > iMesh_getAllVtxCoords > iMesh_getVtxCoordIndex > will be replaced with the new function below. > NOTE: This is slightly different than what was discussed during > the telecon. I a) noticed a deficiency in the usage (added > the 'entity_handles' output list) and b) dropped the in_entity_set > argument, for which no agreement was reached during the telecon. > > /**\brief Get indexed representation of mesh or subset of mesh > * > * Given an entity set and optionally a type or topology, return: > * - The entities in the set of the specified type or topology > * - The entities adjacent to those entities with a specified > * type, as a list of unique handles. > * - For each entity in the first list, the adjacent entities, > * specified as indices into the second list. > * > *\param entity_set_handle The set of entities from which to query > *\param entity_type_requestor If not iBase_ALL_TYPES, act only on > * the subset of 'entity_set_handle' of the > * specified type. > *\param entity_topology_requestor If not iMesh_ALL_TOPOLOGIES, act > only > * on the subset of 'entity_set_handle' > with > * the specified topology. > *\param entity_type_requested The type of the adjacent entities to > * return. > *\param entity_handles The handles of the (non-struct) subset > of > * the entity set indicated by > * 'entity_set_handle' and the optional > type > * and topology filtering arguments. > *\param adj_entity_handles The union of the entities of type > * 'requested_entity_type' adjacent to each > * entity in 'entity_handles'. > *\param adj_entity_indices For each entity in 'entity_handles', the > * adjacent entities of type > * 'entity_type_requested', specified as > * indices into 'adj_entity_handles'. The > * values are concatenated into a single > * array in the order of the entity handles > * in 'entity_handles'. > *\param offset For each entity in the corresponding > * position in 'entity_handles', the > position > * in 'adj_entity_indices' at which values > * for that entity are stored. > */ > void iMesh_getAdjEntIndices(iMesh_Instance instance, > /*in*/ const iBase_EntityHandle > entity_set_handle, > /*in*/ const int entity_type_requestor, > /*in*/ const int entity_topology_requestor, > /*in*/ const int entity_type_requested, > /*inout*/ iBase_EntityHandle** entity_handles, > /*inout*/ int* entity_handles_allocated, > /*out*/ int* entity_handles_size, > /*inout*/ iBase_EntityHandle** adj_entity_handles, > /*inout*/ int* adj_entity_handles_allocated, > /*out*/ int* adj_entity_handles_size, > /*inout*/ iBsae_EntityHandle** adj_entity_indices, > /*inout*/ int* adj_entity_indices_allocated, > /*out*/ int* adj_entity_indices_size, > /*inout*/ int** offset, > /*inout*/ int* offset_allocated, > /*out*/ int* offset_size, > /*out*/ int *err); > > The code below uses the old interface to retrieve a copy of a hexahedral > mesh in a simple array form: > MBEntityHandle *vertices = 0, *hexes = 0; > int *hex_vertex_indices = 0, *hex_vertex_offsets = 0; > double* coords; > int num_vertices, num_hexes, junk, junk2, junk3, err, order; > int *junk_array; > junk = 0; > iMesh_getEntities( instance, root_set, > iBase_ALL_TYPES, > iMesh_HEXAHEDRON, > &hexes, &junk, &num_hexes, &err ); > junk = 0; > iMesh_getEntities( instance, root_set, > iBase_VERTEX, > iMesh_ALL_TOPOLOGIES, > &vertices, &junk, &num_vertices, &err ); > junk = junk2 = 0; > junk_array = NULL; > order = iBase_INTERLEAVED; > iMesh_getAllVtxCoords( instance, root_set, > &coords, &junk, &junk, > &junk_array, &junk2, &junk2, > &order, &err); > free(junk_array); > junk = junk2 = junk3 = 0; > junk_array = NULL; > iMesh_getVtxCoordIndex( instance, root_set, > iBase_ALL_TYPES, iMesh_HEXAHEDRON, > iBase_VERTEX, > &hex_vertex_offsets, &junk, &junk, > &hex_vertex_indices, &junk2, &junk2, > &junk_array, &junk3, &junk3, > &err ); > free( junk_array ); > > The same code in the new API will be: > MBEntityHandle *vertices = 0, *hexes = 0; > int *hex_vertex_indices = 0, *hex_vertex_offsets = 0; > double* coords; > int num_vertices, num_hexes, junk, junk2, junk3, junk4, err; > int order; > junk = junk2 = junk3 = junk4 = 0; > iMesh_getAdjEntIndices( instance, root_set, > iBase_ALL_TYPES, iMesh_HEXAHEDRON, > iBase_VERTEX, > &hexes, &junk, &num_hexes, > &vertices, &junk2, &num_vertices, > &hex_vertex_indices, &junk3, &junk3, > &hex_vertex_offsets, &junk4, &junk4 ); > junk = 0; > order = iBase_INTERLEAVED; > iMesh_getVtxArrCoords( instance, > vertices, num_vertex, > &order, > &coords, &junk, &junk, > &err ); > > 7) New Function: Array form of iMesh_isEntContained to replace > containment flags no longer returned from iMesh_getVtxCoordIndex > (and hopefully some day all the other functions with a similar > argument). > > void iMesh_isEntArrContained( iMesh_Instance instance, > /*in*/ iBase_EntitySetHandle containing_set, > /*in*/ const iBase_EntityHandle* entity_handles, > /*in*/ int num_entity_handles, > /*inout*/ int** is_contained, > /*inout*/ int* is_contained_allocated, > /*out*/ int* is_contained_size, > /*out*/ int* err ); > > > 8) Replace some iBase_EntityHandle with iBase_EntitySetHandle where > appropriate*: > iMesh_getAdjEntIndices > iMesh_getAdjEntities > > - jason > > > * Similar changes should probably be made to iGeom.h, iMeshP.h, and > iRel.h, > but that was not discussed during the telecon. > > > >

3 2

[Fwd: **** iMesh.h and iBase.h changes ****]
by Lori A. Diachin 20 Jan '09

20 Jan '09

Hi All, I'd like to check in on the status of everyone's changes wrt to the iMesh.h and iBase.h files that Jason sent out back in October. We decided to defer these until after SC08 and gave ourselves an internal deadline of Dec 15... so, are we done yet? :-) Seriously - it was my understanding that folks had agreed in principle to all of these changes; the one exception was what to do about item #6 below. It may very well be that we need a quick telecon to discuss this as well as get an update on status. Carl is planning to send out the iMesh paper by Jan 23, so we may want to touch base before then.. when are folks available for a telecon? To narrow it down a bit, please send me the times you are not available on Monday/Tuesday Jan 12th and 13th, or Tues/Wed the 20th and 21st. Thanks, Lori -------- Original Message -------- Subject: **** iMesh.h and iBase.h changes **** Date: Fri, 24 Oct 2008 18:13:11 -0500 From: Jason Kraftcheck <kraftche(a)cae.wisc.edu> To: TSTT Interface <tstt-interface(a)mcs.anl.gov> Here is the list of proposed changes to iMesh.h (yes, not just iMeshP.h) that were a) agreed upon during the latest telecon and b) may need to be completed by all implementations by SC'08. If you object to any of this, please speak out soon. I've attached copies of the interface definitions, updated as described below. 1) Version defines: Beginning with version 0.8 of iMesh.h, we will add the following C preprocessor macros. This will allow, going forward, applications to be compatible with more than one version of the interface*. #define IMESH_MAJOR_VERSION 0 #define IMESH_MINOR_VERSION 7 2) Zero set handle: All mention of passing 'zero' for a set handle in all iMesh.h documention should be replaced with the root set handle*. Implementations for which a) the root set handle is not zero and b) that actually followed the documentation in that they check for zero rather than the root set will need to be updated. 3) Handle types*: The current handle definitions: typedef void* iBase_Instance; typedef void* iBase_EntityHandle; typedef void* iBase_EntitySetHandle; typedef void* iBase_TagHandle; typedef void* iMesh_Instance; typedef void* iMesh_EntityIterator; typedef void* iMesh_EntityArrIterator; will be replaced with: typedef struct iBase_Instance_Private* iBase_Instance; typedef struct iBase_EntityHandle_Private* iBase_EntityHandle; typedef struct iBase_EntitySetHandle_Private* iBase_EntitySetHandle; typedef struct iBase_TagHandle_Private* iBase_TagHandle; typedef struct iMesh_Instance_Private* iMesh_Instance; typedef struct iMesh_EntityIterator_Private* iMesh_EntityIterator; typedef struct iMesh_EntityArrIterator_Private* iMesh_EntityArrIterator; 4) New Function: /**\brief Set geometric dimension of vertex coordinates * * Set the geometric dimension of the mesh. Notes: An application * should not expect this function to succeed unless the mesh database * is empty (no vertices created, no files read, etc.) *\param instance Mesh database from which to request change. *\param geom_dim Requested geometric dimension. */ void iMesh_setGeometricDimension( iMesh_Intance instance, /*in*/ int geom_dim, /*out*/ int* err ); 5) Changed Functions: There are several functions for which an entity set handle is treated as 'inout' where it should be 'in'*. These include: iMesh_addEntToSet iMesh_rmvEntFromSet iMesh_addEntArrToSet iMesh_rmvEntArrFromSet iMesh_addEntSet iMesh_rmvEntSet iMesh_addPrntChld iMesh_rmvPrntChld The argument shoudl be 'in' because the argument (the value of the handle) is not changed. NOTE: The changes described in 3) will ensure that this change results in compile-time errors. Without the changes in 3), changing the real type from void** to void* for the arguments would still compile, which could be disastrous. 6) The following two functions: iMesh_getAllVtxCoords iMesh_getVtxCoordIndex will be replaced with the new function below. NOTE: This is slightly different than what was discussed during the telecon. I a) noticed a deficiency in the usage (added the 'entity_handles' output list) and b) dropped the in_entity_set argument, for which no agreement was reached during the telecon. /**\brief Get indexed representation of mesh or subset of mesh * * Given an entity set and optionally a type or topology, return: * - The entities in the set of the specified type or topology * - The entities adjacent to those entities with a specified * type, as a list of unique handles. * - For each entity in the first list, the adjacent entities, * specified as indices into the second list. * *\param entity_set_handle The set of entities from which to query *\param entity_type_requestor If not iBase_ALL_TYPES, act only on * the subset of 'entity_set_handle' of the * specified type. *\param entity_topology_requestor If not iMesh_ALL_TOPOLOGIES, act only * on the subset of 'entity_set_handle' with * the specified topology. *\param entity_type_requested The type of the adjacent entities to * return. *\param entity_handles The handles of the (non-struct) subset of * the entity set indicated by * 'entity_set_handle' and the optional type * and topology filtering arguments. *\param adj_entity_handles The union of the entities of type * 'requested_entity_type' adjacent to each * entity in 'entity_handles'. *\param adj_entity_indices For each entity in 'entity_handles', the * adjacent entities of type * 'entity_type_requested', specified as * indices into 'adj_entity_handles'. The * values are concatenated into a single * array in the order of the entity handles * in 'entity_handles'. *\param offset For each entity in the corresponding * position in 'entity_handles', the position * in 'adj_entity_indices' at which values * for that entity are stored. */ void iMesh_getAdjEntIndices(iMesh_Instance instance, /*in*/ const iBase_EntityHandle entity_set_handle, /*in*/ const int entity_type_requestor, /*in*/ const int entity_topology_requestor, /*in*/ const int entity_type_requested, /*inout*/ iBase_EntityHandle** entity_handles, /*inout*/ int* entity_handles_allocated, /*out*/ int* entity_handles_size, /*inout*/ iBase_EntityHandle** adj_entity_handles, /*inout*/ int* adj_entity_handles_allocated, /*out*/ int* adj_entity_handles_size, /*inout*/ iBsae_EntityHandle** adj_entity_indices, /*inout*/ int* adj_entity_indices_allocated, /*out*/ int* adj_entity_indices_size, /*inout*/ int** offset, /*inout*/ int* offset_allocated, /*out*/ int* offset_size, /*out*/ int *err); The code below uses the old interface to retrieve a copy of a hexahedral mesh in a simple array form: MBEntityHandle *vertices = 0, *hexes = 0; int *hex_vertex_indices = 0, *hex_vertex_offsets = 0; double* coords; int num_vertices, num_hexes, junk, junk2, junk3, err, order; int *junk_array; junk = 0; iMesh_getEntities( instance, root_set, iBase_ALL_TYPES, iMesh_HEXAHEDRON, &hexes, &junk, &num_hexes, &err ); junk = 0; iMesh_getEntities( instance, root_set, iBase_VERTEX, iMesh_ALL_TOPOLOGIES, &vertices, &junk, &num_vertices, &err ); junk = junk2 = 0; junk_array = NULL; order = iBase_INTERLEAVED; iMesh_getAllVtxCoords( instance, root_set, &coords, &junk, &junk, &junk_array, &junk2, &junk2, &order, &err); free(junk_array); junk = junk2 = junk3 = 0; junk_array = NULL; iMesh_getVtxCoordIndex( instance, root_set, iBase_ALL_TYPES, iMesh_HEXAHEDRON, iBase_VERTEX, &hex_vertex_offsets, &junk, &junk, &hex_vertex_indices, &junk2, &junk2, &junk_array, &junk3, &junk3, &err ); free( junk_array ); The same code in the new API will be: MBEntityHandle *vertices = 0, *hexes = 0; int *hex_vertex_indices = 0, *hex_vertex_offsets = 0; double* coords; int num_vertices, num_hexes, junk, junk2, junk3, junk4, err; int order; junk = junk2 = junk3 = junk4 = 0; iMesh_getAdjEntIndices( instance, root_set, iBase_ALL_TYPES, iMesh_HEXAHEDRON, iBase_VERTEX, &hexes, &junk, &num_hexes, &vertices, &junk2, &num_vertices, &hex_vertex_indices, &junk3, &junk3, &hex_vertex_offsets, &junk4, &junk4 ); junk = 0; order = iBase_INTERLEAVED; iMesh_getVtxArrCoords( instance, vertices, num_vertex, &order, &coords, &junk, &junk, &err ); 7) New Function: Array form of iMesh_isEntContained to replace containment flags no longer returned from iMesh_getVtxCoordIndex (and hopefully some day all the other functions with a similar argument). void iMesh_isEntArrContained( iMesh_Instance instance, /*in*/ iBase_EntitySetHandle containing_set, /*in*/ const iBase_EntityHandle* entity_handles, /*in*/ int num_entity_handles, /*inout*/ int** is_contained, /*inout*/ int* is_contained_allocated, /*out*/ int* is_contained_size, /*out*/ int* err ); 8) Replace some iBase_EntityHandle with iBase_EntitySetHandle where appropriate*: iMesh_getAdjEntIndices iMesh_getAdjEntities - jason * Similar changes should probably be made to iGeom.h, iMeshP.h, and iRel.h, but that was not discussed during the telecon. /** * Copyright 2006 Sandia Corporation. Under the terms of Contract * DE-AC04-94AL85000 with Sandia Coroporation, the U.S. Government * retains certain rights in this software. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * */ //======================================================== // iBase PACKAGE -- // ITAPS UTITLIES COMMON ACROSS INTERFACES // ERRORS, TAGS //======================================================== package iBase version 0.7 { enum EntityType { VERTEX, EDGE, FACE, REGION, ALL_TYPES }; enum StorageOrder { BLOCKED, INTERLEAVED, UNDETERMINED }; enum CreationStatus { NEW, ALREADY_EXISTED, CREATED_DUPLICATE, CREATION_FAILED }; //==================================================== // ERROR FUNCTIONALITY //==================================================== enum ErrorActions { SILENT, // does nothing, not recommended WARN_ONLY, // prints something, but nothing else THROW_ERROR // throws an exception }; enum ErrorType { SUCCESS, DATA_ALREADY_LOADED, NO_DATA, FILE_NOT_FOUND, FILE_ACCESS_ERROR, NIL_ARRAY, // array was supposed to be initialized and have data BAD_ARRAY_SIZE, BAD_ARRAY_DIMENSION, // all tstt arrays should be 1D INVALID_ENTITY_HANDLE, INVALID_ENTITY_COUNT, INVALID_ENTITY_TYPE, INVALID_ENTITY_TOPOLOGY, BAD_TYPE_AND_TOPO, ENTITY_CREATION_ERROR, INVALID_TAG_HANDLE, TAG_NOT_FOUND, TAG_ALREADY_EXISTS, TAG_IN_USE, INVALID_ENTITYSET_HANDLE, INVALID_ITERATOR_HANDLE, INVALID_ARGUMENT, ARGUMENT_OUT_OF_RANGE, MEMORY_ALLOCATION_FAILED, NOT_SUPPORTED, ENTITY_IN_USE, FAILURE }; class Error extends sidl.SIDLException { void set(in ErrorType error, in string description); void getErrorType(out ErrorType err_type); void get(out ErrorType err, out string description); void getDescription(out string description); void echo(in string label); // prints label and then description string to stderr }; //==================================================== // TAGS //==================================================== enum TagValueType { INTEGER, DOUBLE, ENTITY_HANDLE, BYTES }; //==================================================== // BASIC TAG FUNCTIONALITY //==================================================== // be careful about size arguments // createTag takes number of values of type tag_type interface Tag { void createTag(in string tag_name, in int number_of_values, in TagValueType tag_type, out opaque tag_handle) throws iBase.Error; void destroyTag(in opaque tag_handle, in bool forced) throws iBase.Error; void getTagName(in opaque tag_handle, out string tag_name) throws iBase.Error; void getTagSizeValues(in opaque tag_handle, out int size_values) throws iBase.Error; // number of values void getTagSizeBytes(in opaque tag_handle, out int size_bytes) throws iBase.Error; // total number of bytes void getTagHandle(in string tag_name, out opaque tag_handle) throws iBase.Error; void getTagType(in opaque tag_handle, out TagValueType tag_data_type) throws iBase.Error; }; //==================================================== // ENTITY TAGS //==================================================== interface EntTag extends Tag { void getData( in opaque entity_handle, in opaque tag_handle, inout array<char> tag_value, out int tag_value_size) throws iBase.Error; // in bytes - number of things in the array void getIntData( in opaque entity_handle, in opaque tag_handle, out int int_data) throws iBase.Error; void getDblData( in opaque entity_handle, in opaque tag_handle, out double dbl_data) throws iBase.Error; void getEHData( in opaque entity_handle, in opaque tag_handle, out opaque eh_data) throws iBase.Error; void setData( in opaque entity_handle, in opaque tag_handle, in array<char> tag_value, in int tag_value_size) throws iBase.Error; void setIntData( in opaque entity_handle, in opaque tag_handle, in int tag_value) throws iBase.Error; void setDblData( in opaque entity_handle, in opaque tag_handle, in double tag_value) throws iBase.Error; void setEHData( in opaque entity_handle, in opaque tag_handle, in opaque tag_value) throws iBase.Error; void getAllTags( in opaque entity_handle, inout array<opaque> tag_handles, out int tag_handles_size) throws iBase.Error; void rmvTag( in opaque entity_handle, in opaque tag_handle) throws iBase.Error; }; //==================================================== // ENTITY ARRAY TAGS //==================================================== // the value_array_size is the total number of characters // value_array_size = number of entity_handles*size of each tag's value in bytes // = entity_handles_size * tag value size // in units of elements in the array - value_array_size // on array tags - if you request an int tag on 100 entities and not all of them // have the tag - the behavior is: throw an error; array contents are undefined // error is TAG_NOT_FOUND // on removing tags on array of entities - if the entity doesn't have the tag // just skip over it - do not throw an error and delete tags on the rest of the ents interface ArrTag extends Tag { void getArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, inout array<char> value_array, out int value_array_size) throws iBase.Error; void getIntArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, inout array<int> value_array, out int value_array_size) throws iBase.Error; void getDblArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, inout array<double> value_array, out int value_array_size) throws iBase.Error; void getEHArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, inout array<opaque> value_array, out int value_array_size) throws iBase.Error; void setArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, in array<char> value_array, in int value_array_size) throws iBase.Error; void setIntArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, in array<int> value_array, in int value_array_size) throws iBase.Error; void setDblArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, in array<double> value_array, in int value_array_size) throws iBase.Error; void setEHArrData( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle, in array<opaque> value_array, in int value_array_size) throws iBase.Error; void rmvArrTag( in array<opaque> entity_handles, in int entity_handles_size, in opaque tag_handle) throws iBase.Error; }; //=================================================== // ENTITY SET TAGS //=================================================== interface SetTag extends Tag { //tags void setEntSetData( in opaque entity_set, in opaque tag_handle, inout array<char> tag_value, in int tag_value_size) throws iBase.Error; void setEntSetIntData( in opaque entity_set, in opaque tag_handle, in int tag_value) throws iBase.Error; void setEntSetDblData( in opaque entity_set, in opaque tag_handle, in double tag_value) throws iBase.Error; void setEntSetEHData( in opaque entity_set, in opaque tag_handle, in opaque tag_value) throws iBase.Error; void getEntSetData( in opaque entity_set, in opaque tag_handle, inout array<char> tag_value, out int tag_value_size) throws iBase.Error; void getEntSetIntData( in opaque entity_set, in opaque tag_handle, out int int_data) throws iBase.Error; void getEntSetDblData( in opaque entity_set, in opaque tag_handle, out double dbl_data) throws iBase.Error; void getEntSetEHData( in opaque entity_set, in opaque tag_handle, out opaque eh_data) throws iBase.Error; void getAllEntSetTags( in opaque entity_set, inout array<opaque> tag_handles, out int tag_handles_size) throws iBase.Error; void rmvEntSetTag( in opaque entity_set, in opaque tag_handle) throws iBase.Error; }; interface EntSet { // create/destroy void createEntSet( in bool isList, out opaque entity_set) throws iBase.Error; void destroyEntSet( in opaque entity_set) throws iBase.Error; // is this set ordered? void isList(in opaque entity_set, out int is_list) throws iBase.Error; // get the entity sets // num_hops of >=0 is recurse down that many levels (=0 is that ESet only) // num_hops < 0 is recurse forever void getNumEntSets( in opaque entity_set, in int num_hops, out int num_sets) throws iBase.Error; void getEntSets ( in opaque entity_set, in int num_hops, inout array<opaque> contained_entset_handles, out int contained_entset_handles_size) throws iBase.Error; // add and remove entities void addEntToSet(in opaque entity_handle, in opaque entity_set) throws iBase.Error; // if the entity isn't in the set, don't throw an error void rmvEntFromSet( in opaque entity_handle, in opaque entity_set) throws iBase.Error; void addEntArrToSet( in array<opaque> entity_handles, in int entity_handles_size, in opaque entity_set) throws iBase.Error; // if the entity isn't in the set, don't throw an error void rmvEntArrFromSet( in array<opaque> entity_handles, in int entity_handles_size, in opaque entity_set) throws iBase.Error; // all entity sets are contained in root set // root set is contained in no other sets // root set cannot be removed - throw an error // can't remove anthing from root set - throw an error - use destroy // add/remove entity sets void addEntSet( in opaque entity_set_to_add, in opaque entity_set_handle) throws iBase.Error; // if the entity set isn't in the set, don't throw an error void rmvEntSet( in opaque entity_set_to_remove, in opaque entity_set_handle) throws iBase.Error; // check whether an entity is contained in the entity set void isEntContained(in opaque containing_entity_set, in opaque entity_handle, out int is_contained) throws iBase.Error; // check whether entities are contained in the entity set void isEntArrContained( in opaque containing_set, in array<opaque> entity_handles, inout array<int> is_contained, out is_contained_size ); // check whether an entity set is contained in another void isEntSetContained(in opaque containing_entity_set, in opaque contained_entity_set, out int is_contained) throws iBase.Error; }; interface SetRelation extends EntSet { // Root set cannot be a child or parent // don't throw error if parent/child already exists void addPrntChld( in opaque parent_entity_set, in opaque child_entity_set) throws iBase.Error; // don't throw error if parent/child link doesn't exist void rmvPrntChld( in opaque parent_entity_set, in opaque child_entity_set) throws iBase.Error; void isChildOf( in opaque parent_entity_set, in opaque child_entity_set, out int is_child) throws iBase.Error; void getNumChld( in opaque entity_set, in int num_hops, out int num_child) throws iBase.Error; void getNumPrnt( in opaque entity_set, in int num_hops, out int num_parent) throws iBase.Error; void getChldn( in opaque from_entity_set, in int num_hops, inout array<opaque> child_handles, out int child_handles_size) throws iBase.Error; void getPrnts( in opaque from_entity_set, in int num_hops, inout array<opaque> parent_handles, out int parent_handles_size) throws iBase.Error; }; interface SetBoolOps extends EntSet { // Having root set as entity_set_1 gives the complement of entity_set_2 // behavior for contained sets // explicitly lay out what happens when there are multiple copies of something void subtract( in opaque entity_set_1, in opaque entity_set_2, out opaque result_entity_set) throws iBase.Error; void intersect( in opaque entity_set_1, in opaque entity_set_2, out opaque result_entity_set) throws iBase.Error; void unite( in opaque entity_set_1, in opaque entity_set_2, out opaque result_entity_set) throws iBase.Error; }; } // END iBase //========================================================== // iMesh PACKAGE - The ITAPS mesh interface // MESH QUERY, MODIFICATION //========================================================== // // Only import ITAPS if the iMesh package appears in a separate sidl file. -TLD // import iBase version 0.8; package iMesh version 0.8 { enum EntityTopology { POINT, /**< a general zero-dimensional entity */ LINE_SEGMENT, /**< a general one-dimensional entity */ POLYGON, /**< a general two-dimensional element */ TRIANGLE, /**< a three-sided, two-dimensional element */ QUADRILATERAL, /**< a four-sided, two-dimensional element */ POLYHEDRON, /**< a general three-dimensional element */ TETRAHEDRON, /**< a four-sided, three-dimensional element whose * faces are quadrilaterals */ HEXAHEDRON, /**< a six-sided, three-dimensional element whose * faces are quadrilaterals */ PRISM, /**< a five-sided, three-dimensional element which * has three quadrilateral faces and two * triangular faces */ PYRAMID, /**< a five-sided, three-dimensional element * which has one quadrilateral face and four * triangular faces */ SEPTAHEDRON, /**< a hexahedral entity with one collapsed edge * - a seven noded element with six faces */ ALL_TOPOLOGIES /**< allows the user to request information * about all the topology types */ }; /** single call, worst case scenario */ enum AdjacencyInfo { UNAVAILABLE, /**< Adjacency information not supported */ ALL_ORDER_1, /**< Stored or local traversal */ ALL_ORDER_LOGN, /**< Computation required, e.g., Tree search */ ALL_ORDER_N, /**< Computation required, e.g., Global search */ SOME_ORDER_1, /**< Some connectivity available, stored or local */ SOME_ORDER_LOGN, /**< Some connectivity available, log(n) computation */ SOME_ORDER_N /**< Some connectivity available, n computation */ }; //==================================================== // Core Mesh Interface //==================================================== interface Mesh { // this implies that you can get the root set before data is loaded // use tag conventions on the entity set to specify option behavior // - these are specific to implementations // - Tag convention names - iMesh_LOAD_OPTIONS, iMesh_SAVE_OPTIONS of type BYTE // implementation-defined sizes // - data gets read into root set in all cases and also into the entity_set if // it's not the root set // when you read in duplicate data, then duplicate data exists in the root set, // no attempt is made to merge the data at this stage // for those implementations that don't support duplicate data and/or multiple // - return an error // what gets saved will be file format and implementation dependent // input/output void load( in opaque entity_set_handle, in string name, in string options) throws iBase.Error; void save( in opaque entity_set_handle, in string name, in string options) throws iBase.Error; // global info void getRootSet(out opaque root_set) throws iBase.Error; void getGeometricDim(out int dim) throws iBase.Error; void getDfltStorage(out iBase.StorageOrder dflt_storage) throws iBase.Error; void getAdjTable( inout array< AdjacencyInfo > adjacency_table, out int adjacency_table_size) throws iBase.Error; // check the status of the invariance of the handles since the last time // the getHandleStatus function was called // returns true until the handles have changed // then it returns false until reset is true void areEHValid(in int reset, out int are_valid) throws iBase.Error; void getNumOfType( in opaque entity_set_handle, in EntityType entity_type, out int num_type) throws iBase.Error; void getNumOfTopo( in opaque entity_set_handle, in EntityTopology entity_topology, out int num_topo) throws iBase.Error; // entity arrays void getEntities( in opaque entity_set, in EntityType entity_type, in EntityTopology entity_topology, inout array<opaque> entity_handles, out int entity_handles_size) throws iBase.Error; void getVtxArrCoords( in array<opaque> vertex_handles, in int vertex_handles_size, inout StorageOrder storage_order, inout array<double> coords, out int coords_size) throws iBase.Error; void getAdjEntities( in opaque entity_set, in EntityType entity_type_requestor, in EntityTopology entity_topology_requestor, in EntityType entity_type_requested, inout array<opaque> adj_entity_handles, out int adj_entity_handles_size, inout array<int> offset, out int offset_size, inout array<int> in_entity_set, out int in_entity_set_size) throws iBase.Error; void getAdjEntIndices( in opaque entity_set_handle, in EntityType entity_type_requestor, in EntityTopology entity_topology_requestor, in EntityType entity_type_requested, inout array<opaque> entity_handles, out int entity_handles_size, inout array<opaque> adj_entity_handles, out int adj_entity_handles_size, inout array<int> adj_entity_indices, out int adj_entity_indices_size, inout array<int> offset, out int offset_size ) }; //==================================================== // SINGLE ENTITY TRAVERSAL, QUERY //==================================================== interface Entity extends Mesh { // traverse void initEntIter( in opaque entity_set_handle, in EntityType requested_entity_type, in EntityTopology requested_entity_topology, out opaque entity_iterator ) throws iBase.Error; // change the behavior to be false when there are no more handles and put // garbage in the handle spot (different from current which returns false // on the last valid handle) // note in the doc that it is possible to modify the mesh and muck with // the iterators in such a way that recovery (and the possibility thereof) // is implementation dependent - so buyer beware void getNextEntIter( in opaque entity_iterator, out opaque entity_handle, out int at_end) throws iBase.Error; void resetEntIter( in opaque entity_iterator) throws iBase.Error; void endEntIter( in opaque entity_iterator) throws iBase.Error; // query void getEntTopo( in opaque entity_handle, out EntityTopology ent_topo) throws iBase.Error; void getEntType( in opaque entity_handle, out EntityType ent_type) throws iBase.Error; void getVtxCoord( in opaque vertex_handle, out double x, out double y, out double z) throws iBase.Error; void getEntAdj( in opaque entity_handle, in EntityType entity_type_requested, inout array<opaque> adj_entity_handles, out int adj_entity_handles_size) throws iBase.Error; void getEnt2ndAdj( in opaque entity_handle, in EntityType order_adjacent_key, in EntityType entity_type_requested, inout array<opaque> adj_entity_handles, out int adj_entity_handles_size) throws iBase.Error; }; //==================================================== // ENTITY ARRAY TRAVERSAL, QUERY //==================================================== interface Arr extends Mesh { //traverse void initEntArrIter( in opaque entity_set_handle, in EntityType requested_entity_type, in EntityTopology requested_entity_topology, in int requested_array_size, out opaque entArr_iterator ) throws iBase.Error; // return true as long as ent handle size is nonzero and false otherwise // note in the doc that it is possible to modify the mesh and muck with // the iterators in such a way that recovery (and the possibility thereof) // is implementation dependent - so buyer beware void getNextEntArrIter( in opaque entArr_iterator, inout array<opaque> entity_handles, out int entity_handles_size, out int at_end) throws iBase.Error; void resetEntArrIter( in opaque entArr_iterator) throws iBase.Error; void endEntArrIter( in opaque entArr_iterator) throws iBase.Error; //query void getEntArrTopo( in array<opaque> entity_handles, in int entity_handles_size, inout array<EntityTopology> topology, out int topology_size) throws iBase.Error; void getEntArrType( in array<opaque> entity_handles, in int entity_handles_size, inout array<EntityType> type, out int type_size) throws iBase.Error; void getEntArrAdj( in array<opaque> entity_handles, in int entity_handles_size, in EntityType entity_type_requested, inout array<opaque> adj_entity_handles, out int adj_entity_handles_size, inout array<int> offset, out int offset_size) throws iBase.Error; void getEntArr2ndAdj( in array<opaque> entity_handles, in int entity_handles_size, in EntityType order_adjacent_key, in EntityType entity_type_requested, inout array<opaque> adj_entity_handles, out int adj_entity_handles_size, inout array<int> offset, out int offset_size) throws iBase.Error; }; //============================================ // MODIFY INTERFACE //============================================ // Entity handle invariance - three levels // - get the same handle for the same entity always, even in the face of modification // - the handle may change, but only in the face of modfication // - the handles are not guaranteed to be invariant ever -- not allowed any more interface Modify extends Mesh { // single entities void setVtxCoords( in opaque vertex_handle, in double x, in double y, in double z) throws iBase.Error; void createVtx( in double x, in double y, in double z, out opaque new_vertex_handle) throws iBase.Error; void createEnt( in EntityTopology new_entity_topology, in array<opaque> lower_order_entity_handles, in int lower_order_entity_handles_size, out opaque new_entity_handle, out CreationStatus status) throws iBase.Error; void deleteEnt( in opaque entity_handle) throws iBase.Error; }; interface ArrMod extends Mesh { // entity arrays void setVtxArrCoords( in array<opaque> vertex_handles, in int vertex_handles_size, in StorageOrder storage_order, in array<double> new_coords, in int new_coords_size) throws iBase.Error; void createVtxArr( in int num_verts, in StorageOrder storage_order, in array<double> new_coords, in int new_coords_size, inout array<opaque> new_vertex_handles, out int new_vertex_handles_size) throws iBase.Error; void createEntArr( in EntityTopology new_entity_topology, in array<opaque> lower_order_entity_handles, in int lower_order_entity_handles_size, inout array<opaque> new_entity_handles, out int new_entity_handles_size, inout array<CreationStatus> status, out int status_size) throws iBase.Error; void deleteEntArr( in array<opaque> entity_handles, in int entity_handles_size) throws iBase.Error; }; class Factory { static void newMesh(in string option, out Mesh new_mesh) throws iBase.Error; }; } // END iMesh

6 9

Re: itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]
by Carl Ollivier-Gooch 12 Jan '09

12 Jan '09

Mark Shephard wrote: > Carl, > > Although I would like to put some focus on improving mesh adapt (from > multiple levels) and FMDB (low level performance and memory), I do not > think it is going to happen in the near future since the SCOREC group > needs to keep focused on parallel and meeting the needs of applications > groups we are working with. (By the way your figure 6 showing where the > time is spent is quite interesting and gives great information on where > things need improvement - Ting and others, please note that figure and > table XVI.) I've also got a callgrind profile that I'd be happy to send along now or in the future. It's entirely possible that there are some places where a small change could make a huge difference in performance, if one looked in the right place. > Therefore I am not comfortable including the memory and cpu comparisons. > In addition to known inefficiencies, we may be comparing apples and > oranges in some aspects. The mesh adapt procedures tend to include > substantial logic checks and decision processes not used in lots of > codes. My guess is that the only fair comparison is the the Native and > GRUMMP comparison. I was leaning towards taking this out, but left it in primarily out of inertia. I'm happy to pull the performance comparisons. That said, we shouldn't abandon the notion of doing more complete performance comparisons at some point in the future. Someone (Martin maybe?) floated the notion of having a set of performance kernels to complement the compliance test suite. I think that's a good idea, for two reasons: first, it'll help all of us tune up our implementations, and second, it'll give a realistic (?) assessment of the tradeoffs that come with the different design decisions that have gone into the different mesh databases. Once we have the data internally, we can then decide what to do about releasing it. Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Associate 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/ ------------------------------------------------------------------------

3 2