[petsc-dev] Using petsc4py in notebooks
Barry Smith
bsmith at mcs.anl.gov
Sun Nov 16 11:40:28 CST 2014
> On Nov 16, 2014, at 6:53 AM, Matthew Knepley <knepley at gmail.com> 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
More information about the petsc-dev
mailing list