[petsc-dev] explaining hierarchical composible solvers

[Barry Smith]

On Dec 3, 2012, at 9:35 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:

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

    Yes. 


> This would certainly help with related wishes such as automated code formatting checks as well.

   Sadly I investigated if there were any decent LLVM based pretty printers and came up with nothing. Uncrustify which seems to do ad hoc parsing of the source code without any real semantic understanding seems by far the best pretty-printer out there.

   Barry


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