August 2010 - Tstt-interface - mailman3.cels.anl.gov

proposal for common configuration elements for ITAPS services
by Jason Kraftcheck 27 Sep '10

27 Sep '10

We have decided on common configuration options used to specify the ITAPS implementations to be used by services. I think that it would be nice if all ITAPS codes followed a common convention for these options. I propose that the group adopt the system we use. I'll describe the system and the reasoning behind the choices below. The system we have decided on uses autoconf variables that point to the i*-Defs.inc file provided by the implementation. The names of the variables are all-uppercase of the form I*_DEFS. An autoconf variable is created in the configure.ac with a statement like the following: AC_ARG_VAR( [IMESH_DEFS] , [Path to iMesh-Defs.inc] ) The following are examples of three slightly different syntaxes that can be used to configure Mesquite with iGeom and iMesh support: Example 1: ./configure IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc \ IGEOM_DEFS=/home/jason/cgm/lib/iGeom-Defs.inc Example 2: IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc \ IGEOM_DEFS=/home/jason/cgm/lib/iGeom-Defs.inc \ ./configure Example 3: export IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc export IGEOM_DEFS=/home/jason/cgm/lib/iGeom-Defs.inc ./configure This system differs from other common ones in two significant ways. Firstly, it uses an autoconf variable rather than an --enable-* or --with-* flag. Secondly, the value is expected to be the full path to the *-Defs.inc file, rather than some directory containing the file. The reason for the first choice (autconf variable) is that it makes configuring many services that are all build against the same implementation(s) (e.g. all services are to be used in the same app) to be configured more easily. A statement like export IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc will store a value in the shell environment that can be used by all subsequent configures of different services without specifying it again. Allowing the value to be specified as an environmental variable is also more likely to be compatible with build systems that are implemented wiht cmake. Cmake has a very different syntax for command line arguments, but can still access environmental variables. The reason for the second choice (full path to *-Defs.inc) is that it is the most straightforward and least error prone way to implement the configure script. It is also entirely sufficient: the defs file should contain all the information the service needs. No other path information should be necessary. Many implementations currently accept a value that corresponds to the --prefix where the implementation was installed. They then expect the defs file to be at the libs/*-Defs.inc relative path. This will break if --libdir was specified explicitly to the configure script as something other than the lib/ subdir of $prefix. It also precludes using the i*-Defs.inc files from un-installed MOAB or CGM builds (which is supported). Another useful feature of this is that it is proof against non-standard names for the *-Defs.inc files, for example if a file must be re-named to avoid conflicts with another implementation. Finally, it is the least error-prone for the user if they are using tab-completion in the shell because by the time they have the whole option specified the shell has verified that it is correct (to have reached the file with tab completion, the file must exist.) - jason

5 7

Re: Special-ness of root set: Impl. vs. data model
by Jason Kraftcheck 31 Aug '10

31 Aug '10

On 08/31/2010 12:20 AM, Mark Miller wrote: > On Mon, 2010-08-30 at 19:59, Tim Tautges wrote: >> On 08/27/2010 02:37 PM, Miller, Mark C. wrote: >>> >> I think this is a case where full generality of the data model >> conflicts with usability of the interface, where here I >> define that as restricting what you can do with/on the root set. > > I am not sure where '...full generality...' is really coming in here. > The data model is the data model. The root set is a) a set and b) the > universe set. There is nothing I am doing/suggesting to 'generalize' the > data model. I am merely asking that the root set, since it is a set, be > allowed to be used as a set in ALL instances where a set is involved and > where it make sense at the data model level. I am asking for an > interpretation of the root set in the iMesh API that is 'free' from > implementation details. > I think I disagree with both of you (Mark and Tim) on one important aspect of this: the root set is not part of the data model. The data model has: the mesh, elements, vertices, entity sets, and tags on any of those. The root set is a fiction in the API to allow a) specifying either the entire mesh or an entity set to query functions and b) used to indicate the mesh when interacting with tags. It is not, nor was it ever intended to be, a proper set in the sense of the data model. It is a convenience in the API to avoid the need to have separate versions of many functions that act on the mesh rather than a subset of the mesh. - jason

3 3

Re: Special-ness of root set: Impl. vs. data model
by Jason Kraftcheck 31 Aug '10

31 Aug '10

On 08/31/2010 12:20 AM, Mark Miller wrote: > > I can. The problem is writing code that uses the API when there are two > kinds of sets I have to worry about; entity sets and the 'almost an > entity set but not quite' root set. Working from a blind list of sets > which may or may not include the special root set, I now have to test > whether or not a given set is the root set before I pass it into > functions accepting sets and examine the error codes they return. > Why would you ever want to pass the root set to some function that is going to modify the set? I think that the goal of an API is to provided the necessary functionality in the most concise and easily understood way as possible. How the root set integrates into the data model should only be considered in so far as how it affects the usability of the API. I can imagine many cases where we should probably support all set query functions on the root set. There are many different algorithms that one may wish to use on either a subset of the mesh or the entire mesh. And it is entirely harmless to do so. However, I think that allowing modification operations on the root set is different. There are four basic set modification operations that could involve the root set (other than tags, which we are allowing): 1) destroy the root set 2) add/remove entities from the root set 3) add the root set to another set 4) make the root set a parent/child of another set I am certain that allowing the first two is a truly horrible idea. Both take what is a relatively benign operation for a set and define a much more destructive behavior for the root set (delete the entire mesh or delete an entity from the mesh.) That is a rather cruel trap that is far more likely to result in bugs than be of any use. Further, allowing this would have precisely the opposite affect of the example you are trying to avoid: > if (set != rooSet) > iMesh_rmvEntFromSet() > else > iMesh_deleteEnt() In practice, if I were writing a subroutine that modified a set I would check for the root set explicitly to avoid unintended consequences: if (set != rootSet) iMesh_rmvEntFromSet(set,ent); else return iBase_FAILURE; /* don't accidentally delete entities */ And anyone who failed to add such checks would be setting themselves up for an unpleasant surprise. I ordered the initial list of modification operations in order of decreasing potential for unintended side effects. The third item, adding the root set to another set is guaranteed to, by definition, create a cyclical containment graph. While the API does not prohibit cyclical set relations, it is typically a bug for an application to create such a containment graph. Further, the meaning of a set containing the root set is rather unclear. Presumably one could just use the root set itself in place of the containing set. As there is no reasonable use case (that I can think of) for wanting to do this and because there is a high probability that an attempt to do it is a bug in the application, I don't think we'd be doing users of the API any favors by allowing the behavior. The final operation type (parent/child links) doesn't really have any unintended side effects. So I'm not strongly opposed to allowing such functionality for the root set. However, it still seems more likely to mask a bug than to provide a useful functionality. I'm not very enthusiastic about implementing a bunch of special case code which is unlikely to ever be (intentionally) used. - jason

1 0

Special-ness of root set: Impl. vs. data model
by Miller, Mark C. 31 Aug '10

31 Aug '10

Hi Folks, I am gaining some experience with the implementations that suggests that root set is treated very differently than other sets. While I understand there are probably good reasons from an implementation standpoint to do this, consider a very simple tool like eyeMesh browser. What that tool basically does is traverse the set containment hierarchy (the hierarchy defined by getEntSets() and then descending into each of those sets). As eyeMesh traverses the hierarchy it gathers all the information it can regarding each set; getNumTopo, getNumOfTopoType, isList, getNumPrnt, getNumChld, etc. eyeMesh then presents this data in a textual oriented gui that allows you to browse what is there. It is coded using a simple recursion starting from the root set. Because of that, it queries everything it ordinarily would, even on root set; isList, getNumPrnt for example. These calls have shown to be problematic on a few implementations as no one expected to have to implement them with the possibility that the given set might be the root set. In further investigating, I've learned that, for example, addPrntChld is not necessarily expected to work with root set as well there might be other calls in iMesh that are problematic to support on the root set. But, these are all impelementation issues and are not part of the data model. From the point of view of the data model, the only thing that makes the root set 'special' is that all other things are contained within it. It is effectively the 'universe' set. It cannot have 'parents' or be 'contained in' another set. So, in my view, with my data model hat on and working only from the iMesh.h header file (not from an implementation), I think that the root set ought to behave 'just like any other set' and that there should be no implementation-driven restrictions upon its use in the API other than those that can be derived directly from the data model. In particular, implementations should be coded to operate 'reasonably' in all cases where an entity set handle is required and caller passes root set for such. If the call does not make any sense in the data model, then it is ok for the call to error out. However, if there is no legitimate argument that the call does NOT make sense from the perspective of the data model when 'entity set handle' is replaced with 'root set', then the call should return normally and with reasonable results. If this is not consistent with others understanding of the data model and implementations, please speak up loudly now so we can identify all the issues. Mark

5 5

proposals for enumeration of interface-specific error codes
by Jason Kraftcheck 30 Aug '10

30 Aug '10

The need for interface-specific error codes was discussed during the boot camp. The following items were agreed upon: o New error codes should be set to the list for review. o All error codes should be included in the iBase_ErrorType enumeration (defined in iBase.h) o Interface-specific error codes should be prefixed with the name of the interface that they are specific to in place of the iBase prefix. For example: iMeshP_NO_PARTITION rather than iBase_NO_PARTITION. o The error codes should be enumerated such that adding a new error code does not break implementations of different interfaces that use an array of strings to implement i*_getDescription. For example, adding a new iMeshP_* error code should not break iRel_* implementations. Below I will propose three alternate schemes for addressing the last point (only). All of these schemes have the additional beneficial property that things will not break if interface-specific error codes are added to the list for an interface for which there were no specific error codes, effectively changing the ordering of the blocks of interface-specific codes. --------------------------------- 1 ---------------------------------- My first, and most controversial suggestion, is to ignore the issue. Getting an error string from an error code should not be a performance-sensitive issue. There is no reason not to use a switch statement to obtain the string for an error code rather than indexing into an array, and such a solution does not break in difficult to catch ways when the list of error codes changes. --------------------------------- 2 ---------------------------------- The second solution is to do the array based indexing using relative values. Similar to my first proposed solution, this solution requires nothing special be done in the iBase_ErrorType definition. The index into the array of interface-specific error codes can be determined by subtracting the first interface-specific error code from the passed error code. For example: Given: enum iBase_ErrorType { iBase_SUCCESS, iBase_MESH_ALREADY_LOADED, iBase_NO_MESH_DATA, ... iBase_FAILURE, iRel_NO_RELATION, ... iRel_NO_SETS, iMeshP_NO_PARTITION, iMeshP_NO_PART, }; Do something like: const iBase_ErrorType first_irel_error = iRel_NO_RELATION; if (error_code >= first_irel_error) return iRel_error_strings[error_code - first_irel_error]; ---------------------------------- 3 --------------------------------- The final suggestion is to use explicit fixed offsets. This is probably most like what the those in the group who expressed a need for this requirement expected. However, it also results in a fairly sparse array. That makes the use of a single common function to for all implementations that indexes into a single array more difficult. Move this enumeration from the iRel.h header to iBase.h (this should probably be done anyway): enum IfaceType {iRel_IBASE_IFACE = 0, iRel_IGEOM_IFACE, iRel_IMESH_IFACE, iRel_IFIELD_IFACE, iRel_IREL_IFACE}; and change it to be the following: enum iBase_IfaceType { iBase_IBASE_IFACE = 0, iBase_IGEOM_IFACE, iBase_IMESH_IFACE, iBase_IMESHP_IFACE, iBase_IFIELD_IFACE, iBase_IREL_IFACE }; Now explicitly define the first interface-specific error code for each interface to be 100 times the corresponding value in the IfaceType enumeration. For example: enum iBase_ErrorType { iBase_SUCCESS = 100*iBase_IBASE_IFACE, iBase_MESH_ALREADY_LOADED, iBase_NO_MESH_DATA, ... iBase_FAILURE, iRel_NO_RELATION = 100*iBase_IREL_IFACE, ... iRel_NO_SETS, iMeshP_NO_PARTITION = 100*iBase_IMESHP_IFACE, iMeshP_NO_PART, };

4 4

Re: Special-ness of root set: Impl. vs. data model
by Carl Ollivier-Gooch 27 Aug '10

27 Aug '10

On 08/27/2010 09:45 AM, Miller, Mark C. wrote: > Hi Folks, > I am gaining some experience with the implementations that suggests that > root set is > treated very differently than other sets. While I understand there are > probably good > reasons from an implementation standpoint to do this, consider a very > simple tool like > eyeMesh browser. What that tool basically does is traverse the set > containment > hierarchy (the hierarchy defined by getEntSets() and then descending > into each of those > sets). As eyeMesh traverses the hierarchy it gathers all the information > it can regarding > each set; getNumTopo, getNumOfTopoType, isList, getNumPrnt, getNumChld, > etc. eyeMesh > then presents this data in a textual oriented gui that allows you to > browse what is there. > It is coded using a simple recursion starting from the root set. Because > of that, it queries > everything it ordinarily would, even on root set; isList, getNumPrnt for > example. These calls > have shown to be problematic on a few implementations as no one expected > to have to > implement them with the possibility that the given set might be the root > set. > In further investigating, I've learned that, for example, addPrntChld is > not necessarily > expected to work with root set as well there might be other calls in > iMesh that are > problematic to support on the root set. > But, these are all impelementation issues and are not part of the data > model. From the > point of view of the data model, the only thing that makes the root set > 'special' is that > all other things are contained within it. It is effectively the > 'universe' set. It cannot have > 'parents' or be 'contained in' another set. > So, in my view, with my data model hat on and working only from the > iMesh.h header > file (not from an implementation), I think that the root set ought to > behave 'just like any > other set' and that there should be no implementation-driven > restrictions upon its use > in the API other than those that can be derived directly from the data > model. In particular, > implementations should be coded to operate 'reasonably' in all cases > where an entity set > handle is required and caller passes root set for such. If the call does > not make any sense > in the data model, then it is ok for the call to error out. However, if > there is no legitimate > argument that the call does NOT make sense from the perspective of the > data model > when 'entity set handle' is replaced with 'root set', then the call > should return normally > and with reasonable results. > If this is not consistent with others understanding of the data model > and implementations, > please speak up loudly now so we can identify all the issues. Mark, Thanks for volunteering to do an audit of all set-related functions and propose the proper behavior of these when passed a root set. ;-) Then we'll all argue with whatever results you come up with. 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

iMeshP compliance test download
by Misbah Mubarak 26 Aug '10

26 Aug '10

All, The iMeshP compliance test can be downloaded from https://svn.scorec.rpi.edu/svn/TSTT/ComplianceTests/iMeshP -Misbah

1 0

itaps.mcs.anl.gov build issues
by Jason Kraftcheck 26 Aug '10

26 Aug '10

The itaps machine at Argonne appears to have a broken mpich install in the default path (e.g. /usr/bin/mpicxx). For building MOAB a bunch of link errors went away when I used /usr/lib/mpich/mpicxx instead. - jason

3 2

ITAPS SVN repository
by fabien delalondre 26 Aug '10

26 Aug '10

To all, If you have question regarding ITAPS svn repository, please contact help(a)scorec.rpi.edu. Tim Wickberg will get back to you as soon as possible. Fabien -- Fabien Delalondre, PhD. Senior Research Associate, Scientific Computation Research Center (SCOREC). Rensselaer Polytechnic Institute (RPI), Troy, NY. Email: delalf(a)scorec.rpi.edu, Phone: (518)-276-8045

1 0

thoughts on testing and coverage
by Miller, Mark C. 26 Aug '10

26 Aug '10

We discussed coverage metrics in the context of iMesh/iMeshP unit testing. One useful metric is of course function count. However, many functions can be called with a variety of arguments including arguments that can drive the interfaces into error conditions and so function count alone can wind up not providing clear coverage metric for testing. We observed that routinely measuring coverage in the same way we routinely run tests and report results is probably NOT as essential as doing a focused gcov-like analysis as testing codes are developed and evolve. With the exception of iMesh reference implementation, existing iMesh/iMeshP implementations generally include a combination of some other product (e.g. FMDB, MOAB, GRUMMP) with an ITAPS interface wrapper bolted onto it. To adequately measure gcov-like coverage if ITAPS interfaces in this setting, we could take the following appraoch... For any implementation, we identify the handful of source files were the ITAPS interface wrapper code exists. Then, that wrapper code is prepared as necessary for gcov and the gcov analysis is performed ONLY on those relevant files. In this way, we measure coverage of the ITAPS interfaces WITHOUT having the whole of the underlying implementation substrate factor into the analysis. As Jason observed, you'd only need to do this analysis as the test code itself is developed and modified, but as implementations change. Mark

1 0