From: Cody P. <cod...@gm...> - 2013-11-07 16:37:35
|
On Thu, Nov 7, 2013 at 8:36 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > On Nov 7, 2013, at 9:13 AM, Derek Gaston <fri...@gm...> > 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. Yes I did, and we are still tweaking it even now. I just add the nodeset information a few days ago so lets figure out what we need in the current version before the next release! Cody |