I'm happy to commit this - any objections?
On 8/23/11 12:07 PM, "David Andrs" <[email protected]> wrote: > > 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] >> <http://p.sf.net/sfu/wandisco-dev2dev> >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
