[petsc-dev] discoverability

[Jed Brown]

On Mon, 22 Feb 2010 14:12:03 -0600, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>    Jed,
> 
>     Over 10 years ago we had support for exactly this. Each section  
> bracketed by PetscOptionsBegin/PetscOptionsEnd resulted in a page of  
> options one could select for in a GUI. This is what the dead variable  
> PetscOptionsPublish is related to. It used the Alice Memory Snooper to  
> communicate between the PETSc processes and a Tcl GUI. It was pretty  
> sweet, but DOE politics killed the Alice Memory Snooper.

I definitely noticed that the design was set up for this, but never knew
it actually worked.

>     I think the way to resurrect it is by using the Zope stuff that we  
> added to PETSc a few years ago and display the GUI's in a browser  
> (with javascript I guess). This would give portability and not require  
> the user to install any GUI packages. Roughly the PetscOptionsEnd()  
> routine would communicate via sockets to the Zope server which would  
> display and get back the options via HTTP and the users browser. What  
> the GUI system does is present the options and allow the user to set/ 
> change the options database graphically as the program runs; except  
> for actually sending/getting back the values from the server the code  
> is in PetscOptionsEnd_Private().

It seems to me that sending the options to the program pretty much
requires restarting it.  If we could arrange things so that all options
were set before anything "expensive" happened, then the restart could be
done continuously as the user changed things like pc_type.  This is hard
to arrange for multilevel and fieldsplit.

I have no direct contact with Zope, but I recall hearing complaints
about unnecessary complexity.  The cool kids seem to like Django these
days.  Any any case, getting it in the browser does sound a lot better
than rolling a custom GUI.

Jed