-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Add support for heliocentric coordinate frames and barycentric/heliocentric time corrections #4314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@StuartLittlefair - before doing a detailed review, there are some conceptual bits I'm confused by here. In the docstrings you call |
|
@eteq Thanks for the questions.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Putting in comments as I look over things, some of which may be quite nitpicky: Getting the unit here by converting to cartesian seems extremely expensive. I think this would do
not all(c.unit.is_equivalent((u.one, u.radian)) for c in grcs_coo.data.components)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code you suggest doesn't work - gcrs_coo.data.components gives a tuple of strings - (lat, lon) for example. I don't think it's that expensive either, since the cartesian representation is only calculated if the first condition is not true, which I think it always should be.
|
@StuartLittlefair - This looks great! As you'll have seen, I have only very minor comments, except that I think the code for the two corrections in |
|
One important aspect will be to document it well. In particular, to get barycentric times, one would do, By returning a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is covered by #4302 -> needs a rebase.
|
Ah, yes, another one worth bringing outside of the in-line comments is that you currently assume the distance to the object is far larger than the distance between the observatory and the barycentre. In principle, this is not necessary (though in practice one has to do the trigonometry carefully to ensure one does well in the small-angle limit). Not sure it is worth addressing here... |
astropy/time/core.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the dot only words for scalar tcor and spos; should it be (spos * hpos).sum(axis=-1) / const.c? (This leaves properly broadcasting up to the user.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
playing around with this it looks like this should be (spos*cpos).sum(axis=0) / const.c?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're not using EQUINOX_J2000 (also missing end of line at end of file).
|
OK, tests now passed, so merging. Thanks very much, @StuartLittlefair, for fixing this very longstanding issue of not being able to calculate barycentric corrections! |
|
Oops, missed that there was some recent progress here not related to climbing... But it looks great, thanks @StuartLittlefair and @mhvk! |
This pull request fixes #2244, fixes #4288, and adds tests for the GCRS<->ICRS transformations in #4268. The idea is that helper routines, similar to
sidereal_timeare now attached to eachTimeobject. These helper routines,heliocentric_correctionandbarycentric_correctionreturnTimeDeltaobjects, which can be added to a Time object to create a heliocentric or barycentric corrected time.An example usage