[petsc-dev] why have all this stuff

[Matthew Knepley]

On Fri, Oct 14, 2011 at 6:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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

I totally agree with you. The ChangeSet I just pushed removes any
specialized event knowledge from benchmarkExample.py. I will
redo benchmarkAssembly to use that new code. The only reason I hardcoded it
last time was that I needed results that day for a
talk.

    Matt


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


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111014/0a9a52e1/attachment.html>