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 <knep...@gmail.com> wrote: > > On Sat, Jan 21, 2023 at 4:34 PM Barry Smith <bsm...@petsc.dev > <mailto:bsm...@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/>
