<div dir="ltr"><div dir="ltr"><div dir="ltr">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*.<div><br></div><div>Some obvious benefits would be:<br></div><div>[1] Type checking!</div><div>[2] User contexts could be readily shared using PetscObjects reference counter (PetscObjectReferenece()).</div><div>[3] User contexts would have a communicator.</div><div>[4] User contexts could have textual names associated with them (PetscObjectSetName()).</div><div>[5] Internal to PETSc (e.g. within KSPComputeOperators_SNES) the header of the context could be checked to ensure the type of the PetscObject is valid (SNES in this example).</div><div><br></div><div><div>If this change was adopted, the user could readily change their code to use a PetscContainer. Such a change avoids the user having to recreate their own object model / class to deal with simple issues associated with sharing a context, or having to manage communicators within their own contexts.</div><div><br></div></div><div>I see the point that the context is "the users problem". Many PETSc examples simply use a pointer to typedef'd struct as the context. Users tend to copy examples, and really, a simple struct with a bunch of parameters is not a good object model to be followed. Would it be so horrible to require users to put "their problem" (e.g. context) inside a PetscObject?</div><div><br></div><div>Besides the huge volume of work required to change internal PETSc code and more over, the code of all users, are there genuinely compelling reasons to keep using void* everywhere? I cannot think of one, but I would like to hear others thoughts on this. (Maybe there are concerns with Fortran compatibility?). </div><div><br></div><div><br></div><div>Thanks</div><div>Dave</div><div><br></div><div><br></div><div><br></div></div></div></div>