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?