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

[Jed Brown]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170429/047e819e/attachment.sig>