Dave May writes:
> On Mon, 4 Mar 2019 at 21:30, Jed Brown wrote:
>
>> If reusing, would the interface require
>> casting the function pointers to void(*)(void) instead of what is
>> currently type-safe for most function pointers?
>
>
> No. I don't see that casting a function pointer would be
Dave May via petsc-dev writes:
> I think there would be a lot of merit (in the long run) if user contexts,
> such as given to KSPSetComputeOperators(), SNESSetJacobian() etc were
> changed to be of type PetscObject rather than void*.
>
> Some obvious benefits would be:
> [1] Type checking!
How
I've been working on a nonlinear map object: it would wrap
up the function/derivative/second-derivative callbacks
for SNES/Tao/maybe TS in an object.
It doesn't do what Dave is asking: at the moment, the user still
passes a (void *) as ctx to that object. Rather, I'm interested in
use cases
> On Mar 4, 2019, at 5:54 AM, Dave May wrote:
>
> Hi Barry,
>
>
> On Mon, 4 Mar 2019 at 03:26, Smith, Barry F. wrote:
>
>There is a lot of merit for this alternative approach.
>
>This suggestion is also closely related to the (I think it's Toby's)
> proposal to replace the
Something related are functions like
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESSetConvergenceTest.html
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPMonitorSet.html
which even have 3 parameters - the "evaluation" function, the context, and
There is a lot of merit for this alternative approach.
This suggestion is also closely related to the (I think it's Toby's)
proposal to replace the (function), ctx pairs that manage call backs in PETSc
with objects.
There will be a bit of an issue with dealing with the Fortran
