On Fri, Oct 14, 2011 at 6:01 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
  Matt,<br>
<br>
    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<br>

<br>
for name in ['VecMDot', 'VecMAXPY', 'KSPGMRESOrthog', 'MatMult']:<br>
<br>
    2.25<br>
 -;;;;<br>
<br>
    2.29<br>
 -  for name in ['VecCUSPCopyTo', 'VecCUSPCopyFrom', 'MatCUSPCopyTo']:<br>
<br>
;;;;<br>
<br>
  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.<br>
</blockquote><div><br></div><div>I totally agree with you. The ChangeSet I just pushed removes any specialized event knowledge from benchmarkExample.py. I will</div><div>redo benchmarkAssembly to use that new code. The only reason I hardcoded it last time was that I needed results that day for a</div>
<div>talk.</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
   Does that make sense?<br>
<font color="#888888"><br>
<br>
   Barry<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Oct 14, 2011, at 2:43 PM, Matthew Knepley wrote:<br>
<br>
> On Fri, Oct 14, 2011 at 10:21 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>  Why have all this stuff?<br>
><br>
>  <a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/49c718f99df2" target="_blank">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/49c718f99df2</a><br>
><br>
>   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?<br>
><br>
> Alright reasons:<br>
><br>
> 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.<br>
><br>
> 2) It meshes with the build system, so I can build several versions of the code. You do this with make, which is quaint.<br>
><br>
> Good reasons:<br>
><br>
> 3) This is for runs across many versions of the code. I can't even switch MPI_COMM_WORLD sizes in your model.<br>
><br>
>     Matt<br>
><br>
><br>
>    Barry<br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>