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
