> On Oct 17, 2017, at 10:06 AM, Jed Brown <[email protected]> wrote:
>
> Barry Smith <[email protected]> writes:
>
>>> On Oct 17, 2017, at 9:47 AM, Jed Brown <[email protected]> wrote:
>>>
>>> Lawrence Mitchell <[email protected]> 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?
> 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.
Barry
