Where should +Z point in the Cartesian XYZ frame convention?

Following #15, we should have a discussion about the pros and cons of various orientations of the XYZ Cartesian frame in observer coordinates. If we are sticking to right-handed systems, there are basically two options

1. +Z points away from the observer. This is currently the way exoplanet is structured.
2. +Z points toward the observer. This is the way Murray and Corriea seem to have things.

There are some pros and cons to each system.

System 1 yields v_z = v_radial, in that positive radial velocities are receeding from the observer. However, matching up astrometric orbits is a little bit tricky because after we go from the x,y,z in the perifocal frame to the XYZ in the sky frame, we need to associate X and Y with RA and DEC appropriately. The observational definition is that if the position angle of the ascending node (Omega) is 0, then the node is located 0 degrees east of north. This makes the X axis correspond to the north axis, and so to conform to the right hand rule, since we usually draw north up and east to the left, the Y axis must point to the right, or Y = - RA axis. This means that mentally mapping a simple orbit in the perifocal plane to the observer frame requires a reflection about the X axis. I always found this a little bit confusing because when plotting orbits we typically invert the RA axis to have it increasing to the left. This convention would also have us negating it as well.

System 2 does better with associating X and Y with cardinal directions. The X axis still corresponds to north, but now Y points to the left, so Y = + RA axis. So mapping from the perifocal frame to the observer frame only requires a 90 degree rotation. This is easy enough to plot an orbit as plt.plot(Y, X). This system can’t have it all, though, since now Z points towards the observer and so v_radial = - v_z.

Thoughts on which would make our lives easiest across all of the package?

Second, following the choice of where +Z points, is a discussion of which node is the ascending node, i.e., the one where the secondary is coming towards the observer, or the one where the secondary is receeding from the observer.

A third observational convention is that inclination is [0, 90) degrees when the orbit is counter-clockwise on the sky and (90, 180] degrees when the orbit is clockwise on the sky. For this reason I tend to prefer System 2 because it means the inclination is simply the angle between the angular momentum vector of the orbit and the +Z axis (pointed towards the observer).

Once we make decisions on the first two conventions then I think the rotation matrices from the perifocal frame to the observer frame are uniquely specified.

[dfm]

Excellent. I’m happy to switch to 2 where Z points towards the observer (I know that this is also what @rodluger wants…). Here’s a list of some of the spots where we’ll have to make changes:

• exoplanet/theano_ops/starry/limbdark.cc: this currently has the transit == (z < 0) convention encoded
• exoplanet/theano_ops/contact/contact.cc: the contact points for a transit are computed with the current definition
• exoplanet/light_curves.py: defaults to passing los = -tt.ones_like(...) to get a transit
• exoplanet/orbits/keplerian.py we’ll have to incorporate the rotation matrices properly @iancze: since you’re looking at this anyways, can you update the implementation and add the matrices that you’re using somewhere in paper/exoplanet.tex or a notebook in docs/notebooks so that it’ll go into the docs?
• exoplanet/orbits/keplerian.py we’ll have to audit the radial_velocity function
• exoplanet/orbits/light_curve_test.py I think that the comparisons to batman might need to be updated because I think batman uses the old convention

I’m sure there are some other spots that we’ll need to audit and we can add them here.

[dfm]

This notebook looks awesome! If we want to get crazy, we could add a mixture model to deal with outliers.