<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 10:03 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">I am torn here. I would bet serious money that I can write a parser for our current numerical output in 1/10</div>

<div class="gmail_extra">of the time it takes to write new output/parsers and setup all the associated infrastructure (databases). If</div>
<div class="gmail_extra">all we ever do is compare, we should just write the parser. Can you think of any other value that would come</div><div class="gmail_extra">from JSON test output?</div><div class="gmail_extra"></div>

</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">petscplot does this parsing in a relatively extensible way</div><div class="gmail_extra"><br></div><a href="https://github.com/jedbrown/petscplot/wiki/PETSc-Plot" target="_blank">https://github.com/jedbrown/petscplot/wiki/PETSc-Plot</a></div>

<div class="gmail_extra"><br></div><div class="gmail_extra">The problem is that when users inject their own diagnostic output, we don't have a reliable way to identify ours. If we had a mechanism by which the output from each object was reliably distinguished, it would be easier to build tools that consume the output. In addition to plotting and error checking, it's relevant for live monitoring and batch analysis. I currently do batch analysis with multiple passes of grep and awk (the effort to properly parsing every incidental thing is too high for the first pass), but it's less precise than I'd like.</div>

</div>