Some other questions:

[ericagol]

• [x] Do we need an expression near b=0? k^2 -> \infty, which shows up outside of elliptic integrals.
• [x] Code just in starry: paper focuses on spherical harmonics & math. Can compute arbitrary order limb darkening, but only need m=0 terms.
• [x] limbdark: rewriting Mandel & Agol linear term with stable formula. Write down m=0 relations.
• [x] Compare double-precision versions of Julia & python codes.
• [ ] Do we need handle special cases separately for n != 2 s_n? b+r = 1; b=r (or in vicinity)?

[rodluger]

That's right, my original version appears to be very stable.

[ericagol]

So, probably best to go with that?

[rodluger]

I think so, although I'm still curious about what's causing the instability. I wonder if this fixes your instabilities for small b?

[ericagol]

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.

[rodluger]

So, with the code you just pushed, if I run test_sn_bigr.jlwith 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.

[ericagol]

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

[ericagol]

Are you happy with this?

[rodluger]

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?

[ericagol]

Sorry, no; it's due to K or L, not H, I think, since it remains the same when I set Q to zero.

[rodluger]

In that case I'm definitely happy with it!

[rodluger]

I think there's a typo in (D65): The factor of 2 shouldn't be there in the K term:

[rodluger]

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.

[rodluger]

@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.

[rodluger]

@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

[rodluger]

@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.

[ericagol]

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?

[rodluger]

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.

[ericagol]

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.

[rodluger]

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 .

[rodluger]

@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.

[ericagol]

Yes, I've fixed those; thanks!

[ericagol]

@rodluger How does the earth occultation look now that you've updated your code?

[rodluger]

Really good!

[ericagol]

@rodluger Excellent!