[petsc-dev] PETSc factories 101 and 102

[Barry Smith]

   Matt,

     Very nice. 

    Barry

Of course you did ignore the obvious statement that we should have written PETSc in Objective C, instead of inventing our own pseudo Objective C like beast :-)  Objective C is way cool and is the only way to program the fastest growing market for applications, iOS  :-)


On Sep 8, 2012, at 7:19 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Sat, Sep 8, 2012 at 5:39 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>    Some discussion came up today about the use of "factories" in C++ (and other OO languages) code and I thought it would be useful to related it to how PETSc handles the same issue since some numerical libraries (the next generation of Trilinos's ML and Chombo) are using factories extensively and recklessly (and will, I am confident, alienate a lot of users. I love it when our competitors make the mistake of chasing every new idea down the wrong road).
> 
>     "In object-oriented computer programming, a factory is an object for creating other objects ", "it deals with the problem of creating objects (products) without specifying the exact class of object that will be created."   http://en.wikipedia.org/wiki/Factory_method_pattern http://en.wikipedia.org/wiki/Factory_(software_concept)
> 
>     So for example if in my code I need a KSP solver object I could do something like
> 
>      void myroutine( …..) {
>         KSPObject  *kspobject = new KSPGMRESObject
> 
>    where KSPObject is my abstract class and KSPGMRESObject is a specific implementation some one has written.  Now in the code I can go off and use the KSPObject to solve something and the rest of my code does not need to "know" that the KSPObject is actually a KSPGMRESObject.  But since when I create the object I cannot create an abstract class and can only create a specific implementation my code has now hardwired the KSPGMRESObject.  Factories are a way of "avoiding" this hardwiring.  I can introduce a new class KSPObjectFactory that has a method newKSPObject() and then reorganize my code as
> 
>     void myroutine(KSPObjectFactory *factory, ….) {
>        KSPObject *kspobject = factor->newKSPObject();
> 
>   and I've removed the explicit use of a particular implementation constructor from my routine.  The actual decision of what type of KSPObject to create is "pushed up higher in the code" and involves the factory.   So for example I could have a KSPObjectFactory() that produces a particular implementation of a KSPObject by setting a string name into the factory.  So if BarrysKSPObjectFactory is a particular implementation of KSPObjectFactory then I could write "higher up in my code"
> 
>        BarrysKSPObjectFactory  *kspobjectfactory = new BarrysKSPObjectFactory;
>         kspobjectfactory->setimplementationbyname("gmres");
>         myroutine(kspobjectfactory);
> 
> one could also consider a method on BarrysKSPObjectFactory   setimplementationbyCommandLineArgs(argsc,args);   now I can "push up" the decision of what KSPObject to actually use to runtime as a command option.
> 
>     A drawback to factories is that it can easily double the number of different classes that users have to deal with and many people (at least Mark and I) find it cumbersome.
> 
> PETSc factories 101
> ----------------------------
> 
>      In PETSc because all objects are essentially delegator objects ("the delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object" http://en.wikipedia.org/wiki/Delegation_pattern)  when we "create" a PETSc object we have not yet actually created the delegated object and thus do not need traditional factories for the purpose listed above. For example
> 
>       KSP  ksp;
>       KSPCreate(comm,&ksp);
> 
>       gives me a KSP solver object that I can pass around to other code, keep references to, and even set options on but it does not have a specific implementation of a solver wired to it yet.  When I call
> 
>       KSPSetType(ksp,"gmres");  or  KSPSetFromOptions(ksp);
> 
>      what happens is the KSP object looks for the "gmres factory" that has been registered with KSPRegister("gmres",KSPCreate_GMRES,..) and calls KSPCreate_GMRES() to generate the delegate that will actually do the solving.
> 
>       Since the delegate is completely encapsulated inside the ksp object I can change the delegate at a later time in the code to have a different implementation by just calling
> 
>       KSPSetType(ksp,"cg")
> 
>       The old delegate is freed and the new solver implementation is put in place. And all references to the ksp object continue to work (just using the new solver).
> 
>       So you see the design of PETSc allows "pushing up" the specific choice of implementations of classes in essentially the same way as factory objects do but without the need for users to explicitly create and manipulate the factories.
> 
> PETSc factories 102
> ---------------------------
> 
>      The other place PETSc uses factories is to allow "mesh information" to determine algebraic objects that are created within algebraic solvers. This is done with the DM abstract class which you can think of as a factory for Vecs and Mats (though it does other things as well).
> 
>       Consider the nonlinear solver SNES in PETSc.  I can use
> 
>        SNESSetJacobian(snes,J,J,func,ctx)
> 
> to provide the matrix that Newton's method is going to use.  But these means that my code that creates the SNES object and sets is various parameters has to explicit know how to create the J Mat object.  If I am using a complicated meshing package that generated some grid and is going to use finite elements to compute the Jacobian J I'd like the figuring out of the size and sparsity pattern of the J to be handled by the meshing package.  Thus I would make an implementation of the DM abstract class (say MattsDM) that does all this yucky figuring out. Then I could call
> 
> DMCreateMatrix(dm,&J)   /* now my solver code sees nothing of the yuckyness of particular mesh details */
> 
> and then pass the J to
> 
> SNESSetJacobian(snes,J,J,func,ctx)
> 
> Similarly I can do the same thing to create vectors.
> 
> We can take this one step further. So far I've been assuming that the application programmer is explicitly creating the algebraic objects (Mats and Vecs) and passing them to the solver object.
> 
> Once solver objects start getting complicated; for example with multigrid methods it is painful for the user to create ALL the vectors and matrices needed for the multiple levels and provide them all to PCMG (though it is possible and we provide interfaces for doing that).
> 
> Instead we can create DMs that can generate appropriate sized vectors and matrices and give those DMs to the solver object and the solver then calls the methods to get new vectors and matrices wherever it needs them inside the solver.   PCMG would still need several DMs, one for each level. But rather than requiring the user to create these several DMs the user can create a single DM and the DM objects have methods in them that generate coarser or finer DMs that can be used to generate the vectors and matrices on the other levels.  This is why a simple call of SNESSetDM(snes,dm) allows the nonlinear and linear solver objects (including all the levels of multigrid) to create all their various needed vectors and matrices.
> 
> When composing complicated solvers this approach can be extremely powerful, one can envision DMs being able to generate sub DMs that represent just pieces of the physics and using those DMs to generate the vectors and matrices for the solver associated with the sub physics (in PCFieldSplit). Thus we can generate all the algebraic pieces for very complicated nested solvers with multigrid inside fieldsplit and fieldsplit into multigrid etc for any number of levels with one simple paradigm.
> 
> 
> In conclusion, you can think of PETSc as having one important visible factory class the DM and then one factory completely transparent to the user for each abstract PETSc object: IS, Vec,Mat,KSP,SNES, and yes even DM. IMHO factories are a powerful and useful tool for large libraries but they should be used sparingly and most of them though thoughtful design need never be seen the users (because if seen by the users that steepens the learning curve a great deal)
> 
>    Questions, clarifications?
> 
> I have written up a discussion of 101 for the Encyclopedia of Programming Languages (Hans Petter is editing), which is attached. We
> should certainly write up 102 since it is more interesting.
> 
> I think DMCreateSubDM() is fine for field pieces, but we need some way of doing domain pieces, and so far I don't like any of the suggestions.
> 
>    Matt
>  
>     Barry
> 
> We actually have another factory in PETSc, MatGetVecs() that returns for a given matrix appropriately sized vectors. I don't have some grand philosophical reason for it to be around, but it is a very useful utility since often when you have a matrix you need vectors to perform operations with it and it is cumbersome to have to pass some vector through several layers of routines to get it to where it is needed to interact with the matrix.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
> <ProgrammingLanguagesForScientificComputing_Full.pdf>