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

[Barry Smith]

> On Apr 3, 2017, at 10:05 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>> 
>>   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.

   These are different in that, I think, the same code needs to be used regardless of whether the user
just used -snes_mf[*] or the user provided a matrix free matrix directly to the TS or SNES. So I don't think
these can be changed to call SNESGetUsingInternalMatMFFD().
> 
> 
>> 
>> 
>> 
>> 
>>> 
>>> 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.)