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 <[email protected]>
> 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
>
