On Fri, Jan 9, 2009 at 5:29 PM, Roy Stogner <roystgnr@...> wrote:
> To enable a bit more modularity, automatic multithreading, etc., as
> I've mentioned before, I'd like to change the DiffSystem/FEMSystem
> Right now, the library has methods like:
> Which, overridden by the user, can access DiffSystem member variables
> with state information (like time) and solution information (like
> elem_solution) to fill residual information (like elem_residual and
> elem_jacobian). This is general enough that we could write structured
> finite difference methods on top of it if we wanted to.
> But for now, we all use the only important subclass, FEMSystem, which
> adds more member variables with FEM (or if you wanted, cell-centered
> FVM) specific information - the FE, Quadrature rule, and Elem classes,
> for example.
> That's fine, but now I'd like to move all those member variables into
> a method argument:
> So that, in particular, different threads can work on different
> DiffContext objects at the same time without creating multiple
> systems. We'd then move FEMSystem-specific member variables into a
> FEMContext subclass of DiffContext, and users whose FEMSystem
> subclasses add new member variables would add them to
> "CahnHilliardContext" or some such.
> People with more C++ intuition than I are already seeing the problem
> that arises?
> If BSys subclasses ASys, and BCon subclasses ACon, then
> BSys::method(BCon&) is not an implementation of ASys::method(ACon&),
> and for our purposes BSys::method() won't work with just an ACon&.
> Worse: if ASys is FEMSystem and BSys is UserInventedSystem, then
> there's no way for ASys to even create a BCon to pass in.
How low-level do users of BSys::method() need to get? I mean, is it
imperative that they be able to provide the context, or is the library
going to be smart enough to do it for them? When you first described
the multithreading idea, I thought OK cool, I still just call
element_residual() and then DiffSystem/FEMSystem worries about
creating the separate data for separate threads, etc etc. In derived
systems classes, the user might be required to implement a
build_context() function, callable by the base class. The base class
then manages all the contexts while the threads operate on them and
cleans them up when the assembly is finished.
But, I suspect I am just not understanding the bigger picture of how
you want to multithread DiffSystem, so maybe I could use a little
enlightenment on that point...