I understand that every "SpecialSnowflakeSystem" does not need special
attention and in case I gave you that impression, sorry about that.
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).
This IMO is cleaner and allows good flexibility without breaking
existing behavior. This argument is valid for someone who is
interested in deriving from EquationSystems and want to create, use
their own SpecialSnowflakeSystem implementation. Otherwise, what you
suggest is true and I would not want to touch add_system for every new
"RandomSystem" created by a user.
> 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. 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.
Vijay
On Wed, Jan 13, 2010 at 3:29 PM, Roy Stogner <[email protected]> wrote:
>
> On Wed, 13 Jan 2010, Vijay S. Mahadevan wrote:
>
>> Roy, the other reason that add_system needs to be virtual is because
>> in EquationSystems.read(), the systems are created while reading the
>> header through the call to add_system(type, name). And so if you have
>> a System that is not recognized by libmesh, this will always throw an
>> error while reading the header. I hope that is a more sensible reason
>> to make this method virtual. Its been a while since I made this change
>> on my end and when I removed the virtual call on this method, my
>> program started crashing and the reason became apparent.
>
> Ah, yes. I forgot about the tests in add_system().
>
> Redefining add_system() to handle every SpecialSnowflakeSystem class
> is a dangerous way to go, though. Then we write
> "SpecialSnowflakeSystem" to output files, try to run those output
> files later through a more general utility that doesn't know the class
> exists, and "ERROR: Unknown system type:" ensues.
>
> Notice that DiffSystem and FEMSystem don't override
> ImplicitSystem::system_type(). The same goes for my own personal
> CahnHilliardSystem, NavierStokesSystem, SpecialSnowflakeSystem, etc.
> classes. That way, my saved output all gets written as
> "ImplicitSystem", which can be read from generic libMesh utilities
> without crashing.
>
> 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.
> ---
> Roy
>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
