Attached are two patches for review. 1) Fix for Parallel::broadcast of std::set
There is no assign() for std::set. I needed to broadcast the set of subdomain ids and bumped into it. Apply first. 2) Fixing XDA solution file to have subdomain ids for variables. This patch intorduces LIBMESH_VERSION macro to do version comparison (hopefully it will be useful in future) Users can get a set of domains, where a variable lives. When reading the XDA file, we store the version into Xdr class and then when reading system header, we pick it up to decide if we need to read subdomain ids. This patch also changes the harcoded libmesh version that goes into the XDA file to 0.7.2. It seems to me, that there should be some macros for generating the libmesh version and should be used here, so if the version of libmesh changes, we do not have to go all over the code and fix that... The LIBMESH_VERSION macro (above) can be easily used for version comparisons. Note: I was able to achieve this with less lines of code then the peek-into-stream solution and this seems a lot cleaner to me. Thanks, -- David Roy Stogner <[email protected]> wrote on 08/22/2011 12:49:20 PM: > > 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
0002-Storing-subdomain-ids-in-and-XDA-solution-file.patch
Description: Binary data
0001-Fixing-Parallel-broadcast-of-std-set.patch
Description: Binary data
------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
