On Nov 7, 2013, at 9:13 AM, Derek Gaston <fried...@gmail.com> wrote:
> I understand what you're saying - but the current format is so very close to > what I actually currently need. If it had element and node ids in it and > tried to restore those ids when you loaded the file I believe that it would > do everything I currently need it to do. > > Can we do something simple in the interim like a configure option to write > IDs to the XDA file? Yeah, this is trivial. Consider what we have currently in the header: 1 # number of elements 27 # number of nodes . # boundary condition specification file n/a # subdomain id specification file n/a # processor id specification file n/a # p-level specification file 1 # n_elem at level 0, [ type (n0 ... nN-1) ] We already support writing the processor id, or not, based on the "processor id specification file" We presently support "n/a" or ".", meaning the processor id is either not included or written to the current file. The idea here is the processor mapping could also be read from a separate file, but this has not been implemented. Adding "n/a" # element id specification file . # element id specification file to the header is what we want to do. Similarly for the node ids. Cody, you just recently changed the IO version number anyway, right? So we can just add this option into the new, unreleased change. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
