Closed ericagol closed 6 years ago
That's right, my original version appears to be very stable.
So, probably best to go with that?
I think so, although I'm still curious about what's causing the instability. I wonder if this fixes your instabilities for small b?
It doesn't seem to fix the problem for small b. The problem at small b
seems to be caused by alternating signs in the terms A_{i,u,v}
. I did find an improvement by computing K_{uv}
, L_{uv}
, and Q
by taking the sum of positive and negative terms from least to greatest (each), and then summing the results together; I think this avoids some of the round-off error caused by the alternating signs successively cancelling. But, I'm still getting large errors for the smallest terms when b=10^{-8}
; these are probably the harmonics that alternate in sign azimuthally around the star. This isn't too worrying since these won't contribute much to total flux.
So, with the code you just pushed, if I run test_sn_bigr.jl
with r = 110
and b = 110.99
, I get lines that look like this:
n: 363 l: 19 m: -17 mu: 36 nu: 2 s: -1.0719823571498716e-21 s_big: -1.201711975110431e-19 d_old: -0.9910795400282887 d_big: -0.9910795400282887
...
n: 371 l: 19 m: -9 mu: 28 nu: 10 s: -2.3841857910483374e-7 s_big: -3.68271397181325e-16 d_old: 6.473991207608575e8 d_big: 6.473991207608575e8
...
n: 375 l: 19 m: -5 mu: 24 nu: 14 s: -1.8426744612576101e-16 s_big: -2.0804086199601594e-14 d_old: -0.9911427281949404 d_big: -0.9911427281949404
...
n: 367 l: 19 m: -13 mu: 32 nu: 6 s: 2.384185791015036e-7 s_big: -6.614199275635531e-18 d_old: -3.604647655331025e10 d_big: -3.604647655331025e10
where the difference between s
and s_big
is several orders of magnitude. Curiously, this happens for l = 19
and l = 17
, but is much less pronounced for large even l
. If you switch to the old H_{u,v}
, these instabilities should disappear.
Okay, thanks! I still find some large relative errors, but much smaller in the absolute sense:
n: 291 l: 17 m: -15 mu: 32 nu: 2 s: -6.382340453166007e-18 s_big: -6.734484328137131e-18 d_old: -0.05228965690807874 d_big: -0.05228965690807874
n: 363 l: 19 m: -17 mu: 36 nu: 2 s: 1.9843516557680895e-19 s_big: -1.201711975110431e-19 d_old: -2.651270601331686 d_big: -2.651270601331686
n: 367 l: 19 m: -13 mu: 32 nu: 6 s: -6.846679775031808e-18 s_big: -6.614199275635531e-18 d_old: 0.035148698989559746 d_big: 0.035148698989559746
Are you happy with this?
I think so, though we should come back to this after I've finished coding everything up in C. Are you sure that the remaining error is still due to H
?
Sorry, no; it's due to K
or L
, not H
, I think, since it remains the same when I set Q
to zero.
In that case I'm definitely happy with it!
I think there's a typo in (D65):
The factor of 2 shouldn't be there in the K
term:
I got the upward recursion for J working in C, but when I tried to adapt your code using cel
the light curves blew up. If you derived the cel
version from (D65) then it needs to be fixed as well.
@ericagol We should make it clear in the text that (if I'm not mistaken) the upward and downward recursion expressions for I and J (D55, D56, and D73) are valid in both the k^2 < 1
and k^2 >= 1
cases, even though the boundary conditions are different.
@ericagol I think you want your tolerance to be eps(1/k2)
when k2 >= 1
:
https://github.com/rodluger/starry/blob/7126d6729a85a3f4f784e93bfea7eb870cce875a/julia/sn_bigr.jl#L87
@ericagol I wonder if the above change to the tolerance fixes your stability issues for small b
? I didn't implement your intelligent summing method but am getting errors at the 10^-12
level as b --> 0
for l = 10
.
Maybe! Can you tell me what b
and r
values you use, and whether you are raising/lower the I_v
, J_v
, and H_uv
?
For r = 0.1
, b = 1e-8
, l = 10
, here is the difference between all of the s
terms computed at double and quadruple precision:
The relative difference is below machine precision everywhere, although the fractional difference creeps up to 1e-4
when the term is very small: I think that's expected, though. I'm computing H
with an upward recursion, I
from the tabulated values, and J
with a downward recursion.
I get similar looking residuals as you for the same parameters:
I'm happy that we've reached machine precision! Thanks for tracking down the typos - I didn't do as thorough job as I had with the r>>1
case, so sorry you had to root out the errors.
Nice! And no worries, this is the best way to make sure we're doing the right thing.
By the way, my criterion for doing upward recursion is 0.5 < k^2 < 2. It seems to work well everywhere I've tested it. It may be related to the fact that if the series coefficients are close to unity, 1/2 is the largest value for which the series converges. Our coefficients drop off with increasing n, but as a rule of thumb this might make sense...
On Tue, Jun 12, 2018, 1:21 PM Eric Agol notifications@github.com wrote:
I get similar looking residuals as you for the same parameters:
[image: diff_lmax10_r0 1_b1em8] https://user-images.githubusercontent.com/243664/41314779-8f3ff9ce-6e42-11e8-8348-a13ccaab1a95.png
I'm happy that we've reached machine precision! Thanks for tracking down the typos - I didn't do as thorough job as I had with the r>>1 case, so sorry you had to root out the errors.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/rodluger/starry/issues/88#issuecomment-396720672, or mute the thread https://github.com/notifications/unsubscribe-auth/AI5FK2rWOBdImKcz-KihltwC6brBJL2jks5t8CLdgaJpZM4UbpBW .
@ericagol Let me know once you've fixed the typo in (D65) and your cel
code for J_0
and J_1
and I'll close this issue. I've opened new ones with things that came up, so that will help with the organization.
Yes, I've fixed those; thanks!
@rodluger How does the earth occultation look now that you've updated your code?
Really good!
@rodluger Excellent!