ALL the other options are sticky. Calling setFromOptions() twice does not change the value of rtol etc etc etc that was set the last time and even -ksp_monitor is sticky, why are the viewers so special in that they are the only ones that are not sticky? Is not consistent, doesn't make sense, when -ksp_monitor is sticky. It is just a freak feature of the implementation of PetscOptionsGetViewer() that no one realized was there when they wrote it (probably me :-)).
> On Jan 22, 2023, at 1:16 PM, Jed Brown <j...@jedbrown.org> wrote: > > Matthew Knepley <knep...@gmail.com> writes: > >> On Sun, Jan 22, 2023 at 1:06 PM Barry Smith <bsm...@petsc.dev> wrote: >> >>> >>> 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 >>> >> >> Let me address it another way. If I understand correctly, what happens >> currently is that at each ViewFromOptions() call, the database is inspected >> and if a *_view is found, then the view is executed. So when you replace >> the database, if this option is not found then nothing happens. This seems >> to satisfy a kind of options locality. If instead we make some options >> sticky, like -ksp_view, so that once given they never expire, this would >> make the code exceedingly hard to reason about, especially if options are >> set deep inside something, before a user is knowingly doing things. This >> does not sound like the right model to me. > > We could have something like PetscOptionsMerge() if one wants to preserve > previously set options while adding some new ones (without tainting the > global database). I don't like stickiness in general (a key reason why CMake > is impossible to reason about and best practice is to run rm -rf * && cmake > .. -DALL_THE_OPTIONS).
