[Developers] [Patches] Make ADMConstraints GF public

Erik Schnetter schnetter at cct.lsu.edu
Sun Sep 17 17:34:50 CDT 2006

This seems like an ad-hoc measure, chosen because it is easy to  
implement.  This drives us away from my main point:

- For physics results, the sum reduction is in many cases  
irrelevant.  It can be safely omitted.

- If you want to test the sum reduction, then you can choose a case  
which "works" for the current system.

On the other hand, the standard way to handle absolute and relative  
errors is to specify both tolerances, and to flag an error only if  
both tolerances are exceeded.  This is e.g. done in the numerical  
recipes for automatic step size control in time integrators.  I  
oppose choosing an arbitrary threshold such as "1" or "10"; this will  
either confuse users or overlook real errors.


On Sep 17, 2006, at 16:27:30, David Rideout wrote:

> Let me clarify my proposal.  Why not just leave everything as it is,
> except turn off the absolute error checking for values which exceed
> some threshold?  This threshold could be set to 1.  Or maybe 10.  Then
> everthing should work fine, _including_ testing large values such as
> those returned by sum reduction operators.  This has the added benefit
> of being easy to implement...
> Cheers,
> David
> On 9/17/06, David Rideout <dprideout at gmail.com> wrote:
>> IMHO the test mechanism should be changed, not the tests themselves.
>> e.g. what if one wants to test the reduction operators  
>> themselves?  As
>> Jonathan says, it makes little sense to worry about absolute errors
>> except for in small quantities.  The test mechanism could turn off  
>> the
>> absolute error check if the value is above 1, say.
>> -David
>> On 9/17/06, Jonathan Thornburg <jthorn at aei.mpg.de> wrote:
>>> Hi, Erik,
>>>> The "sum" reduction has the problem that it can easily lead to  
>>>> large
>>>> absolute
>>>> differences that are small relative differences.  The "average"  
>>>> reduction
>>>> behaves better in that respect, and, apart from that, tests the  
>>>> same
>>>> thing.  I
>>>> suggest to avoid using the sum reduction in test cases.
>>> | I'm confused:  Since    average := sum / sum_of_weights   , why  
>>> does
>>> |  average   not also "lead to large absolute differences that  
>>> are small
>>> | relative differences"?
>>>> Because of the division by "sum_of_weights".  If you assume 10^6  
>>>> grid points,
>>>> then the absolute difference in the sum is 10^6 times the  
>>>> absolution
>>>> difference in the average.  If you allow an absolute difference  
>>>> of 10^-12,
>>>> then there are often cases where the average is deemed accurate  
>>>> enough, while
>>>> the sum is deemed inaccurate.
>>>> Let me give an example:
>>>> Assume there are 10^6 grid points, all having the value 1.0 plus  
>>>> a small error
>>>> of the order of 10^-14.  Then we have
>>>> the exact values:
>>>>       average: 1.0
>>>>       sum: 10^6
>>>> the perturbed values:
>>>>       average: 1.0 + 10^-14
>>>>       sum: 10^6 + 10^-8
>>>> The relative error of the perturbed values with respect to the  
>>>> accurate values
>>>> is 10^-14 for both the average and the sum.  The absolute errors  
>>>> differ; the
>>>> absolute error for the average is 10^-14, while the absolute  
>>>> error of the sum
>>>> is 10^-8.
>>> Ok, I see your point.  I hadn't realised we (are so foolish as to)
>>> compare non-O(1) values with absolute tolerances.  Using relative
>>> tolerances is *much* preferred...
>>> ciao,
>>> --
>>> -- Jonathan Thornburg <jthorn at aei.mpg.de>
>>>    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein- 
>>> Institut),
>>>    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/ 
>>> home.html
>>>    "Washing one's hands of the conflict between the powerful and the
>>>     powerless means to side with the powerful, not to be neutral."
>>>                                       -- quote by Freire / poster  
>>> by Oxfam
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at cactuscode.org
>>> http://www.cactuscode.org/mailman/listinfo/developers
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers

Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20060917/99fdd7f1/attachment.bin 

More information about the Developers mailing list