> Right. So your code will work, because it's using > CustomEquationSystem. But when I try to open your file in my > meshdiff, meshplot, meshimage, etc. utilities, they'll crash, because > they're using EquationSystems. Likewise, if I'd used your method, > none of the files I'd written out would be openable in any code you've > written.
True. You will not be able to read my output as is but my library still derives from libMesh and so anything created in libMesh can be read by my code. But vice-versa will not work since libMesh does not know about my SpecialSnowFlakeSystem or my derived EquationSystems object. This is fine since my application is a little specific to the physics I'm solving and is not a very general library yet. May be in the future ... > Look at the add_system() implementation. Like with add_vector(), you > can add an already-existant name and you'll just get a reference to > the already-added object. I understand that. Again, I was talking about SpecialSnowFlakeSystem which will fail all the "ifs" and hence throw an error at the end, even if it has been added by the SnowFlake aware CustomEquationSystem a-priori. SpecialSnowFlakeSystem is the reason why I've been arguing to make add_system(type, name) virtual. If no one else finds this useful, I can make this as my specific change in my working copy. Vijay On Wed, Jan 13, 2010 at 4:05 PM, Roy Stogner <[email protected]> wrote: > > > On Wed, 13 Jan 2010, Vijay S. Mahadevan wrote: > >> But the fact is that I do not use EquationSystems directly but instead >> only rely on the derived member, say CustomEquationSystem, which is >> aware of the necessary calls to create, manipulate and delete >> SpecialSnowflakeSystem. Hence, CustomEquationSystem should override >> add_system(type, name) and will perform an action only if the type is >> SpecialSnowflakeSystem. Else, it will just forward the call to >> EquationSystems::add_system(type, name). > > Right. So your code will work, because it's using > CustomEquationSystem. But when I try to open your file in my > meshdiff, meshplot, meshimage, etc. utilities, they'll crash, because > they're using EquationSystems. Likewise, if I'd used your method, > none of the files I'd written out would be openable in any code you've > written. > > It's okay if you don't have such generic tools or don't need that > level of interoperability, but it's not cleaner or more flexible. > >>> When they're read as restart files, however, and I actually really >>> *do* want to create a SpecialSnowflakeSystem, that's still easy >>> enough: the code that's reading them is SpecialSnowflakeSystem-aware, >>> so it calls es.add_system<SpecialSnowflakeSystem>("Special") itself. >>> Then when es.read() encounters a system named "Special" in the data >>> file, it fills in the data for the existing system of that name. >> >> Btw, this will not work as is. > > When theory and practice give differing answers, it's time to > reexamine the theory... > >> Because, the read() method calls add_system(type, name) immaterial >> of whether such a system exists currently or not. May be a call to >> has_system() before this would actually implement the behavior you >> specify. > > Look at the add_system() implementation. Like with add_vector(), you > can add an already-existant name and you'll just get a reference to > the already-added object. > --- > Roy > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
