Mailman 3 নভেম্বর 2020 - AstroPy

consistency of reference frames between SkyCoord and JPL Horizons
by Paolo Tanga 27 জানুয়ারি, 2021

27 জানুয়ারি, 2021

Hi all I am trying to plug the results by JPL Horizons into the appropriate reference system of a SkyCoord object, but it looks very trick. (bewore long message, I hope the explanation is clear for the specialists of reference systems) The Horizons server returns two types of equatorial coordinates: "astrometric" (1) and (2) "apparent". Their description is the following: - (1): astrometric RA and Dec with respect to the observing site (coordinate origin) in the reference frame of the planetary ephemeris (ICRF). Compensated for down-leg light-time delay aberration. - (2): Airless apparent RA and Dec of the target with respect to an instantaneous reference frame defined by the Earth equator of-date (z-axis) and meridian containing the Earth equinox of-date (x-axis, IAU76/80). Compensated for down-leg light-time delay, gravitational deflection of light, stellar aberration, precession & nutation. Note: equinox (RA origin) is offset -53 mas from the of-date frame defined by the IAU06/00a P & N system. My guess is none of these two systems correspond to either ICRS or GCRS as defined in astropy. The simplest possibility for me, would have been to assimilate (1), computed for the Solar System barycenter, to ICRS. But definitely (2) is not GCRS and the test below easily proves that. Verification (see the attached notebook if you want to play with) : - I queried for Solar System barycentric coordinates (1) of an asteroid at one epoch. I inserted them in a SkyCoord object as ICRS and use the transform_to(GCRS) towards geocentric, at the given epoch. - I queried again JPL Horizons for the apparent coordinates (2) from the geocenter, directly. As expected, by comparing the results I get the patent confirmation that GCRS is not the frame of (2), with a discrepancy of 16 arcmin in my case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put apparent coordinates (2) aside for the moment. Second possibility (see notebook again). I take coordinates (1), for the geocentric observer. I insert them as GCRS in a SkyCoord object. I trasform_to(ICRS) (barycentric observer) and compare the result to a query of (1) directly for the barycentric observer. Again this SHOULD NOT WORK accurately. In fact the definition of (1) does not contain annual aberration and light deflection that are part of GCRS. A difference of several arcsec (mostly due to annual aberration) SHOULD show up. And in fact IT DOES, ~8 arcsec of difference. The conclusions if that using SkyCoord with the output of JPL Horizons is far from obvious to the end user... ---- So, my final questions/remarks are: - How to get a fully accurate consistency between a SkyCoord frame and JPL Horizons output, in the case of a barycentric, geocentric or topocentric observer, for both "astrometric" and "apparent" coordinates as provided by JPL? Which reference SkyCoord should use and how? - Does astropy implement GCRS correctly in the case of Solar System objects, by taking into account aberration and light deflection in the relativistic form, for an object at finite distance (different than for the stars!) ? - ...or... Am I missing something fundamental in my interpretation? - Eventually, this query to Horizons turns our to be tricky to manage as SkyCoord for the final user. I think it would be useful to provide the correct recipe and/or directly a SkyCoord as output of the query... Best regards Paolo -- --------------------------------------------------------------------- Paolo Tanga Astronomer Deputy director of Laboratoire Langrange / UMR 7293 Observatoire de la Côte d'Azur Tel +33(0)492003042 Bv de l'Observatoire - CS 34229 Fax +33(0)492003121 06304 Nice Cedex 4 - France http://www.oca.eu/tanga https://twitter.com/ziggypao

2 1

Telescope pointing with astropy, atmospheric refraction and precession
by Russell Valentine 30 নভেম্বর, 2020

30 নভেম্বর, 2020

Hello, I've been trying to figure out the best way to get correct coordinates for telescope pointing of a equatorial mount in astropy. How to, given a set of coordinates in ICRS, convert it to account for precession and atmosphereic refraction to correctly move the telescope. It is my understand that you can transform from ICRS to TETE to compensate for precession, but then how to also account for atmospheric refraction? I believe the AltAz coordinate is needed for that. Things I was thinking and tried: 1) ICRS->AltAz (w/pressure)->TETE I do not know if this is correct because you get just very close to just ICRS. I thought maybe it is right and the refraction just happens to be the counter the precession, but I tried it on both east and west horizons with the same result. 2) ICRS->TETE->AltAz(w/pressure) But as expected AltAz is the same as ICRS->AltAz I feel like I am missing some key piece. Has anyone done this with astropy? from astropy.coordinates import EarthLocation, TETE, ICRS, AltAz, SkyCoord import astropy.units as u from astropy.time import Time as AstroTime from astropy.units import si as usi t = AstroTime('2020-11-27 19:12:16.894431') earth_location = EarthLocation(lat=38.9369*u.deg, lon= -95.242*u.deg, height=266.0*u.m) # East horizon object icrs = ICRS(ra=346.23611667*u.deg, dec=12.32287778*u.deg) pressure = 98170.13549857 * u.Pa altaz = icrs.transform_to(AltAz(obstime=t, location=earth_location, pressure=pressure)) tete = icrs.transform_to(TETE(obstime=t, location=earth_location)) tete_from_altaz = altaz.transform_to(TETE()) # West horizon object icrs2 = ICRS(ra=172.53106667*u.deg, dec=9.27663056*u.deg) altaz2 = icrs2.transform_to(AltAz(obstime=t, location=earth_location, pressure=pressure)) tete2 = icrs2.transform_to(TETE(obstime=t, location=earth_location)) tete2_from_altaz2 = altaz2.transform_to(TETE()) altaz_from_tete = tete_from_altaz.transform_to(AltAz(obstime=t, location=earth_location, pressure=pressure))

3 6

IERS issue again
by Nicola Montecchiari 22 নভেম্বর, 2020

22 নভেম্বর, 2020

Hello everybody, after some months I am getting again an error while trying to connect to the IERS. Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit (Intel)] on win32 astropy==2.0.16 numpy==1.16.6 >>> from astropy.time import Time >>> t = Time('2016:001') >>> t.ut1 WARNING: failed to download https://datacenter.iers.org/data/9/finals2000A.all and ftp://cddis.gsfc.nasa.gov/pub/products/iers/finals2000A.all, using local IERS-B: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)>;<urlopen error ftp error: timed out> [astropy.utils.iers.iers] <Time object: scale='ut1' format='yday' value=2016:001:00:00:00.082> Is this a known issue? Thanks a lot for your help Nicola <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Mail priva di virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 2

astropy v4.2rc1 release candidate testing
by Brigitta Sipocz 8 নভেম্বর, 2020

8 নভেম্বর, 2020

Dear All, The first astropy v4.2 release candidate is now available and ready for testing. https://pypi.python.org/pypi/astropy/4.2rc1 We would appreciate if you could try out this RC and report back any success or failure via the following wiki page. If you maintain any downstream packages please check, and preferably whether they are compatible or there are any blocking issues: https://github.com/astropy/astropy/wiki/v4.2-RC-testing Please also, open issues for each different type of failure (please check the issue tracker first to make sure no one has reported it earlier). In addition to running the astropy test suite itself, we especially encourage you to also test it with as many packages of yours as possible. There is a section to list packages at the bottom of the wiki page. You should be able to install the RC by doing: pip install astropy --pre or pip install astropy==4.2rc1 If you use conda, be sure to either remove the existing conda astropy package or make a new environment. Happy testing, Brigitta

1 0