[petsc-dev] explaining hierarchical composible solvers

[Barry Smith]

On Dec 3, 2012, at 8:18 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Mon, Dec 3, 2012 at 12:30 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>> which doesn't surprise me. Maybe GUI programming tools are now sufficiently
>> mature and powerful such that they indeed help to reduce the overall
>> complexity instead of only adding an additional maintenance burden?
> 
> I used to believe this. Or maybe something closer to "code artifacts can be
> independently extracted, manipulated easily, and recombined to make coding
> easier" which was the program at MS run by the Hungarian notation guy. Barry
> definitely believed this too. Unfortunately, all our attempts failed miserably,
> and facts are pretty convincing. Unless we want to turn into the
> parallel compiler
> guys, we have to look at the facts on the ground.

   I still believe this, but it requires an enormous amount of "compiler stuff" knowledge as well as lots of time to play around and explore how to do it. Sadly the people with sufficient compiler knowledge have their heads so far up their ass and are unable to think outside their silly 1970s box of how compilers work to make the break needed to really do this right.
> 
> I do think Barry is right here that the best use of visualization is
> to comprehend
> overall structure and diagnose logic errors, rather than construct code itself.

   Matt is right, this stuff is a way to display what the already existing code and options are doing in a variety of simple ways to help people understand the algorithms and software implementation. Manipulating these visual displays comes later (on the other hand doing simple things like changing KSP types in particular places in the display is not particularly difficult). The thing is that the PETSc source code defines all the interrelationships and since I do not believe in duplication in any form I do not want a separate "expert system" (thingy) that also knows about all the interrelationships. (Because the separate thing always gets out of date and keeping both representations of the same interrelationships is a nightmare of maintenance.) (People who care mainly about writing papers would just write some python tool that also knew what the source code knew (for a second in time) and publish something on it, not worrying about the fact that it will never become a practical tool with that approach.)

   Barry




> 
>   Matt
> 
>> Best regards,
>> Karli
>> 
>> 
>> 
>> 
>> On 12/02/2012 11:51 PM, Jed Brown wrote:
>>> 
>>> Not a new idea, my friend.
>>> 
>>> 
>>> On Sun, Dec 2, 2012 at 9:49 PM, Karl Rupp <rupp at mcs.anl.gov
>>> <mailto:rupp at mcs.anl.gov>> wrote:
>>> 
>>>    Hmm, following this thought/path all the way down should lead us to
>>> ...
>>> 
>>>    ... a PETSc GUI? It surely sounds a bit odd, but at some point every
>>>    means to fight the dragon named complexity is welcome.
>>> 
>>>    Best regards,
>>>    Karli
>>> 
>>> 
>>> 
>>> 
>>>    On 12/02/2012 07:55 PM, Jed Brown wrote:
>>> 
>>>        I have wanted to make this sort of view interactive for a long
>>> time.
>>> 
>>>        On Dec 2, 2012 4:48 PM, "Barry Smith" <bsmith at mcs.anl.gov
>>>        <mailto:bsmith at mcs.anl.gov>
>>>        <mailto:bsmith at mcs.anl.gov <mailto:bsmith at mcs.anl.gov>>> wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>>             In order to help explain and understand composible solver I
>>>        started
>>>             to add the PetscViewerDraw ability to the solver objects to
>>>             graphically explain the solvers used and the decomposition
>>>        of the
>>>             solvers. It is very crude now but I've attached a couple of
>>>        images
>>>             of what are generated when using -ts/snes/ksp_view_draw
>>>        We need to
>>>             add more information (somehow) to indicate  the multigrid
>>>        levels as
>>>             "levels" the field split decomposition etc. Any thoughts or
>>>        code
>>>             welcome.
>>> 
>>>                 Barry
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> --
> 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