[petsc-dev] TS is creating SNES ALWAYS even when not needed

[Barry Smith]

> On Apr 29, 2017, at 10:07 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>> On Apr 29, 2017, at 9:51 PM, Jed Brown <jed at jedbrown.org> wrote:
>>> 
>>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>> 
>>>> For example TSSetFromOptions() creates SNES, TSSetRHSFunction()
>>>> creates SNES, TSSetProblemType() creates SNES!
>>>> 
>>>> This is pitifully bad design, TS should only be creating SNES when
>>>> SNES is needed! Unfortunately TS is now so badly contaminated with
>>>> SNES it is not trivial to remove it.
>>> 
>>> It was an attempt to reduce the number of references
>> 
>>  ?? What kind of references? 
> 
> If you hold the same object in multiple places and assume that they are
> always the same, it's easy to mess up and let them become inconsistent.
> Even if you check for it, it may not make semantic sense for them to be
> different, and that yields confusing behavior.
> 
>>> and prevent the
>>> opportunity for a user to, for example, TSGetSNES and then change the
>>> SNES Jacobian.  But I'll need to overhaul this with IRKs anyway, for
>>> which the SNES sees a larger system than what the user is providing.
>> 
>>  Maybe all PETSc programs should automatically create some Tao objects, TS objects, SNES objects etc just on the off chance the user might want them later. PETSc has usually used the model of create on demand, here clearly it did not.
> 
> SNESSetFromOptions calls SNESGetKSP despite the fact that some SNES
> implementations don't use KSP.  Why aren't you complaining about that?

   That is a flaw that we should fix, the reason it hasn't hit my radar is very few people currently use the SNES types that don't use KSP. Suggestions on how to fix this? The same paradigms may also help with TS.