- changed status to open
- removed comment
Improve roundoff accuracy of efficient RK4
Issue #362
closed
I just encountered a weird case where evolving Minkowski with the efficient RK4 implementation was not static. It turns out that the reason was floating-point round-off error in RK4. During each of the substeps, RK4 adds terms with factors of 1/3 and 2/3, and for the final step, adds a term with a factor of 4/3. Due to round-off, these terms do not cancel exactly, so that the time-evolved lapse is slightly different from 1 (although all the lapse RHS terms are 0). The same goes for the diagonal terms of the metric.
The attached patch keeps track of the round-off error when adding these terms, leading to a more accurate integration result.
The problem described above is not always visible, but also depends on optimisation settings.
Keyword:
Comments (9)
-
reporter
-
- removed comment
The patch also removes some variables - are they unused? Otherwise it looks fine - please apply.
-
reporter
- changed status to resolved
- removed comment
Yes, these variables are unused.
I applied the patch.
-
- removed comment
I have not looked at the patch. This seems to modify a hugely critical part of the code. Have you verified that the testsuites are unaffected by this change?
-
reporter
- removed comment
Alas, I did not.
I am running the testsuites now, but I lack a comparison from before the change. I will them run again, without this change, to see the difference.
I apologise for my oversight.
-
reporter
- removed comment
Yes, there are no differences:
$ diff -u testsuite-old.out testsuite-new.out | less --- testsuite-old.out 2011-03-25 22:47:58.000000000 -0400 +++ testsuite-new.out 2011-03-25 21:35:32.000000000 -0400 @@ -829,9 +829,9 @@ GRHydro: GRHydro_test_tov_ppm_ML Success: 180 files compared, 54 differ in the last digits GRHydro: GRHydro_test_tov_ppm_ML_disable_internal_excision - Success: 180 files compared, 57 differ in the last digits + Success: 180 files compared, 54 differ in the last digits GRHydro: GRHydro_test_tov_ppm_no_trp_ML - Success: 180 files compared, 52 differ in the last digits + Success: 180 files compared, 51 differ in the last digits Hydro_InitExcision: diag_flip_pugh_eno Failure: 72 files missing, 0 files compared, 0 differ Hydro_InitExcision: diag_flip_pugh_ppm @@ -895,7 +895,7 @@ ML_BSSN_Test: gw3d_McLachlan_ord4_15 Failure: 105 files compared, 81 differ, 81 differ significantly ML_BSSN_Test: gw3d_McLachlan_ord4_30 - Success: 96 files compared, 9 differ in the last digits + Success: 96 files compared, 81 differ in the last digits Multipole: test_22 Success: 9 files compared, 9 differ in the last digits Multipole: test_31 @@ -1020,7 +1020,7 @@
Summary for configuration sim-debug
- Time -> Fri Mar 25 22:39:36 EDT 2011 + Time -> Fri Mar 25 21:32:09 EDT 2011 Host -> erik-schnetters-macbook-pro.local User -> eschnett
-
- removed comment
Good. Did you use the full ET thornlist? Clearly the change affects things at the roundoff level (as expected).
-
reporter
- removed comment
Yes, I used the exact ET thorn list, and ran all test cases.
Here is the test case summary -- looks quite bad, actually, about 30% of our test cases fail:
Summary for configuration sim-debug
Time -> Fri Mar 25 21:32:09 EDT 2011 Host -> erik-schnetters-macbook-pro.local User -> eschnett
Total available tests -> 173 Unrunnable tests -> 46 Runnable tests -> 127 Total number of thorns -> 162 Number of tested thorns -> 38 Number of tests passed -> 87 Number passed only to set tolerance -> 43 Number failed -> 40
-
- edited description
- changed status to closed
- Log in to comment
