Sorry about the delay in reply. Roy,
> Your confusion is due to the fact that you're assuming our design is > better than it is. ;-) haha. libMesh is one of the more decently structured libraries I've seen and you guys have done a great job in making sure the design adheres to many of the standard patterns/principles. It is not a perfect design but any change that improves it does help everyone. Yes. I can see that in solve, all the systems are treated in a completely decoupled fashion, in a block-jacobi sense. But without the ability to derive from EquationSystems explicitly, there is not much use for this routine. It is understandable that all the primary developers have not derived from this object since it is supposed to be self contained. In my version of EquationSystems, I have the following methods made virtual which I think is the minimal set needed to derive from it. void clear () void init () void reinit () System & add_system (const std::string &system_type, const std::string &name) bool compare (const EquationSystems &other_es, const Real threshold, const bool verbose) const std::string get_info () const Also, I derived EquationSystems from ReferenceCountedObject. Do let me know what you think. John, I know solve was virtual for a while now but only noticed the other virtual methods recently. I do not have adjoint sensitivity analysis capability in my code yet and definitely do not use the new routines yet. And that could've been the reason why I was oblivious to the change. On Wed, Jan 13, 2010 at 9:53 AM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Tue, 12 Jan 2010, Vijay S. Mahadevan wrote: > >> I had to make few of the routines virtual in order to accomplish >> that but since I did not see any of that in the existing design, I >> assumed that EquationSystems was not supposed to be extendable as >> is. But the new inclusions have got me all confused. > > Your confusion is due to the fact that you're assuming our design is > better than it is. ;-) The explanation is simple: > > In principle, we've thought that EquationSystems should be usable as a > base class. In particular, I think that overriding solve() would be > one of the more elegant ways to implement certain operator splitting > and loose coupling algorithms. > > In practice, none of the primary developers have derived from > EquationSystems, so features necessary to do it well may be missing > because they've never been tested in practice. > > Which routines did you make virtual? There's nothing in > EquationSystems that gets called from an inner loop, so there should > be no objections to making more of its methods virtual in the SVN > head. > --- > 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 Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
