Add astrometry example about exoplanet

[dfm]

@iancze and I have been chatting offline and we're hoping to work on this. Here are some open questions from Ian:

1. coordinate convention about the ascending node: is it the one receeding from the observer or approaching the observer? My personal preference is that of the visual binary field, discussed in the document I linked. It yields to a consistent right hand rule system. The choice of the exoplanet field seems to be to use the opposite convention (perhaps more common in planetary science), though this may just be from following Murray and Correia. I can defer to whatever you think makes most sense, but the inconsistencies within the exoplanet field are what drove me to write that document in the first place.

2. format of data. Usually this would be measurement of the secondary relative to the primary as separation and position angle, but maybe other people have more exotic formats. For hierarchical systems, say C orbits a tighter binary A-B, the formats I have usually seen are B relative to A and C relative to A, OR C relative to the photocenter of AB. Other types of measurements could exist.

3. properly generalizing the orbits to hierarchical systems. Perhaps you might have already solved this organizational problem with the RV orbits.

I haven't solved any of these problems and I don't have enough experience to have strong opinions (yet!).

There's an implementation of this in: https://github.com/iancze/PSOAP/blob/master/psoap/orbit_astrometry.py

@iancze: want to post your overleaf doc here too? Or some other copy of your notes?

[iancze]

Sure thing. Here are some notes for an internally consistent convention (following the visual binary field) that I've been using for my work: https://v2.overleaf.com/read/wszkgttktyvg

The inconsistencies I think I noted were the swapping of a negative sign in the equation for radial velocity v_r and v_z in the Murray and Correia notes, or at least, my misunderstanding of something related to that.

There are also a number of other systems I've seen that don't conform to the right-hand rule. I think we might want to stay away from those.

[iancze]

Just a note that I have made some progress on this on a fork of the repo, e.g., https://github.com/iancze/exoplanet/blob/master/docs/notebooks/astrometric.ipynb

I'll work on flushing out the functionality and tutorial before thinking about how to put together a proper a pull request.

[iancze]

Some changes to KeplerianOrbit to include astrometry

• change t_ref to t_periastron, let t0 be time of transit (time of minimum impact parameter if non-transiting). Add both to __init__, then add logic to ensure user only specifies one at a time.
• add Omega to KeplerianOrbit. Tinker with rotate_vector to include position angle rotation.
• get_consistent_inputs needs to have logic to sort out astrometric parameters. Possible include kappa to the __init__ values. Then modify consistent_inputs to return m_planet values. Either compute kappa from m_planet OR compute m_planet from kappa.

[iancze]

After our work on this today, I think we finally have a working implementation for astrometric orbits over at https://github.com/iancze/exoplanet/blob/keplerian-astrometric/docs/notebooks/astrometric.ipynb, which converges when using the xo.PyMC3Sampler to tune.

The changes to orbits/keplerian.py are probably ready to merge, although I should write some tests to be sure. My next step is to round out the tutorial with notes on how to do a joint RV + astrometric fit.