Fwd: [AstroPy] Heliocentric Julian Date HJD

[Erik Tollerud]

This is from the astropy list.  I'm wondering if we want to implement HJD in astropy?

The funny thing about Heliocentric Julian Dates (and their cousin, BJD) is that they depend on where you're looking, so they aren't a simple timescale.  So the question is how this could fit into the existing `Time` framework.  Currently we have some time scales that depend on location on the earth, so in principal this could be done the same way, but then we'd have to add further attributes to `time` that don't really make sense in other contexts.  

So perhaps this is a call to not store `lat/lon` in Time, but rather in an `EarthLocation`.  Then we can treat BJD/HJD the same way, but using the celestial coordinate objects instead of `EarthLocation`?

---------- Forwarded message ----------
From: Leticia Rodriguez <lrodr...@iafe.uba.ar>
Date: Mon, Mar 17, 2014 at 10:00 AM
Subject: [AstroPy] Heliocentric Julian Date HJD
To: "<ast...@scipy.org>" <ast...@scipy.org>

Hi,

I need to find out the Observational Date (timestamp) from a HJD value.

I have a function that  it converts from MJD to Timestamp. I could use this function converting first from HJD to MJD.

Or just use a function that it converts from HJD to Timestamp.

Does anyone know any function to convert from HJD to MJD or HJD to Timestamp in any python library?

Thanks

Leticia.

--

Leticia Lorena Rodríguez

Technical Contact 

NOVA - Virtual Observatory Argentina
http://nova.conicet.gov.ar

_______________________________________________
AstroPy mailing list
Ast...@scipy.org
http://mail.scipy.org/mailman/listinfo/astropy

--

Erik T

[Tim Jenness]

On Wed, Mar 26, 2014 at 8:05 AM, Erik Tollerud <erik.t...@gmail.com> wrote:

This is from the astropy list.  I'm wondering if we want to implement HJD in astropy?

The funny thing about Heliocentric Julian Dates (and their cousin, BJD) is that they depend on where you're looking, so they aren't a simple timescale.  So the question is how this could fit into the existing `Time` framework.  Currently we have some time scales that depend on location on the earth, so in principal this could be done the same way, but then we'd have to add further attributes to `time` that don't really make sense in other contexts.  

So perhaps this is a call to not store `lat/lon` in Time, but rather in an `EarthLocation`.  Then we can treat BJD/HJD the same way, but using the celestial coordinate objects instead of `EarthLocation`?

I agree that replacing bare "lat/lon" with an object would give us more flexibility. For some spectral coordinate frames we also need to know where we are and where we are looking, and obviously you have azimuth, elevation coordinates. Presumably some thought is required in dealing with a location in the time and a location in the coordinate when we are associating a time with a coordinate (and what do we do if the coordinate has a different location to the time object).

-- 

Tim Jenness

 

[Aldcroft, Tom]

On Wed, Mar 26, 2014 at 11:31 AM, Tim Jenness <tim.j...@gmail.com> wrote:

On Wed, Mar 26, 2014 at 8:05 AM, Erik Tollerud <erik.t...@gmail.com> wrote:

This is from the astropy list.  I'm wondering if we want to implement HJD in astropy?

The funny thing about Heliocentric Julian Dates (and their cousin, BJD) is that they depend on where you're looking, so they aren't a simple timescale.  So the question is how this could fit into the existing `Time` framework.  Currently we have some time scales that depend on location on the earth, so in principal this could be done the same way, but then we'd have to add further attributes to `time` that don't really make sense in other contexts.  

So perhaps this is a call to not store `lat/lon` in Time, but rather in an `EarthLocation`.  Then we can treat BJD/HJD the same way, but using the celestial coordinate objects instead of `EarthLocation`?

It's easy enough in Time to add attributes that are available for doing transformations.  So you are suggesting to replace Time.lat/lon with e.g. Time.earth_location, and then add something like Time.sky_coordinate? 

 

I agree that replacing bare "lat/lon" with an object would give us more flexibility. For some spectral coordinate frames we also need to know where we are and where we are looking, and obviously you have azimuth, elevation coordinates. Presumably some thought is required in dealing with a location in the time and a location in the coordinate when we are associating a time with a coordinate (and what do we do if the coordinate has a different location to the time object).

It seems like there should be a way to thread through these issues, but I agree it requires some thought.

- Tom

-- 

Tim Jenness

 

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Erik Tollerud]

It's easy enough in Time to add attributes that are available for doing transformations.  So you are suggesting to replace Time.lat/lon with e.g. Time.earth_location, and then add something like Time.sky_coordinate? 

That's one possibility (I definitely think we want to replace `lat`/`lon` with `earth_location` once `EarthLocation` exists, but I think there's already agreement on that?).  

A second option is to not have these be `Time` attributes at all, but rather require a transformation function or something like that to go from TDB to something else (or from something else to BJD/HJD).  This goes back to the discussion around `sidereal_time`: there are some contexts where it's not really clear if `Time` should be an attribute of a coordinate, or if the coordinate should be an attribute of `Time`.  So to prevent confusion, I was advocating neither - instead, use a function that must be given both.  I'm not sure that's the best solution here, but it's something to consider, at least.

 

 

I agree that replacing bare "lat/lon" with an object would give us more flexibility. For some spectral coordinate frames we also need to know where we are and where we are looking, and obviously you have azimuth, elevation coordinates. Presumably some thought is required in dealing with a location in the time and a location in the coordinate when we are associating a time with a coordinate (and what do we do if the coordinate has a different location to the time object).

It seems like there should be a way to thread through these issues, but I agree it requires some thought.

Definitely - but at first thought, I *think* it should be possible to abstract this into the `coordinates` framework - that is, `sky_coordinate` could be any kind of valid sky coordinate, and it can be left to `coordinates` to transform to whatever form is actually needed.  There's some possible issues with circularity (i.e., a coordinate needs the Time to know how to do the transform, but Time needs a coordinate to do *its* transform), but it may be that's not an issue with a suitably structured implementation.

 

- Tom

-- 

Tim Jenness

 

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Erik T

[Thomas Robitaille]

On 26 Mar 2014, at 23:00, Erik Tollerud <erik.t...@gmail.com> wrote:

It's easy enough in Time to add attributes that are available for doing transformations.  So you are suggesting to replace Time.lat/lon with e.g. Time.earth_location, and then add something like Time.sky_coordinate? 

That's one possibility (I definitely think we want to replace `lat`/`lon` with `earth_location` once `EarthLocation` exists, but I think there's already agreement on that?).  

Just a minor point - this should be Time.location (which could end up being set to EarthLocation, SpacecraftLocation, MarsLocation, etc), as earth_location would be too constraining, right?

Tom

[Erik Tollerud]

Yeah, that's a good point.  To be fully general, I guess it's that we need a `from_location` and a `to_location`.  That is, HJD/BJD care about what you're looking *at*, while TBD cares about where you're observing *from*.  There's probably some better name for that, though - it's not really obvious that `to_location` is typically a celestial coordinate.

[Aldcroft, Tom]

On Wed, Mar 26, 2014 at 6:00 PM, Erik Tollerud <erik.t...@gmail.com> wrote:

It's easy enough in Time to add attributes that are available for doing transformations.  So you are suggesting to replace Time.lat/lon with e.g. Time.earth_location, and then add something like Time.sky_coordinate? 

That's one possibility (I definitely think we want to replace `lat`/`lon` with `earth_location` once `EarthLocation` exists, but I think there's already agreement on that?).  

A second option is to not have these be `Time` attributes at all, but rather require a transformation function or something like that to go from TDB to something else (or from something else to BJD/HJD).  This goes back to the discussion around `sidereal_time`: there are some contexts where it's not really clear if `Time` should be an attribute of a coordinate, or if the coordinate should be an attribute of `Time`.  So to prevent confusion, I was advocating neither - instead, use a function that must be given both.  I'm not sure that's the best solution here, but it's something to consider, at least.

When I look at this a bit more closely I agree that BJD/HJD makes sense as more of a utility function rather than part of the core Time class.

- Tom

[Aldcroft, Tom]

I opened issue #2244 (https://github.com/astropy/astropy/issues/2244).  I would propose moving discussion of this particular issue onto github now since it should mostly be about implementation details at this point.

- Tom

On Wed, Mar 26, 2014 at 6:49 PM, Erik Tollerud <erik.t...@gmail.com> wrote:

Yeah, that's a good point.  To be fully general, I guess it's that we need a `from_location` and a `to_location`.  That is, HJD/BJD care about what you're looking *at*, while TBD cares about where you're observing *from*.  There's probably some better name for that, though - it's not really obvious that `to_location` is typically a celestial coordinate.

On Wed, Mar 26, 2014 at 6:19 PM, Thomas Robitaille <thomas.r...@gmail.com> wrote:

On 26 Mar 2014, at 23:00, Erik Tollerud <erik.t...@gmail.com> wrote:

It's easy enough in Time to add attributes that are available for doing transformations.  So you are suggesting to replace Time.lat/lon with e.g. Time.earth_location, and then add something like Time.sky_coordinate? 

That's one possibility (I definitely think we want to replace `lat`/`lon` with `earth_location` once `EarthLocation` exists, but I think there's already agreement on that?).  

Just a minor point - this should be Time.location (which could end up being set to EarthLocation, SpacecraftLocation, MarsLocation, etc), as earth_location would be too constraining, right?

Tom

A second option is to not have these be `Time` attributes at all, but rather require a transformation function or something like that to go from TDB to something else (or from something else to BJD/HJD).  This goes back to the discussion around `sidereal_time`: there are some contexts where it's not really clear if `Time` should be an attribute of a coordinate, or if the coordinate should be an attribute of `Time`.  So to prevent confusion, I was advocating neither - instead, use a function that must be given both.  I'm not sure that's the best solution here, but it's something to consider, at least.

 

--

Erik T

--

Erik T

I opened issue #2244 (https://github.com/astropy/astropy/issues/2244).  I would propose moving discussion of this particular issue onto github now since it should mostly be about implementation details at this point.

- Tom

[Stuart Mumford]

Hello,

This just caught my attention. There has been a small bit of discussion between the SunPy devs about a general 'Observer' class. Mainly to deal with knowing where observations were taken from to deal with incomplete WCS headers etc.

I am wondering if making this slightly more general than Time is of interest to anyone else?

Stuart

[Erik Tollerud]

Hi Stuart,

This is definitely something on the horizon, although I think most of the discussion thus far has been between Marten and I.  We had talked about an "Observatory" class, which would be a subclass of `EarthLocation` (although as I say, that, a more general `Location` is necessary here, given that SunPy and perhaps others would want to allow observer locations like satellites and such).  This would contain the location information, *and* extra information like lists of telescopes at that location and maybe (down the road)  instruments on those telescopes,instrument parameters, and the like.

Is that the sort of thing you were thinking of?

[Wilfred Tyler Gee]

On Thursday, March 27, 2014 at 5:43:38 AM UTC-10, Erik Tollerud wrote:

Hi Stuart,

This is definitely something on the horizon, although I think most of the discussion thus far has been between Marten and I.  We had talked about an "Observatory" class, which would be a subclass of `EarthLocation` (although as I say, that, a more general `Location` is necessary here, given that SunPy and perhaps others would want to allow observer locations like satellites and such).  This would contain the location information, *and* extra information like lists of telescopes at that location and maybe (down the road)  instruments on those telescopes,instrument parameters, and the like.

Is that the sort of thing you were thinking of?

We are implementing something like this as part of our small observatory control system (https://github.com/panoptes/POCS). We use astropy as much as possible and I keep thinking that someone else must have some similar Observatory class. Anyone doing work on this or did this thread go elsewhere?  My basic class right now has:

        self.location = None # EarthLocation

        self.altaz = None # AltAz

        self.horizon = 30 * u.degree

        self.gmt_offset = 0 * u.minute

        self.elevation = 0 * u.meter

        self.air_pressure = 0 * u.millibarye

Along with knowledge of our mounts, cameras, scheduler, weather sensors, etc.. 

I want to be able to ask basic questions about observability from location on given dates, etc.

I know others are doing similar things so just want to see if there is interest in creating a more generic astro-obs astropy affiliated package and what others might need out of that.

Aloha,

[Brett Morris]

Hi Wilfred, 

We're working on something just like the Observatory class that you're requesting in an astropy-affiliated package called astroplan, which is currently in development (see the Observer class, specifically). We're still developing the docs and implementing useful pieces, but we're hoping for a v0.1 release in the next few weeks. Keep your eyes peeled for that release soon!

Brett

[Erik Bray]

On Tue, Aug 11, 2015 at 4:59 PM, Brett Morris <nasa...@gmail.com> wrote:
> Hi Wilfred,
>
> We're working on something just like the Observatory class that you're
> requesting in an astropy-affiliated package called astroplan, which is
> currently in development (see the Observer class, specifically). We're still
> developing the docs and implementing useful pieces, but we're hoping for a
> v0.1 release in the next few weeks. Keep your eyes peeled for that release
> soon!

Sounds like the sort of thing where you all might want to combine your
efforts--see what astroplan is doing and what requirements of PANOPTES
the design fulfills (and more interestingly which ones it doesn't--I
wouldn't be surprised if something like PANOPTES has some different
use cases?)

The Observer class in astroplan already looks pretty similar to the
one describe:

https://github.com/astroplanners/astroplan/blob/master/astroplan/core.py#L108

(it doesn't have a horizon attribute currently, but one could imaging
setting a default horizon to use for calculations that use it?)

Erik

[Wilfred Tyler Gee]

Yeah, that's great, thanks Brett. Panoptes will indeed use something similar and I'm going to see if I can't just use that as a base class for our concept of Observatory. Our system is fundamentally an observatory control system (OCS) so does more than just what astroplan is doing but if we can use it and contribute back that would be great.

Thanks for responses.

You received this message because you are subscribed to a topic in the Google Groups "astropy-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/astropy-dev/5KH5Ny1m6WY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to astropy-dev...@googlegroups.com.

[Marten van Kerkwijk]

Hi All,

Yes, an observatory class would be great. Please do use/improve also my early attempt in `astropy.coordinates.earth.EarthLocation`. To get a sense what one would eventually need in terms of horizons, VLBI .vex files have entries like the one below -- ideally, one would read these using a `from_vex` class method... (the horizon could just be a property that interpolates in a list like that given).

All the best,

Marten

def VLBA_BR;
   site_type = fixed;
   site_name = VLBA_BR;
   site_ID = Br;
   site_position = -2112065.2265 m : -3705356.5009 m : 4726813.6591 m;
   site_velocity = 0 cm/yr : 0 cm/yr : 0 cm/yr;
   horizon_map_az = 0.0 deg : 5.0 deg : 10.0 deg : 15.0 deg : 25.0 deg : 30.0 deg : 40.0 deg : 45.0 deg : 70.0 deg : 75.0 deg : 120.0 deg : 125.0 deg : 130.0 deg : 135.0 deg : 155.0 deg : 160.0 deg : 185.0 deg : 190.0 deg : 195.0 deg : 220.0 deg : 225.0 deg : 235.0 deg : 240.0 deg : 245.0 deg : 250.0 deg : 255.0 deg : 265.0 deg : 270.0 deg : 275.0 deg : 300.0 deg : 305.0 deg : 310.0 deg : 315.0 deg : 330.0 deg : 335.0 deg : 340.0 deg : 345.0 deg : 350.0 deg : 360.0 deg;
   horizon_map_el = 2.0 deg : 2.0 deg : 3.0 deg : 2.0 deg : 2.0 deg : 3.0 deg : 3.0 deg : 4.0 deg : 4.0 deg : 5.0 deg : 5.0 deg : 4.0 deg : 4.0 deg : 3.0 deg : 3.0 deg : 2.0 deg : 2.0 deg : 3.0 deg : 4.0 deg : 4.0 deg : 3.0 deg : 3.0 deg : 4.0 deg : 4.0 deg : 5.0 deg : 6.0 deg : 6.0 deg : 5.0 deg : 6.0 deg : 6.0 deg : 5.0 deg : 6.0 deg : 5.0 deg : 5.0 deg : 4.0 deg : 4.0 deg : 3.0 deg : 2.0 deg : 2.0 deg;
enddef;