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

[Barry Smith]

> On Oct 17, 2017, at 10:30 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> 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.

  Ok, I think it plus the DMTS are problematically because, frankly, only you understand them and anything in a package that has subtle complexities in it that only one person understands is really bad (you kind of admit this by saying you are the only one who can really do a new refactorization).

  Barry