From: Roy S. <roy...@ic...> - 2011-06-09 21:22:14
|
On Thu, 9 Jun 2011, Cody Permann wrote: > 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? Have you sent those changes upstream, to see what they think? If we can upgrade to future Exodus versions without having to apply our own patches each time, then I'd be thrilled to no longer be applying an ugly hack to our Exodus subdomain IDs. We'd want a tool for helping people convert their old files, but that ought to be simple to write; I've got a hundred line "meshbcid" tool for setting boundary condition IDs based on various command line options, and "meshsbdid" would be even simpler. Random digression: would "meshbcid" be useful to anyone else? or "meshnorm" for that matter? I should have thought of this when committing "meshdiff": I've got a couple more of these little utilities lying around that could go in src/apps if there's any public interest. --- Roy |