Add ecliptic frames and transforms - #3749

My primary use case doesn't depend on any of these high levels of precision: ecliptic coordinates are the natural frame for calculating target observability by JWST, which will be in an ecliptic orbit and has a field of regard and constraints on spacecraft orientation that are naturally expressed in ecliptic coordinates. For many pre-launch planning purposes one doesn't need any precision better than half a degree or so (which is a typical offset between spacecraft-local coordinates and Earth-centered), at least not for user tools for e.g. "is it at all feasible to observe my target with the instrument field of view oriented in some particular desired manner?". So thanks for doing this, I can't comment on any very technically demanding applications, and the choices you have made seem reasonable to me.

Great! I can't comment on the questions since I'm not familiar with the system

Note that we did set up a comparison of ecliptic coordinates in the coordinates-benchmark repo so we should try it out there.

@scottransom @aarchiba - since you both do pulsars, which sometimes use ecliptic coordinates (is that right?) maybe you can comment on the accuracy aspects?

Hi Erik,

Thanks for continuing along in the Ecliptic Coordinate transforms. These will be very helpful for the Solar System community.

1: I don’t often work in GCRS, I know some people who do and will ask for their opinions. My understanding that what you have done is correct. My limited experience is using this reference frame is typical for spacecraft plotting.

2: The simple rotation is what is normally done. However, people go to heliocentric and barycentric and back and forth quite a bit. Each reference point has its own plusses. That is particularly true when comparing measured orbits (often expressed in barycentric) to model orbits (often done in heliocentric).

3: I’m think you are correct but will consult some of the spacecraft folks.

JJ

On May 3, 2015, at 10:41 AM, Erik Tollerud [email protected] wrote:

eteq wants to merge 2 commits into astropy:master from eteq:add-ecliptic-frames:

This closes #1430 #1430 by adding frames (and transforms into the rest of the coordinate graph) for ecliptic coordinates.

As implemented here I think everything is at least internally self-consistent, but before merging it would be useful to hear from some people who actually use ecliptic coordinates, because I had trouble finding authoritative definitions of exactly how such coordinates are defined (like many coordinate frames...). So @mperrin https://github.com/mperrin, @mtbannister https://github.com/mtbannister, @ijiraq https://github.com/ijiraq, @Cadair https://github.com/Cadair, or anyone else who uses these systems, maybe you can comment on the following uncertainties:

There's two systems here, one for geocentric and the other for heliocentric. The former I've defined relative to GCRS, so it nominally includes effects like aberration and GR light deflection by the sun/planets. Is that what's normally assumed? It doesn't really matter "internally" - that is, if you just want to use ecliptic coordinates relative to each other. But it does matter if you want to convert to ICRS or AltAz or various other systems (because the light deflection and such will then need to be un-done).
The heliocentric version is simply a rotation to the equinox of date and obliquity, relative to ICRS. This then does not include the above effects. It also means it's not strictly heliocentric, but rather solar system barycentric. My thinking is that for ecliptic coordinates the barycenter is actually a more useful origin than the center of the sun itself (although of course they are very close). But someone more familiar with how this is used might be able to comment better.
For simplicity/less confusion here, both frames only include an equniox frame attribute. For the geocentric one, one could conceivably also have an obstime, which would set the location of the Earth, independent of the orientation of the axes (that is equinox would set where the 0-meridian is, while obstime would determine where the origin is based on the Earth's location). That seems really confusing, so I am implcitly always assuming these are the same. But are there applications where it's useful to have the orientation fixed to a particular equinox but the earth location be somewhere that does not match that equinox?
Also needs a changelog entry, which I'll add once the above issues are addressed.
cc @adrn https://github.com/adrn @mhvk https://github.com/mhvk
You can view, comment on, or merge this pull request online at:

#3749 #3749
Commit Summary

move cartrepr_from_matmul to utils
add ecliptic systems and transforms
File Changes

M astropy/coordinates/builtin_frames/init.py https://github.com/astropy/astropy/pull/3749/files#diff-0 (4)
A astropy/coordinates/builtin_frames/ecliptic.py https://github.com/astropy/astropy/pull/3749/files#diff-1 (97)
A astropy/coordinates/builtin_frames/ecliptic_transforms.py https://github.com/astropy/astropy/pull/3749/files#diff-2 (69)
M astropy/coordinates/builtin_frames/intermediate_rotation_transforms.py https://github.com/astropy/astropy/pull/3749/files#diff-3 (19)
M astropy/coordinates/builtin_frames/utils.py https://github.com/astropy/astropy/pull/3749/files#diff-4 (27)
Patch Links:

https://github.com/astropy/astropy/pull/3749.patch https://github.com/astropy/astropy/pull/3749.patch
https://github.com/astropy/astropy/pull/3749.diff https://github.com/astropy/astropy/pull/3749.diff
—
Reply to this email directly or view it on GitHub #3749.

In pulsar astronomy, the chief use of ecliptic coordinates is as a better parametrization when one is fitting for a pulsar position - the error ellipse is more likely to be axis-aligned. So to make us happy the transforms should agree with those in tempo/tempo2 (e.g. in the function convertEcliptic here: http://tempo2.cvs.sourceforge.net/viewvc/tempo2/tempo2/sw_delay.C?view=markup ) which appear to be a simple rotation (unless there's a different implementation squirrelled away somewhere else; don't ask). No aberration, no light bending, and measured from the solar system barycenter.

Ok, so @aarchiba, that probably means what's called HeliocentricEcliptic here works for you, right? (except that perhaps it should be renamed BarycentricEcliptic or something like that, a la my next paragraph.)

Given @ijiraq's comments, that probably means there should be both a HeliocentricEcliptic and a BarycentricEcliptic, is that right? So that would involve renaming what's currently called HeliocentricEcliptic to BarycentricEcliptic and adding a HeliocentricEcliptic that's identical but with the origin offset a bit to match the sun center instead of the SSB. Is that what you mean by barycentric vs. heliocentric, @ijiraq? That is, neither would have any kind of abberation or light deflection?

Your Helio/Bary distinction is correct. Having both would be very helpful.

I did not get response from spacecraft colleges regarding geocentric issues raised before. I'm speaking with them directly on Thursday so will see if I can get some comment then.

JJ

On May 5, 2015, at 11:56 AM, Erik Tollerud [email protected] wrote:

Ok, so @aarchiba, that probably means what's called HeliocentricEcliptic here works for you, right? (except that perhaps it should be renamed BarycentricEcliptic or something like that, a la my next paragraph.)

Given @ijiraq's comments, that probably means there should be both a HeliocentricEcliptic and a BarycentricEcliptic, is that right? So that would involve renaming what's currently called HeliocentricEcliptic to BarycentricEcliptic and adding a HeliocentricEcliptic that's identical but with the origin offset a bit to match the sun center instead of the SSB. Is that what you mean by barycentric vs. heliocentric, @ijiraq? That is, neither would have any kind of abberation or light deflection?

—
Reply to this email directly or view it on GitHub.

Ok, I've made the trivial change of renaming Heliocentric to Barycentric, but I'll hold off on updating this any further to hear what your colleagues say, @ijiraq . Unless they say otherwise I'll plan to make the changes I said above and leave it at that.

One other question/ambiguity occurred to me: here I'm assuming the preferred equinox is the true equinox of date (i.e., both precession and nutation), but another option would be the mean equinox of date (precession but not nutation). @aarchiba, do you know if that's the convention that applied for pulsar work? And @ijiraq, you might want to ask about that too.

Also, @aarchiba, do you think you can try comparing the Barycentric one to some "known good" datasets you might have (or can generate with tempo2)? That would be a useful test to include...

It's a pain to get numbers out of tempo/tempo2. But for reference: http://stsdas.stsci.edu/astrolib/coords_api/public/coords.position.Position-class.html#ecliptic https://pythonhosted.org/PyTPM/conversions.html

astrolib and PyTPM are both in the coordinates-benchmark repo: https://github.com/astropy/coordinates-benchmark so it would make sense to now update those benchmarks to do ecliptic and compare to this branch (cc-ing @cdeil since he's done a lot of work on the benchmarks)

Has anyone had a chance to test this out? It would be great to have in 1.1!

@eteq How is the ecliptic formally defined? I am just thinking that going from true heliocentric ecliptic to heliographic coordinates might be more trivial than the direct FK5 -> HGS that we were discussing at pyastro??

@astrofrog / others: if others don't have time to test this I can try to massage this into the coordinates benchmark with PyTPM.

Still wondering about the true/mean equinox question, though. I suppose we could expand this into six systems: GeocentricTrueEcliptic, BarycentricTrueEcliptic, HeliocentricTrueEcliptic, GeocentricMeanEcliptic,BarycentricMeanEcliptic, HeliocentricMeanEcliptic... That wouldn't be too much work really.

Alright, I've pushed up a change to this which adds a HeliocentricTrueEcliptic, adds the "True" to the other names, but does not add the "mean" versions. It also now adds tests, although they are very rudimentary as "accuracy" tests, using just a few examples, and a changelog entry.

The idea is that we clearly are having trouble finding good test cases (or at least the right people who have opinions about what "good" counts as). So adding this now will give us a user base who can help us out with that. Hence, the final commit here adds warnings to the docs that basically say "we don't have good accuracy tests, so use at your own risk... but please help us if you do figure it out." I think that's the best way to go for 1.1. If so (and the tests pass) I think this is good to go, and when merged we can immediately add an issue about adding better accuracy tests. Sound ok, @astrofrog @embray?

(And @Cadair - to answer your question I left hanging above: my impression is that there is not a clear "formal" definition of what it means, because there are a bunch of subtly different versions - e.g. the true/mean equinox question, what the origin of your coordinate system is if you care about 3D effects instead of just the spherical geometry, etc)

@eteq - sounds good to me. I wonder if it would be good to add a warning in the main docs too? Otherwise this looks good to me.

Alright, I did as you suggested @astrofrog, and added a note into the docs index. I'll go ahead and merge this, then, although if anyone else manages to get some tests cases in we can certainly update that if it comes before the release.

(Also, hooray on this closing a 2+ year-old issue - #1430!)

Thanks very much for adding and closing. I think we have a graduate student lined up to do some testing. Will keep you all informed.

JJ

On Sep 29, 2015, at 3:48 PM, Erik Tollerud [email protected] wrote:

(Also, hooray on this closing a 2+ year-old issue!)

—
Reply to this email directly or view it on GitHub.

Thanks @eteq!

And @ijiraq - great to hear that you have a grad student lined up to do testing of this :)

I suspect (but cannot prove) that the NEOS lookup database of JPL uses heliocentric mean ecliptic coordinates:

http://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2003122

We had some discussion about it in poliastro, which is summarized here:

https://github.com/poliastro/poliastro/wiki/Reference-frames#small-bodies-coordinates

I understand that there are no authoritative, good definitions of ecliptic reference frames. However, I would like to quickly prove if a mean ecliptic fits better the results I'm getting from JPL - my tests suggest that neither HeliocentricTrueEcliptic nor BarycentricTrueEcliptic do the trick. Is there a (hackish?) way to transform from true to mean ecliptic with the tools that Astropy offers today?

Adding a direct ping to @eteq

Well, I think I am closer to solving the mistery. My conclusions are here:

poliastro/poliastro#222 (comment)

By the information shown in the output of Horizons, I think I need a mean ecliptic with the obliquity of IAU80. To implement this, I guess I would need to copy this fragment:

https://github.com/astropy/astropy/blob/v2.0.1/astropy/coordinates/builtin_frames/ecliptic_transforms.py#L24-L28

And change:

• From erfa.pnm06a to erfa.bp06, and use the bias matrix (if I would want a generic mean-of-date, I would use the bias-precession)
• From erfa.obl06 to erfa.obl80, to compute the obliquity with respect to the equator of IAU76.

Does this sound plausible? The relative differences in obliquity are of the order 1e-7, but even so I would like something that is as close as their solution as possible.

With change I mean "adding a new _mean_iau76_ecliptic_rotation_matrix function" and a corresponding frame in ecliptic.py, of course.

@Juanlu001 @adrn - I wonder whether something like this is related to #6461?

@astrofrog I was not aware of that issue. Let's move the discussion there.

To clarify: this probably won't save me from implementing my own system, since the new ecliptic transformations present in SOFA/ERFA use the models of IAU2000, and I want something... older.

@Juanlu001 - indeed, let's move discussion to #6461 - maybe you can copy your conclusion there? It sounds to me like we'll have to support the older version regardless of whether it is directly in erfa.