From: Vijay S. M. <vi...@gm...> - 2010-01-13 21:51:22
|
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 <roy...@ic...> 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 > |