9th order prolongation test fails with REAL_PRECISION=4

Comments (12)

1. 

   Erik Schnetter

   • removed comment

   I don't think changing things to an L1 warning is a good solution. Either 9th order prolongation works with single precision (then we fix it), or it doesn't because of lack of precision (then we disable it). Or maybe we just have to lower our expectations with single precision.

   For example, the statement

   if (not (good::abs (res - y0) < 1.0e-12))

   may need adjusting. Replacing 1.0e-12 by eps^(3/4) where eps is the precision of CCTK_REAL may be a way.

   RT is a type; it is the real type corresponding to T, which may be a complex type. In C++, eps = numeric_limits<RT>::min(). Can you check whether eps^(3/4) works for single precision? 1.5e-5 seems borderline for this.

   • 2012-02-02T16:58:44+00:00
2. 

   Ian Hinder reporter

   • removed comment

   I looked up numeric_limits, and according to http://www.cplusplus.com/reference/std/limits/numeric_limits, numeric_limits<T>::min() is of type T and is the minimum positive value that T can take. i.e. it would be 1.17549435e-38F for single precision and 2.2250738585072014e-308 for double precision. Do you mean numeric_limits<T>::epsilon() instead? This would be 1.19209290e-07F for single precision and 2.2204460492503131e-16 for double precision. eps^3/4^ would be correspondingly 6.4e-6 and 1.8e-12, which sound more like what we want. In the code, with single precision, I see:

   INFO (CarpetLib): numeric_limits<RT>::min() = 1.1920928955078125e-07 INFO (CarpetLib): good::abs (res - y0) = 1.52587890625e-05

   Is this what you mean by borderline? Should we use eps^4/7^? This gives (1.19209290e-07)^(4/7)^ = 1.1e-4 as the tolerance for single precision and 1.13e-9 for double precision.

   • 2012-02-02T21:54:25+00:00
3. 

   Erik Schnetter

   • removed comment

   Right, it should be epsilon, not min.

   4/7 sound like a very fine-tuned choice. What about 100*eps^(3/4)? Or maybe a lookup table, manually choosing 1e-12 and 1e-4? Or maybe we want 1e+3*eps, acknowledging that we lose 3 digits in our calculations.

   • 2012-02-02T22:00:39+00:00
4. 

   Ian Hinder reporter

   • removed comment

   I agree it is fine-tuned. I like your last suggestion the best. That will make the test stricter than it currently is for double precision (2.2e-13) and allows single precision to work (1.2e-4). 1e-13 seems a little small, but then we are getting to fine-tuning again...

   • 2012-02-02T22:15:15+00:00
5. 

   Erik Schnetter

   • changed status to resolved
   • removed comment

   Applied.

   • 2012-02-05T20:57:31+00:00
6. 

   Barry Wardell

   • removed comment

   This fix seems to have only been applied to the cell-centered version of the code. The original problem reported by Ian still exists. Can we apply the same fix to CarpetLib/src/prolongate_3d_rf2.cc (and possibly any other affected versions)?

   • 2012-02-06T05:58:16+00:00
7. 

   Barry Wardell

   • removed comment

   Replying to [comment:6 barry.wardell]:

   This fix seems to have only been applied to the cell-centered version of the code. The original problem reported by Ian still exists. Can we apply the same fix to CarpetLib/src/prolongate_3d_rf2.cc (and possibly any other affected versions)?

   To answer my own question: no. The fix gets rid of the warning for 9th order, but a similar one appears for the 11th order operators:

   WARNING[L1,P0] (CarpetLib): Error in prolongate_3d_rf2::coeffs_3d_rf2 RT=CCTK_REAL4 ORDER=11 n=10 y0=0, res=-0.000732422 WARNING[L1,P0] (CarpetLib): Error in prolongate_3d_rf2::coeffs_3d_rf2 RT=CCTK_REAL4 ORDER=11 n=10 y0=0, res=-0.000732422

   • 2012-02-06T06:00:51+00:00
8. 

   Erik Schnetter

   • removed comment

   At some point we just have to accept that higher order numerical methods don't make sense with single precision. I suggest to disable this operator for single precision; patches welcome.

   • 2012-02-06T09:40:08+00:00
9. 

   Barry Wardell

   • removed comment

   How about this?

   • 2012-02-06T11:14:26+00:00
10. 

    Erik Schnetter

    • removed comment

    This seems more invasive than necessary. I think it suffices to disable the instantiation and the testing of the 11th order operators; the coefficient arrays can still be defined. However, your patch is also fine.

    Please commit.

    • 2012-02-06T12:28:39+00:00
11. 

    Barry Wardell

    • removed comment

    I agree. I have committed a slightly different patch which is less invasive.

    • 2012-02-06T14:44:28+00:00
12. 

    Roland Haas

    • edited description
    • changed status to closed

    • 2019-02-21T20:21:39+00:00
13. Log in to comment