On Jun 8, 2011, at 12:56 PM, Roy Stogner wrote: > > On Wed, 8 Jun 2011, John Peterson wrote: > >> On Wed, Jun 8, 2011 at 8:49 AM, Cody Permann <[email protected]> wrote: >>> I've just about finished up the patch to allow us to configure >>> subdomain_id_type with ./configure. The current syntax I'm using >>> is "--with-subdomain-id-bytes=<1|2|4>" defaulting to "2". > > This looks good, unless you want to switch it to string arguments to > correspond with John's portability suggestion below. > I'll take a look at this
>> I think we should change the ExodusII code to map 0 to >> >> numeric_limits<int>::max() >> >> when writing, regardless of the subdomain_id_type, since that value >> will always be valid for Exodus. >> >> When reading, we initially read the subdomain ID into an int, then >> check to see if that int value is >= >> numeric_limits<subdomain_id_type>::max(). If it is, then that >> subdomain ID gets mapped to 0 within libmesh. >> >> If we encounter more than one subdomain ID when reading which is >= >> numeric_limits<subdomain_id_type>::max(), then that's an error: you >> can't read the current exodus file with the currently configured >> libmesh; we could print an error message to that effect. > > This sounds ideal for now. This probably makes the most sense when libMesh is running but doesn't solve the problem I mentioned. The actual solution file on disk will contain an ID that changes based on how libMesh is configured. (i.e. if you have it configured with subdomain_id_type = unsigned char, and use the libMesh mesh generation routine for building say a cube, your mesh file on disk will have ID 255 in it. If you have your subdomain_id_type set to unsigned short and run the problem again the output solution file will contain 65535 and so on for the 4 byte case. This makes it more difficult to use an offline comparison tool to compare solution files. > >>> Also, does anyone have a good way to assure that we get the right >>> size type for *any* system? Configure tests the sizes of the >>> various types and records them but I couldn't come up with a clean >>> way to get those sizes into the actual typedef without a lot of >>> seemingly hackish CPreprocessor commands. Right now I'm just >>> making assumptions (see id_types.h) >> >> The most portable way (aside from additional autoconf code) is to let >> the user choose a C type, e.g. "char/short/int" instead of a number of >> bytes. Presumably he knows which is the appropriate one on his >> system. > > C++ guarantees that char will be at least 1 byte, short and int will > be at least 2, and long will be at least 4, but I think stdint.h is > the only standard way to be more specific, and that's a C99 standard > that's probably not guaranteed to play nicely with C++. > > So that leaves autoconf - AC_TYPE_UINT8_T, AC_TYPE_UINT16_T, and > AC_TYPE_UINT32_T ought to work? I like this solution - I might try this instead... > --- > Roy ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
