[petsc-dev] explaining hierarchical composible solvers

[Karl Rupp]

Hi,

 >> 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.

It really seems that it's all about understanding compiler components 
and accessing them as a toolbox rather than a black box where you feed 
your code too. This seems to work fairly well with IDEs in terms of code 
completion and the like, maybe it's just that we should familiarize 
ourselves with e.g. LLVM in the same way we do with MPI, threads, etc.? 
This would certainly help with related wishes such as automated code 
formatting checks as well. Still, I have to admit that I fear the 
compiler world.


>>
>> 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 prac
 tical too
l with that approach.)

I fully agree on the little bash on the 'just sync for a second in order 
to write a paper' and that maintaining two different systems for the 
same thing is a nightmare. Unfortunately, I don't have any ideas on 
making it right either - simply because I don't know enough about 
compilers yet...

Best regards,
Karli