Developers and Exodus users, Instead of doing all this odd mapping and un-mapping I started digging into the underlying reason why we weren't writing zero IDs to the exodus files. It turns out that when the exodus files are constructed through the normal API, a number of "mesh-related" fields in the netCDF format are sized and initialized with zeros. Later when we start writing the Mesh data to the file, those data values are retrieved and are assumed to be "uninitialized" if they are zero which is why we can't use them as identifiers. I created a patch for the exodus API which initializes those fields with some other number (i.e. -1) and uses that number to test for uninitialized values and everything works great! The patch also undoes the zero re-mapping in the Exodus and Nemesis IO classes in libMesh.
I've verified that both Ensight and Paraview can read the exodus files containing zero IDs without issues. I haven't tested any other mesh readers but the API defines IDs as signed integers so I would presume that most, if not all readers would work fine with these changes. The final impacts of this change center around the Seacas tools from Sandia. It turns out that some of those tools make assumptions that IDs inside of exodus are positive which might cause a few issues going forward. I already created a patch to fix exodiff so that it'll correctly compare mesh files containing zero IDs. I think this is manageable though - these tools are very stable and don't change very much. The number of lines changed in the Exodus API and the Seacas tools should amount to only a few dozen lines total overall. The question now is do we want to put these changes into libMesh? I've had a discussion with my colleagues here at the INL and we are all for "improving" exodus to handle these cases to move it more inline with the libMesh indexing. Opinions? Cody Now the question remains, Do On Jun 8, 2011, at 1:07 PM, John Peterson wrote: > On Wed, Jun 8, 2011 at 1:02 PM, Cody Permann <[email protected]> wrote: >> >> 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. > > No, what I proposed fixes that problem. Regardless of how you have > libmesh configured, the ID will be written to file as > numeric_limits<int>::max(). > > -- > John ------------------------------------------------------------------------------ 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
