[petsc-users] -snes_mf_operator yields "No support for this operation for this object type" in TS codes?

[Jed Brown]

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

>> On Apr 3, 2017, at 8:51 AM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>> 
>>>   Jed,
>>> 
>>>    Here is the problem. 
>>> 
>>> https://bitbucket.org/petsc/petsc/branch/barry/fix/even-huger-flaw-in-ts
>> 
>> Hmm, when someone uses -snes_mf_operator, we really just need
>> SNESTSFormJacobian to ignore the Amat.  However, the user is allowed to
>> create a MatMFFD and have their TSRHSJacobian function use MatMFFD on
>> their RHSFunction.  That might even be more accurate, but would require
>> the shift/scale.  But I'm not aware of any way in which TS can
>> distinguish these cases.
>
>    SNESGetUsingInternalMatMFFD(snes,&flg); Then you can get rid of the horrible
>
>       PetscBool flg;
>       ierr = PetscObjectTypeCompare((PetscObject)A,MATMFFD,&flg);CHKERRQ(ierr);
>
>   I had to add in two places. Still ugly but I think less buggy.

Yeah, there are also MATMFFD checks in SNESComputeJacobian.

>
>
>
>
>> 
>> What if SNESComputeJacobian was aware of -snes_mf_operator and just
>> passed Pmat in both slots?  Or does the user sometimes need access to
>> the MatMFFD created by -snes_mf_operator?  (Seems like possibly, e.g.,
>> to adjust differencing parameters.)
-------------- 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-users/attachments/20170403/cdb4caa0/attachment.pgp>