[petsc-dev] Changing tests

[Jed Brown]

"Mark F. Adams" <mfadams at lbl.gov> writes:

>>> 
>> 
>> Fine, but why is the test a better test of PETSc by doing Richardson/SOR
>> instead of Chebyshev/Jacobi?  
>
> I don't know what better means but as I said it was intended to
> exercise and demonstrate the recommended AMG parameters.  

Are those parameters not tested anywhere else?

>> What is exercised now that wasn't
>> exercised before?
>
> SOR?  

Anything that uses -pc_type mg tests that.

> SOR with multis dof?

ex43 and snes ex19 do that in multigrid and there are other examples
that test more sizes of SOR.

>> We don't need to update the tests for our preference-of-the-day.  If a
>> method is not tested anywhere, we can add it.  Changing an existing test
>> is basically a statement that the old test was redundant/unnecessary and
>> that the new test is needed because it tests some functionality that was
>> not tested elsewhere.  
>
> As I have said so many times but let me add. I use tests as a starting
> point, for code and for parameters on how to run the code.  In the
> future it is natural if someone adds a GAMG test that they will start
> with an existing example. Cheby/Jacobi was causing very frustrating
> failures and I want to kill it.  This things get cut and pasted, as
> they should, and Cheby/Jacobi is a virus that I want to kill.

Hmm, and yet I'm pretty sure I recall you arguing for it earlier because
it parallelizes trivially and performs decently.  I don't have a problem
with changing it (provided Cheby/Jacobi smoothers are still tested
somewhere), but I would like a commit message that says why so that one
of us doesn't come along next year and change it some other way.

>> If you have a justification for the change,
>> please write it in the commit message.
>
> You want justification in commit messages?  And this is supposed to
> fit in what is it 78 chars along with a description of what you
> actually did?

Commit messages can be multiple lines.  (Many projects categorically
refuse patch submissions that have one-line commit messages.)  The
reader needs to be able to determine why the change is a net improvement
over the old state.  Something like the following would make the commit
straightforward to evaluate and would prevent future flip-flopping based
on whatever becomes fashionable.

    KSP: change several GAMG tests from Cheby/Jacobi to Richardson/SOR smoothing
    
    Chebyshev/Jacobi tends to require more work than necessary and has
    fragile spectral estimates, especially for problems of type XX.
    Richardson/SOR requires less tuning and is stronger for essentially
    the same amount of work per iteration.  These tests are used as
    starting points for users, so it's better to choose parameters that
    are more likely to work.

    Chebyshev/Jacobi smoothers are still tested by runexYY [1].


[1] Actually, I think Cheby/Jacobi would be totally untested after
applying your change.  We should have one test that uses Cheby/Jacobi
smoothing.

>>>> Note that on systems with stock MPICH (nemesis) and less than 8 cores,
>>>> this np=8 example oversubscribes (many-year open bug with MPICH) and
>>>> thus runs super slow.
>>> 
>>> This example needs Q^3 processors so it needs 8 to be parallel.
>> 
>> Sure, one reason I like DM is that you can run on any number of
>> processes.  But if we know the test tends to oversubscribe, we be more
>> careful about making it as inexpensive as possible to test whatever is
>> uniquely important about that test versus others.
>
> I will reduce it down when this commit gets resolved on way to the other.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130925/0b771b42/attachment.sig>