We have to overhaul the test harness anyway. One way or another, we need to call a runner that is responsible for everything (including output verification). Whatever we choose will be simpler than the current.
On October 14, 2014 9:13:19 AM CDT, Dave May <[email protected]> wrote: >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? >> >>
