<div dir="ltr"><div>Or alternatively, the options set used to define the test should include a sensible value of -ksp_max_it and include the option -ksp_converged_reason. If divergence occurred, then the string written to stdout indicating the reason for termination would provide sufficient information (even with diff) to determine that the test failed. <br><br>However, I can appreciate that this would require a massive overhaul of all the current test suite.<br><br></div><div>Given the current test infrastructure used by PETSc, how could one could easily impose a time limit on each test without making a huge mess inside the makefile? Putting all the options and bash used to verify the tests inside the makefiles is already pretty hairy.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 October 2014 14:15, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This can't be fixed simply by reducing 10000. After all, 250^2 is larger and that's just one more level of nesting.<br>
<br>
We could set time limits on tests and kill them if they don't complete.<br>
<div class="HOEnZb"><div class="h5"><br>
On October 14, 2014 6:28:12 AM CDT, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>On Oct 13, 2014, at 10:30 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
>><br>
>>>  Does anyone object if I change the default KSP max iterations from<br>
>10,000 to 250?<br>
>>><br>
>>>  The rational is that 10,000 is absurd and if you don’t see<br>
>convergence by 250 it generally is pretty hopeless. Users, of course,<br>
>can set a higher max it.<br>
>><br>
>> This depends a bit on the problem.  Iterative methods for<br>
>high-frequency<br>
>> problems often need a lot of iterations, for example.<br>
>><br>
>> My concern is mostly for people that only every once in a while use<br>
>more<br>
>> than 250 iterations, the solve fails (confusingly because it "used to<br>
>> work"), and they have to start over.  Also that just to demonstrate<br>
>> simple scaling behavior with an example like KSP ex2, you'll need to<br>
>> bump up the max iterations.<br>
>><br>
>> Does the marginal value of saving seconds/minutes(?)<br>
><br>
>8+ hours is how long one of the (pretty small) nightly test examples<br>
>that used inner outer iterations (when someone screwed up the code so<br>
>the outer did not converge). Normally the example took < 10 iterations<br>
>and ran very quickly.<br>
><br>
><br>
><br>
><br>
>> for a solver to<br>
>> reach 10k iterations (when you forgot to enable enough monitoring to<br>
>> know what's happening) offset the confusion and alleged misbehavior<br>
>for<br>
>> the people that want to keep iterating?<br>
<br>
</div></div></blockquote></div><br></div>