Skip to content

Conversation

@StuartLittlefair
Copy link
Contributor

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_time are now attached to each Time object. These helper routines, heliocentric_correction and barycentric_correction return TimeDelta objects, which can be added to a Time object to create a heliocentric or barycentric corrected time.

An example usage

from astropy import coordinates as coord, units as u
from astropy.time import Time

wht  = coord.EarthLocation.of_site('lap alma')
star = coord.SkyCoord("08:08:08 +32:00:00",distance=120*u.pc,unit=(u.hour,u.degree),frame='icrs')
t = Time("2013-02-02T23:00")
t.location = wht
hcor_val = t.heliocentric_correction(star)
bcor_val = t.barycentric_correction(star)

# the returned timedelta objects can be added to the original time
hcor = t + hcor_val
bcor = t + bcor_val
print(' MJD (UTC)  = %.11f' % t.mjd)
print(' MJD (TT)   = %.11f' % t.tt.mjd)
print(' MJD (TDB)  = %.11f' % t.tdb.mjd)
print('HMJD (UTC)  = %.11f' % hcor.utc.mjd)
print('HMJD (TT)   = %.11f' % hcor.tt.mjd)
print('HMJD (TDB)  = %.11f' % hcor.tdb.mjd)
print('BMJD (UTC)  = %.11f' % bcor.utc.mjd)
print('BMJD (TT)   = %.11f' % bcor.tt.mjd)
print('BMJD (TDB)  = %.11f' % bcor.tdb.mjd)
print("Correction to add to get time at heliocentre = {} seconds".format(hcor_val))
print("Correction to add to get time at barycentre = {} seconds".format(bcor_val))

@eteq
Copy link
Member

eteq commented Nov 17, 2015

@StuartLittlefair - before doing a detailed review, there are some conceptual bits I'm confused by here. In the docstrings you call Heliocentric "relative to the Earth's center-of-mass rather than the solar system Barycenter". Why is that "Heliocentric"? (Or is that maybe a typo?) Similarly, in #4314 you mention the need for a barycentric coordinate system, but that's not in here. Am I right in interpreting this code that you've decided that ICRS is right for those purposes?

@StuartLittlefair
Copy link
Contributor Author

@eteq Thanks for the questions.

  1. Yes - I meant relative to the Sun's centre of mass in the docstrings. I'll make that change.
  2. w.r.t to Add support for heliocentric coordinate frames and barycentric/heliocentric time corrections #4314 I did indeed realise that ICRS is fine for this purpose since it is a Barycentric coordinate system. Moreover, since it's the coordinate system in which the star's vector is most commonly given, it is ideal for calculating light travel times

Copy link
Contributor

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)

Copy link
Contributor Author

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.

@mhvk
Copy link
Contributor

mhvk commented Nov 17, 2015

@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 Time can be combined (either using a private method or by defining a method that allows the user to choose between barycentric and heliocentric; I think I prefer the latter, with the option set by strings rather than the coordinate class; this has an analogy in how sidereal_time is implemented, with its options for kind).

@mhvk
Copy link
Contributor

mhvk commented Nov 17, 2015

One important aspect will be to document it well. In particular, to get barycentric times, one would do,

t_barycentre = time.tdb + time.barycentric_correction(coord)

By returning a TimeDelta on the TDB scale, you already ensure any errors from not doing .tdb as above (but perhaps after the addition) are minimized, but it is probably good if the docstring and documentation make abundantly clear that in the barycentre one should use tdb.

Copy link
Contributor

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.

@mhvk
Copy link
Contributor

mhvk commented Nov 17, 2015

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...

Copy link
Contributor

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.)

Copy link
Contributor Author

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?

@StuartLittlefair
Copy link
Contributor Author

I've pushed a lot of changes to address @mhvk's comments.

I've also attempted to rebase to bring this in line with #4302 following the instructions in the astropy docs. This is new to me and exceeds my git comfort levels, so I apologise if i stuffed it up.

Copy link
Contributor

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).

@mhvk
Copy link
Contributor

mhvk commented Mar 23, 2016

OK, tests now passed, so merging. Thanks very much, @StuartLittlefair, for fixing this very longstanding issue of not being able to calculate barycentric corrections!

@mhvk mhvk merged commit 4f86d0e into astropy:master Mar 23, 2016
@eteq
Copy link
Member

eteq commented Mar 23, 2016

Oops, missed that there was some recent progress here not related to climbing... But it looks great, thanks @StuartLittlefair and @mhvk!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add Heliocentric and Barycentric frames to coordinates Add support for Heliocentric and Barycentric Julian Dates

9 participants