[petsc-dev] Monitor changes

Barry Smith bsmith at mcs.anl.gov
Sun Aug 14 12:05:53 CDT 2011


On Aug 13, 2011, at 11:28 PM, Jed Brown wrote:

> On Sat, Aug 13, 2011 at 23:09, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Not sure it is really a viewer? It is an AMS published memory (bunch of fields) for the object, not sure if it makes sense to consider that a subclass of PetscViewer
> 
> In the viewer/monitor case, some of those fields are stack, not heap. They may be computed and thrown away. This makes them different in that in addition to being read-only, they can only be accessed at the moment they are published. Is this somehow not a relevant distinction?

   Well, you are argeeing with me. Publishing an object with AMS is different than viewing them and so AMS publishing is not a subclass of PetscViewer it is a separate thing.

>  
> 
> > that has the object, name, type, and help string for every piece of information being exposed?
> 
>   Yes, I think the only thing missing is the "help string" for each field.  For example currently it is
> 
> ierr = AMS_Memory_add_field(obj->amem,"its",&ksp->its,1,AMS_INT,AMS_READ,AMS_COMMON,AMS_REDUCT_UNDEF);CHKERRQ(ierr);
> 
> "its" is the help string. We could have a convention that the string is done as "variablename: useful message" for example  "its: the number of iterations the Krylov solver is currently at" then the GUI can process it anyway it wants.
> 
> Might be better to change the API now to distinguish the name and the help string just like for options?

   You mean "change the AMS API"? Godzooks you are asking too much :-(  Reason, this information has to be propagated through all the AMS code which scares me too much to consider.

   Barry





More information about the petsc-dev mailing list