[petsc-dev] PetscOptionsGetViewer() problems with multiple usage on the same object but different options databases

[Barry Smith]

  That makes incrementally adding new options to an existing object difficult, since each call to setFromOptions() screws up previous calls.

We already have

-ksp_monitor_cancel
-ksp_converged_reason_view_cancel



> On Jan 22, 2023, at 12:45 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Sat, Jan 21, 2023 at 4:34 PM Barry Smith <bsmith at petsc.dev <mailto:bsmith at petsc.dev>> wrote:
>> 
>>   If I run KSPSetFromOptions() on an options database that contains -ksp_view and then push another options database that does not contain -ksp_view and call KSPSetFromOptions() again it undoes the previous setting of that viewer.  So -ksp_view is not used.
>> 
>>   I think this is the wrong model, it should not turn off the previously set view just because it is not being set in the new call, since it was previously set in the KSP. I fear some PETSc function will need another argument to properly handle this; like another flag to PetscOptionsGetViewer().
>> 
>>   Note this is for much more than KSP.
>> 
>>  Thoughts?
> 
> I think it must get rid of it. Otherwise, it would stay forever since there would be no way to get rid of it.
> 
>   Matt 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20230122/90b99a2f/attachment.html>