Closed smoh closed 3 years ago
@smoh So sorry for the long delay in addressing this. I'm finally sitting down and going through all the issues. Thanks for pointing this out. I implemented a simple fix for the two issues you raised in #270, which I'll be merging into master in the next couple days, with a new release in the next week or two. New unit test here.
As for your question, it really depends on the application. When in doubt, it's best to use as high a ydeg
as you can (although too high can lead to a speed hit and -- worse -- severe numerical instabilities). The current algorithm in starry
works pretty well for phase curves with ydeg
as high as 35
or so, but for occultations, instabilities can kick in above ydeg
of 20
(ish). So don't go any higher than that.
When your data is not very informative about high-degree modes (which is almost always the case) you'll want to regularize. One way is to place a Gaussian prior on the modes with variance that drops exponentially with increasing l
. You can do that easily with map.set_prior()
-- perhaps something simple like
def variance(l, tau=5):
return np.exp(-l / tau)
lam = np.concatenate([np.ones(2 * l + 1) * variance(l) for l in range(map.ydeg + 1)])
map.set_prior(lam)
That places a prior on each of the spherical harmonic coefficients whose variance is equal to exp(-l / tau)
. Low-degree modes will therefore have the highest variance, and it will drop exponentially toward high l
. This lets you use arbitrarily high ydeg
without risking over-fitting. The tricky bit is figuring out what tau
should be -- it's essentially the slope of the power spectrum of the map. You could try to use physics to predict what it should be or go hierarchical and fit for it -- depending on the dataset, you might be able to constrain it pretty well.
I'll keep this issue open until I get around to merging the changes into master, but that should only take a couple days. Let me know if you have any other questions.
Thank you for your response and for updating the code. I'll give what you said a try.
Hi,
I am trying to do what is done in "Eclipsing binary: Linear solution for the maps" notebook (https://rodluger.github.io/starry/latest/notebooks/EclipsingBinary_Linear.html) I have two questions and one minor bug report.
it fails because
ls
is slice objectslice(1,1,1)
andls.start>ydeg
becomes1>1
.I feel like there is no reason why this shouldn't be possible; is it just a special case that is not being handled in
solve
in packing parameters?Prior on secondary
sec_mu = np.zeros(pri.map.Ny) sec_mu[0] = 0.1 sec_L = np.zeros(pri.map.Ny) sec_L[0] = 1e-4 sec_L[1:] = 1e-4 sec.map.set_prior(mu=sec_mu, L=sec_L)