> On Nov 16, 2014, at 6:53 AM, Matthew Knepley <[email protected]> wrote:
>
> Our output needs some overhauling to operate nicely here:
>
> a) ALL monitors need to take the type:file:format:mode form argument.
> -snes_monitor
> does but -ksp_monitor does not
I changed all the -xxx_view to use the ::: format but NONE of the monitor
options. So I don't see how you say -snes_monitor does but -ksp_monitor
doesn't, neither does, they both just take an optional file name and always use
ASCII viewer.
I agree we should refactor the -xxx_monitor to be consistent and use the :::
notation but it is not as simple as the viewers because the monitors monitor a
variety of different things (residual norm, preconditioning residual norm,
range, solution etc etc) and we handle these in a variety of ad hoc ways. For
example -snes_monitor_solution plots the solution with a VecView()
SNESMonitorSolutionUpdate() plots the update to the solution with VecView()
-snes_ratiomonitor (bad naming) monitors the ratio of the norms of the
residuals -snes_monitor_lg_range plots something that is not clear to me (note
for this one part of the name is lg which defines the viewer and there is a
-snes_monitor_range that provides the same information as ASCII. etc etc
How do you propose to unify them? We could do
1) -xxx_monitor[_thingtomonitor] :::: changes current API the least
or
2) -xxx_monitor thingtomonitor:::: (then not consistent with -xxx_view so
probably a bad idea)
or
3) -xxx_monitor :::[:thingtomonitor] annoying to have to put the :::: to
set the thing to monitor
Is 1) powerful enough to do everything we want and be totally consistent?
Examples: -snes_monitor (monitors residual to various viewers)
for example -snes_monitor lg would plot
residual norms in line graph and replace -snes_monitor_lg
-snes_monitor draw would plot the
residual (and replace -snes_monitor_lg_residual)
-snes_monitor_solution draw or binary or socket etc
-snes_monitor
I don't think 1) can be done perfectly but would be a much more consistent
approach then we currently use.
At this time baring other concerns I am fine with coming up with a plan to
refactor towards 1)
>
> b) PetscObjectViewFromOptions() has a static variable to shuts it off after
> any error
> so long running processes are hosed. I would like to make any error in
> that short
> function jump to a label which sets incall = PETSC_FALSE and then calls
> CHKERRQ
I don't understand this.
>
> c) The converged_reason options need to take the ::: argument
>
> Comments?
>
> 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
