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
