[petsc-dev] Discussion about time-dependent optimization moved from PR

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>> On Oct 17, 2017, at 10:06 AM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>> 
>>>> On Oct 17, 2017, at 9:47 AM, Jed Brown <jed at jedbrown.org> wrote:
>>>> 
>>>> Lawrence Mitchell <wencel at gmail.com> writes:
>>>> 
>>>> 
>>>> When I suggested as a young child that DM be essentially just a function
>>>> space and create a new object for resolution-independent specification
>>>> of a problem (residual and Jacobian functions and related components),
>>>> Barry wanted it to be part of DM to avoid having a new object.  So it's
>>>> part of DM -- make a new DM if you're solving a different problem.
>>> 
>>>  Of course, everything in PETSc is subject to refactorization and it
>>>  may be time to do this refactorization; especially if it can
>>>  dramatically decrease the ugly subtle complexities of the TSDM,
>>>  SNESDM .... management. One more public object per solver level is
>>>  probably better than the complexity we have now I do admit.
>> 
>> I'm not opposed to refactoring (though it would take me significant time
>> without distractions),
>
>    Perhaps you don't need to do it all yourself? And we could do it in
>    multiple stages, like first add the new public objects get them
>    working with the DM and then later remove the private objects that
>    exist now?

Whomever does it will need to spend some time learning/reminding
themselves of all the functional requirements.  It could be done
somewhat incrementally, but will need careful reviewing.

>> but this sort of change would have a lot more
>> consequences now because we have lots of code depending on it.  
>
>    True
>
>> Is there
>> a functional reason to refactor now?
>
>     Is there ever? As always it is priorities.

Nonlinear preconditioning and multilevel algorithms were the impetus for
DMSNES.  Prior to that, we had some kludgy void* hiding a dependency
loop (DM depending on SNES) and that was definitely not maintainable or
reasonable to extend to support the new functionality.

I don't see the current structure as a significant liability and
wouldn't consider it high priority at this time.