<div dir="ltr">On Wed, Jan 23, 2013 at 9:29 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 9:08 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I am always skeptical of big programs to overall a large piece of infrastructure that works fairly well.</div>
<div><br></div><div>However, there is a really simple thing that we need which would make us much much much better</div><div>at using our own tests. We need a better way to test numerical output. I am not sure what the right</div>


<div>thing to do is, or I would have already done it.</div><div><br></div><div>The current best solution is to print fewer digits, which judging from the HTML page is not sufficient.</div><div>I think that current PETSc output is so stylized that parsing output is feasible, and would allow nice</div>


<div>diffs with tolerances tailored to the type of output and individual test.</div><div></div></blockquote></div><br></div>MOOSE puts all their test output into exodus files and uses exodiff. That has the advantage of being structured enough that it can be diffed with rtol and atol.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">OTOH, we have a challenge that's mostly distinct from a discretization package. We're not testing error in a discretization (which is unchanging as long as the discretization doesn't change), we're testing the intermediate, unconverged values, and comparing error using relative tolerance (versus absolute tolerance, which would be better).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">As we attempt to make our interfaces better for graphical front-ends and automatic high-level controllers, I think we should try to use monitors that provide structured output. This could be a JSON file with object identification and convergence history or perhaps a sqlite database. I suspect we could deal with most of our FP-sensitive testing with only a handful of structured monitors. Providing this structured output is providing an API so we should try to rapidly converge on an extensible data model that can be relatively stable.</div>

</div>
</blockquote></div><br>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"><br>
</div><div class="gmail_extra">   Matt<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
</div></div>