<div dir="ltr"><div class="gmail_extra"><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>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" style>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" style><br></div><div class="gmail_extra" style>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>