[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