On Fri, 3 Apr 2009, Derek Gaston wrote: > Essentially it's just a short-circuiting before the > user_initialization() call.
Why not after user_initialization()? If a system with no variables is being initialized, the user's doing something weird, and we should allow the user to be weird as flexibly as possible. ;-) > The problem is that project_vector doesn't work properly with zero > variables in the system... this fixes it. How does short-circuiting System::init and System::reinit fix that, though? We're calling project_vector from EquationSystems::reinit. I'd also rather fix project_vector for the no-variables case, but if your workaround is sufficient it sounds much much easier. > I've also made the same change to System::reinit()... just short > circuiting the whole function.... there really is no reason to do any > reiniting if there are no variables in the system.... For that matter, it looks like we've got some "no reason *ever* for the reinit call to still exist" situations lying around! EigenSystem::reinit just calls Parent::reinit; that would have been achieved anyway by just not overriding the virtual function again. ExplicitSystem and TransientSystem are the same way now that rhs, old_local_solution, etc are registered with add_vector rather than initialized separatedly. NewmarkSystem::reinit() is a libmesh_error() for some reason > With these two changes I can now properly debug runs containing a > System without variables... And they're just "if (!nvars) return;" cases that definitely shouldn't affect anyone else's usage. I'd say go ahead and commit them, but thanks for the warning. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
