[petsc-dev] discoverability

[Barry Smith]

   Jed's email jogged my memory that I had started a simple ASCII- 
based "GUI" to present the options and allow user changes.

   I have resurrected that code, added a bunch new code, and cleaned  
up the code  with the option -options_gui (temporary name). You can  
give it a try. It only handles certain types, is not robust, and  
doesn't work with a batch system, but it does demonstrate my basic  
vision of how this type of interface can be organized.

    Have fun, note you can just hit return for each option you do not  
want changed.

     Barry

It also demonstrates bad use of PETSc Options, like the stuff in  
DASetFromOptions() that someday needs to be cleaned up.





On Feb 22, 2010, at 2:48 PM, Jed Brown wrote:

> 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