[petsc-dev] change default KSP max iterations

[Jed Brown]

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 <dave.mayhem23 at gmail.com> 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 <jed at jedbrown.org> 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 <bsmith at mcs.anl.gov>
>> wrote:
>> >
>> >On Oct 13, 2014, at 10:30 PM, Jed Brown <jed at jedbrown.org> wrote:
>> >
>> >> Barry Smith <bsmith at mcs.anl.gov> 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?
>>
>>