On Aug 13, 2011, at 10:44 PM, Jed Brown wrote:
> On Sat, Aug 13, 2011 at 22:39, Barry Smith <bsmith at mcs.anl.gov> wrote:
> AMS could be ok. It doesn't care about structure.
>
> The program has to expose the correct structure. Some fields are normally
> computed and thrown away, so they would have to be formalized a bit in order
> to snoop with AMS. The "help" strings are also not centralized like with
> options so it would be harder to explain what a parameter in -pc_view
> actually meant.
>
> Should we make a "rich" viewer
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
> 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.
Barry
> Then we could "publish" this information for AMS and also optionally put it
> into a file or other viewer for anyone who wasn't using AMS to read that data?
