Maps on inclined orbits

[rodluger]

This isn't a bug, just a poor design decision that should be re-thought.

Currently, when the user instantiates a planet and specifies its map, that map is assumed to be what the observer would see when the planet is closest to them, i.e., at a mean longitude of 90 degrees, corresponding to mid-transit.

The problem with this is that it becomes confusing to specify a map of a planet that doesn't transit. Picture this: a highly inclined planet with zero obliquity, rotating in the same plane as its orbit. Say the planet has a simple dipole map that faces the star. How should the user input this map?

Currently, if the user sets the Y_{1,0} coefficient, starry assumes that's what the planet looks like at \lambda = 90, which is wrong since the hot spot would then be pointing away from the observer, and not toward the star!

Moreover, the axis of rotation of the planet defaults to the y axis on the sky. I think it should default to be perpendicular to the orbital plane.

At the very least, we need to make this super clear in the docs.

[rodluger]

Specifically, I think this behavior is confusing:

planet = starry.Planet(L=1, porb=1, prot=1)
star = starry.Star()
sys = starry.System([star, planet])
time = np.linspace(0, 1, 1000)
for inc in [85, 60, 45, 30]:
    planet.inc = inc
    planet.map.reset()
    planet.map[1, 0] = -0.5
    sys.compute(time)
    pl.plot(time, planet.flux, label=inc)
pl.legend()
pl.show()

They all have exactly the same phase curve.

[rodluger]

I think this is better behavior when the user specifies a simple dipole map and different inclinations:

[rodluger]

@ericagol @deitrr The above plot is for longitude of ascending node Omega = 0. What is the expected behavior if Omega = 90? In my mind, the phase curves don't change at all, and the images just rotate counter-clockwise on the page. Is this correct?

[ericagol]

Yes, assuming that your reference plane is the sky plane (as I think it ought to be).

[rodluger]

Awesome -- I figured out the geometry. Here's Omega=45: Going to implement this in C++ now.

[rodluger]

@ericagol @jlustigy @dflemin3 @deitrr Almost ready to go live with this, but wanted your thoughts on this design choice.

Just to bring people up to speed: when the user instantiates a planet with a specific map, we need to decide the frame in which the map is specified. Currently, the map is specified in the sky plane when the planet is closest to the observer (in a transiting configuration, if the orbit is edge-on). This is a problem for two reasons:

• For planets that have been mapped w/ secondary eclipses so far, the "map" is usually the dayside map, not the nightside map, so my convention is backwards.
• More importantly, for inclined orbits and/or orbits with nonzero Omega, the user currently has to specify the map as it looks on the sky, not as it looks in the orbital plane (which is usually how we picture planets). For instance, if we were modeling a planet like the Earth in a system with inc = 45 degrees and Omega = 45 degrees, this is the map the user would have to input: (hard to tell, but that's Asia at the top, Africa at the right, and North America at the left). I think this is a terrible design choice.

Instead, my proposal is to have the user specify the map as if the system were viewed edge-on, with the orbital plane along the xz plane, and with the planet at opposition (secondary eclipse). In this frame, the Earth would look as it usually does (assuming, for simplicity, zero obliquity): The other, important benefit of this is that it makes it easier to define the planet's rotation axis. In the former case (the current behavior), the user would have to specify the rotation axis vector in that weird frame, and do some serious trig to figure out the x, y, and z components. If we switch to this frame, a zero obliquity planet's rotation axis is simply the vector (0, 1, 0). Adding obliquity is straightforward.

In order to get this to work, starry will keep track of two maps: the map provided by the user and the map as seen on the sky, which is the one I use to compute fluxes. I figured out the rotation matrix between these two frames in the general case, so this can be done quickly on the fly.

So, long story short, does this make sense to people? And, if so, how should I concisely explain to the user in the docs how to specify the map and rotation axis? Is the statement, "Specify the map as if the system were viewed edge-on, with the orbital plane along the xz plane, and with the planet at opposition (secondary eclipse)" unambiguous enough? Thanks!

[ericagol]

I think this makes sense for the applications that you are envisioning (secondary eclipses & planet-planet occultations). The one case I can think of that would break this is the case in which the orbit is precisely face-on. This would be an issue if one were using STARRY to study a directly-imaged planet that happened to be nearly face-on within the uncertainties. However, such a planet would not be eclipsed by its star, and would unlikely be eclipsed by a moon if the moon's orbit were not substantially misaligned, in which case one would just need the phase-curve expressions.

[rodluger]

This has been implemented and tested, and I'm happy with the behavior now. I explain these conventions in detail in this tutorial.