> On Mar 4, 2019, at 12:57 PM, Lisandro Dalcin wrote:
>
>
>
> On Mon, 4 Mar 2019 at 09:20, Smith, Barry F. wrote:
>
>By golly you are right,
>
>I don't know how we got to the model where each implementation
> independently sets it to 0. Instead of a universal one. Minimizing cod
Lisandro,
Why don't you go ahead and "fix it" in petsc4y and we'll worry about
unifying the construct at some future date.
Barry
> On Mar 4, 2019, at 12:01 AM, Lisandro Dalcin wrote:
>
> Well, this is just because the Python code implementing KSPSolve does not
> reset the iterati
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 req
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
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 whe
> 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 (func
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
destroyi
