[petsc-dev] DMIGA

[Barry Smith]

   Nate,

    This is ok. 

    IGACreateWrapperDM() should be renamed to DMCreateIGA() to match the paradigm of all the other DM convenience constructors.

    You should rewrite DMIGAGetIGA() in the style of DMRedundantGetSize() which does not do a check based on the type_name string but instead on a registered function pointer. See also DMCreate_Redundant where it registers the function pointer.  

  Note that the model for PETSc objects is that XXXYYYSetZZZ(YYY yyy) where YYY is a specific implementation class is that the Set is ignored when the yyy object is not of type YYY. For example KSPGMRESSetRestart(KSP ksp,.) is ignored if the KSP object is not gmres.  This allows people to write code such as 

KSPCreate(), 
KSPSetFromOptions(), 
KSPGMRESSetRestart(),  
...

that always works so they do not need to edit out the KSPGMRESSetRestart() line when they don't run with gmress.

BUT XXXYYYGetZZZ(YYY yyy,....) generates an ERROR if yyy is not the specific implementation class of YYY, because requesting information that you plan to use from object that cannot provide it is naturally an error since the returned value would garbage and using it would likely cause a crash. 

    I notice you have three perverse functions IGACreateKSP(), IGACreateSNES(), IGACreateTS() that totally do not match the PETSc paradigm; in fact they flip it backwards; in PETSc we have KSPSetDM(), SNESSetDM() and TSSetDM(). 

  -------------------------

   I would like you to totally refactor the design so that the IGA is actually a DM object, this will make the paradigm exactly match the rest of the DM objects (making it easier for users to learn how to use it who have used other DMs) and also making it easier for users are runtime to switch to it from other DMs, and third making it easier to be truly composable and substitutable with other DMs. 
The refactorization is actually not that hard, all the ISSet/Get..() routines become DMIGASet/Get...(), the data structure IGA becomes the private data structure within the DM, routines like IGAGetVector() and IGASetTS() completely disappear and all the DM functionality such as DMGetGlobalVector() etc can be called directly. 

   Think of the DM_IGA object as being a single object with two faces (all DMs have two faces) the DMxxx face that talks to the linear algebra and the DMIGA face that talks about geometry, PDEs etc.

   I estimate with etags in emacs it would only take one of you guys 2 days to do the factorization include the changes to all the examples.

   Of course it is totally outrageous for me, who only meet the two of you in person this week, to say you should refactor the code so extensively from what you designed and loved but in factor the refactorization is mostly superficial IGAxxx -> DMIGAxxx so the design remains very similar to what it is currently but it would  make the IGA match an important (and growing in importance) paradigm in PETSc rather than having its own unique paradigm (such as IGAGetTS(). I ruthless have done this type of refactorization for common paradigms in PETSc for 20 years and will continue to do it. It is absolutely well worth your two days worth of time to do the refactorization now and not put it off. 

  Sincerely,
 
   Barry

  

> On Jun 19, 2015, at 11:17 AM, Nathan Collier <nathaniel.collier at gmail.com> wrote:
> 
> Barry,
> 
> Was discussing a DM-ification of a IGA and Lisandro reminded me we already have this:
> 
> https://bitbucket.org/dalcinl/petiga/src/2d64db7cab9c6307d8a84fcff4127585062c3cce/src/petigadm.c?at=default#cl-55
> 
> which calls:
> 
> https://bitbucket.org/dalcinl/petiga/src/2d64db7cab9c6307d8a84fcff4127585062c3cce/src/petigadm.c?at=default#cl-467
> 
> when we set the DM type to DMIGA. We did this because we have some experimental code which uses DMComposite to support different function spaces for each field component. 
> 
> Is this what you had in mind or do we need to provide something extra? 
> 
> Nate
>