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.
However, I can appreciate that this would require a massive overhaul of all the current test suite. 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. On 14 October 2014 14:15, Jed Brown <[email protected]> wrote: > This can't be fixed simply by reducing 10000. After all, 250^2 is larger > and that's just one more level of nesting. > > We could set time limits on tests and kill them if they don't complete. > > On October 14, 2014 6:28:12 AM CDT, Barry Smith <[email protected]> > wrote: > > > >On Oct 13, 2014, at 10:30 PM, Jed Brown <[email protected]> wrote: > > > >> Barry Smith <[email protected]> writes: > >> > >>> Does anyone object if I change the default KSP max iterations from > >10,000 to 250? > >>> > >>> The rational is that 10,000 is absurd and if you don’t see > >convergence by 250 it generally is pretty hopeless. Users, of course, > >can set a higher max it. > >> > >> This depends a bit on the problem. Iterative methods for > >high-frequency > >> problems often need a lot of iterations, for example. > >> > >> My concern is mostly for people that only every once in a while use > >more > >> than 250 iterations, the solve fails (confusingly because it "used to > >> work"), and they have to start over. Also that just to demonstrate > >> simple scaling behavior with an example like KSP ex2, you'll need to > >> bump up the max iterations. > >> > >> Does the marginal value of saving seconds/minutes(?) > > > >8+ hours is how long one of the (pretty small) nightly test examples > >that used inner outer iterations (when someone screwed up the code so > >the outer did not converge). Normally the example took < 10 iterations > >and ran very quickly. > > > > > > > > > >> for a solver to > >> reach 10k iterations (when you forgot to enable enough monitoring to > >> know what's happening) offset the confusion and alleged misbehavior > >for > >> the people that want to keep iterating? > >
