[petsc-dev] why have all this stuff

[Barry Smith]

  Matt,

    You misunderstand me. I have no love for keeping the legacy makefiles for testing and do want to get rid of them. Nor do I have any objection to having Python doing the processing; what I object to is things like

for name in ['VecMDot', 'VecMAXPY', 'KSPGMRESOrthog', 'MatMult']:

    2.25
 -;;;;

    2.29
 -  for name in ['VecCUSPCopyTo', 'VecCUSPCopyFrom', 'MatCUSPCopyTo']:

;;;;

  That is having ANY knowledge of the methods, objects etc imbedded in the python processing code. The PETSc source code knows that logic and should be providing any of this knowledge needed to any processing tools (like python scripts). Reason: it is duplication of that knowledge and will get out of sync quickly and messily.  If you want some concept of VecMDot() and VecMAXPY() being "imbedded" in the KSPGMRESOrthog this concept should be in the PETSc library (note that it is not always even true that KSPGMRESOrthog encompasses mdot and maxpy, it depends on the options used if a different orthogonlization is done) and NOT in some python processing script. So, for example the running program could burp out (up on request) the relationship between various events in the run and then the python processing tool would do whatever you want it to do (like merge events or list them with nice formating etc etc) using that relationship information.

   Does that make sense?


   Barry



On Oct 14, 2011, at 2:43 PM, Matthew Knepley wrote:

> On Fri, Oct 14, 2011 at 10:21 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>  Why have all this stuff?
> 
>  http://petsc.cs.iit.edu/petsc/petsc-dev/rev/49c718f99df2
> 
>   Why not build into the PETSc C code and structures any (small) additional stuff needed to do all this? Why create another entirely new duplicate structure in python to do it?
> 
> Alright reasons:
> 
> 1) C sucks for this kind of processing. I use the right language for the right job. If not, we could do everything with C++ templates.
> 
> 2) It meshes with the build system, so I can build several versions of the code. You do this with make, which is quaint.
> 
> Good reasons:
> 
> 3) This is for runs across many versions of the code. I can't even switch MPI_COMM_WORLD sizes in your model.
> 
>     Matt
>  
> 
>    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