On Mon, 22 Aug 2011, David Andrs wrote: > However the XDA file does not contain enough info to properly add variables, > see system_io.C:212 where add_variable is called > with no subdomain param, which means all variables will live everywhere and > thus the read from XDA file will fail.
Good catch! > A solution for this problem would be to put additional info about > the variable subdomain into the XDA file. By which you mean the solution xda file, not the mesh xda file, right? > However it should not break the old XDA files, Well, technically there's both forwards and backwards compatibility to consider. Old XDA files breaking in new reader code would be completely unacceptable, but if we can't figure out how to avoid new XDA files breaking in old reader code (and I can't...), that will just be something to live with. > so I was thinking to put there something like (1 2 3), which would > mean a set of subdomain_id(). We could probably peek the stream for > opening parenthesis to see if this info is available there or not > and take a proper action based on that. Bear in mind that we want something to work, with the same API calls, whether it's xda or xdr files being read/written. I'm actually leaning towards using the file format identifier. If we see 0.7.2 or higher (or maybe if we see "with per-subdomain variables"?), then we look for a subdomain ID list for each variable, probably in between the Name and Approximation Order fields. --- Roy ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
