From sergiuspro at yahoo.de  Wed Apr 22 21:49:52 2020
From: sergiuspro at yahoo.de (Sergei Schmalz)
Date: Thu, 23 Apr 2020 03:49:52 +0200
Subject: [AstroPy] AstroPy Lomb-Scargle periodogram
In-Reply-To: <0D2A61ED-18D5-448B-88E4-9CE8B7BC79D0@research.gla.ac.uk>
References: <0D2A61ED-18D5-448B-88E4-9CE8B7BC79D0@research.gla.ac.uk>
Message-ID: <7a5589bd-7f2b-2d71-e9e6-fcfe5e07e87b@yahoo.de>

Hi all!

Does the model() method of the LombScargle object do ONLY A SINUSOID 
best-fit? I've tried to apply it to a folded light curve of an asteroid 
which is not a pure sinusoid in its shape, and the fit didn't really fit 
the data points, it looked exactly like a sinusoid, that's why the 
question. If this is indeed so, is there a work-around while still using 
the model() method, or do I have to use other fitting tools?

By the way, on the Y-axis of the Lomb-Scargle periodogram we have the 
periodogram power, but what's its unit?

Thanks in advance.

Sergei Schmalz


From kellecruz at gmail.com  Thu Apr 23 11:52:50 2020
From: kellecruz at gmail.com (Kelle Cruz)
Date: Thu, 23 Apr 2020 11:52:50 -0400
Subject: [AstroPy] Fwd: [NumFOCUS Projects] Nominate NumFOCUS for IBM Open
 Source Community Grant
In-Reply-To: <CAFP4ZwaZZzatRukG7WDfhf7qDo1iOWq_VV+od8vWOYQ9w0zDzg@mail.gmail.com>
References: <CAFP4ZwaZZzatRukG7WDfhf7qDo1iOWq_VV+od8vWOYQ9w0zDzg@mail.gmail.com>
Message-ID: <CAApiRV5=Ae3_sYJ==M4b_XNzsRjCbV=toV4VmnFwHP_SeYU=8Q@mail.gmail.com>

Hi Astropy Community Members,

Please see below message about how you and any friends you may have at IBM
could help out NumFOCUS with getting cloud computing credits.

(NumFocus is the "fiscal sponsor" for astropy, sunpy, but also numpy,
matplotlib, pandas, and a lot of the scientific computing python stack.
They are our "mothership" so I hope we can help support this effort!)

Kelle

--
Kelle Cruz, PhD
917.837.9748 ? Hunter: x16486 ? AMNH: x7930
Pronouns: she/her and they/them



---------- Forwarded message ---------
From: Walker Chabbott <walker at numfocus.org>
Date: Thu, Apr 23, 2020 at 10:50 AM
Subject: [NumFOCUS Projects] Nominate NumFOCUS for IBM Open Source
Community Grant
To:
Cc: Terry Foor <terry at numfocus.org>


Hello Projects,

Thank you for sending your updates for the April Newsletter. I wanted to
pass along a message from our Director of Development, Terry Foo*r.
NumFOCUS is looking to be nominated for IBM's quarterly Open Source
Community Grants program.* You can find the full message and how to help
out below.
_______

Do you work for IBM? Do you know someone who does? The nomination window
for IBM?s quarterly Open Source Community Grants program opened this week
and runs through May 1. The grant award entails $25,000 in cash and cloud
computing credits valued at an additional $25,000. *Please consider
nominating NumFOCUS. We were finalists last round ? we were not chosen but
were strongly encouraged to have our network of IBMers nominate us again
this quarter as well as in Q3 and Q4 of this year.*

The nomination process does ask for some details about NumFOCUS, including
things like our mission statement, the demographics we serve, and our
ability to reach large audiences and drive significant impact. The scope
and international scale of our work, including PyData, our flagship
community engagement program, qualifies us for everything listed on the
nomination form. More information may be found at
numfocus.org/community/mission as well as at pydata.org/about. Please
contact terry at numfocus.org with any questions or for help filling out the
nomination form.

We were not provided with a link to the nomination portal but IBMers can
search ?Open Source Community Grants? on W3 and find the nomination form.
If needed, NF?s EIN is 45-4547709. Many thanks!

-- 
*Walker Chabbott*
*Communications & Marketing Manager*


-- 
You received this message because you are subscribed to the Google Groups
"Fiscally Sponsored Project Representatives" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to projects+unsubscribe at numfocus.org.
To view this discussion on the web visit
https://groups.google.com/a/numfocus.org/d/msgid/projects/CAFP4ZwaZZzatRukG7WDfhf7qDo1iOWq_VV%2Bod8vWOYQ9w0zDzg%40mail.gmail.com
<https://groups.google.com/a/numfocus.org/d/msgid/projects/CAFP4ZwaZZzatRukG7WDfhf7qDo1iOWq_VV%2Bod8vWOYQ9w0zDzg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

-- 
You received this message because you are subscribed to the Google Groups
"Astropy Coordinators" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to astropy-coordinators+unsubscribe at googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/astropy-coordinators/CAFP4ZwaZZzatRukG7WDfhf7qDo1iOWq_VV%2Bod8vWOYQ9w0zDzg%40mail.gmail.com
<https://groups.google.com/d/msgid/astropy-coordinators/CAFP4ZwaZZzatRukG7WDfhf7qDo1iOWq_VV%2Bod8vWOYQ9w0zDzg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200423/154b358d/attachment.html>

From Paolo.Tanga at oca.eu  Fri Apr 24 09:00:22 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Fri, 24 Apr 2020 15:00:22 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and JPL
 Horizons
Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4@oca.eu>

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

-------------- next part --------------
{
 "cells": [
  {
   "cell_type": "code",
   "execution_count": 9,
   "metadata": {},
   "outputs": [],
   "source": [
    "from astropy.table import Table\n",
    "import numpy as np\n",
    "from astroquery.jplhorizons import Horizons\n",
    "from astropy import coordinates as coord\n",
    "from astropy.coordinates import GCRS, ICRS, Distance, solar_system_ephemeris\n",
    "from astropy.time import Time\n",
    "import astropy.units as u"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 10,
   "metadata": {},
   "outputs": [
    {
     "data": {
      "text/plain": [
       "<ScienceState solar_system_ephemeris: 'de432s'>"
      ]
     },
     "execution_count": 10,
     "metadata": {},
     "output_type": "execute_result"
    }
   ],
   "source": [
    "solar_system_ephemeris.set('de432s') "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Test on (358) Apollonia, April 9, 2020, 07h16m UT"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 11,
   "metadata": {},
   "outputs": [],
   "source": [
    "time = Time('2020-04-09T07:16:00', scale='utc')"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### First test - apparent vs astrometric"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "##### Query JPL Horizons for barycentric and transform to GCRS"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 12,
   "metadata": {},
   "outputs": [],
   "source": [
    "asteroid = Horizons(id='Apollonia', location='@0', epochs=time.jd)  # '@0' defines the Solar Sytem barycenter\n",
    "ast_eph_baryc = asteroid.ephemerides(quantities='1,19,20,21',extra_precision=True)\n",
    "\n",
    "# Build SkyCoord object in ICRS\n",
    "ast_coord_ICRS = coord.SkyCoord(ra=ast_eph_baryc['RA'],dec=ast_eph_baryc['DEC'],distance=ast_eph_baryc['delta'],frame='icrs')\n",
    "# Transform it to GCRS at the epoch above\n",
    "ast_coord_GCRS= ast_coord_ICRS.transform_to(GCRS(obstime=time))"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "##### Query JPL Horizons for apparent coordinates, referred to the geocenter"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 13,
   "metadata": {},
   "outputs": [],
   "source": [
    "asteroid = Horizons(id='Apollonia', location='500', epochs=time.jd)  # '@0' defines the Solar Sytem barycenter\n",
    "ast_eph_app = asteroid.ephemerides(quantities='2,19,20,21',extra_precision=True)\n",
    "\n",
    "# Build SkyCoord from apparent coordinates assuming that it is GCRS \n",
    "ast_coord_app=coord.SkyCoord(ra=ast_eph_app['RA_app'],dec=ast_eph_app['DEC_app'],distance=ast_eph_app['delta'],frame='gcrs',obstime=time)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "##### Separation between the two positions (barycentric transformed to GCRS, and apparent intrpreted as GCRS)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 14,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "Separation  0d16m46.1082s\n",
      "Separation RA  0d15m36.2532s\n"
     ]
    }
   ],
   "source": [
    "print('Separation ',ast_coord_app.separation(ast_coord_GCRS)[0])\n",
    "print('Separation RA ',(ast_coord_app.ra-ast_coord_GCRS.ra)[0])"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This is clearly VERY large. Implying there is a clear difference in the reference frame (especially in RA), not only in \"small\" corrections.\n",
    "Our assumption (apparent coordinates are GCRS) is wrong."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Second test - astrometric geocentric interpreted as GCRS"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "#### Query JPL Horizons for ITRF geocentric and consider these are GCRS"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 15,
   "metadata": {},
   "outputs": [],
   "source": [
    "asteroid = Horizons(id='Apollonia', location='500', epochs=time.jd)  # '@0' defines the Solar Sytem barycenter\n",
    "ast_eph_geoc = asteroid.ephemerides(quantities='1,19,20,21',extra_precision=True)\n",
    "\n",
    "# Build SkyCoord object in GCRS\n",
    "ast_coord_GCRS_2 = coord.SkyCoord(ra=ast_eph_geoc['RA'],dec=ast_eph_geoc['DEC'],distance=ast_eph_geoc['delta'],frame='gcrs',obstime=time)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 16,
   "metadata": {},
   "outputs": [],
   "source": [
    "# Transform it to ICRS barycentric at the epoch above\n",
    "ast_coord_ICRS_2= ast_coord_GCRS_2.transform_to(ICRS)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "#### Difference between the two barycentric positions "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 17,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "Separation  0d00m08.0641s\n"
     ]
    }
   ],
   "source": [
    "print('Separation ',ast_coord_ICRS_2.separation(ast_coord_ICRS)[0])"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "#### Difference between geocentric ICRS queried from JPL, and GCRS obtained from barycentric transformation"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 19,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "Separation  0d00m11.6936s\n"
     ]
    }
   ],
   "source": [
    "print('Separation ',ast_coord_GCRS_2.separation(ast_coord_GCRS)[0])"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": []
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Python 3",
   "language": "python",
   "name": "python3"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.8.2"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}

From bjw at as.arizona.edu  Sat Apr 25 04:43:26 2020
From: bjw at as.arizona.edu (Benjamin Weiner)
Date: Sat, 25 Apr 2020 01:43:26 -0700
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <mailman.25.1587744003.21454.astropy@python.org>
References: <mailman.25.1587744003.21454.astropy@python.org>
Message-ID: <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>

Hello Paolo,

I am not entirely sure what end result you wish to achieve, nor am I an
expert on SkyCoord.  However, I have a suggestion to understand further
these discrepancies (and thank you for including the notebook example). In
your first example:
(a) JPL's barycentric coords to build ICRS at specified time, then
transformed to GCRS at specified time.
(b) JPL's apparent coords to build GCRS at specified time.

The separation of 16 arcmin between (a) and (b) is due to the precession of
the Earth's axis from 2000 to 2020.  This can be seen if we substitute
   time = Time('2000-01-01T00:00:00', scale='utc')
in the line of your notebook that sets the time. At 2000-01-01, the
separation reduces to 8 arcseconds, which you have identified as coming
from the aberration of starlight.

I think that the discrepancy is in building the GCRS coordinates from the
apparent RA/Dec.  The JPL apparent coordinates are referenced to the
position of the Earth's axis at the specified time. But the axes of GCRS
are non-rotating with respect to the axes of BCRS and ICRS - that is, GCRS
is fixed to the Earth's center, but not to the Earth's axis, and does not
precess.  I believe that this is correct - USNO circular 179 has more gory
details on the definition of coordinate frames, see
https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf

Cheers,
Ben

On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org> wrote:

>
> Message: 1
> Date: Fri, 24 Apr 2020 15:00:22 +0200
> From: Paolo Tanga <Paolo.Tanga at oca.eu>
> To: AstroPy at python.org
> Subject: [AstroPy] consistency of reference frames between SkyCoord
>         and JPL Horizons
> Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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
>
>
-- 
Benjamin Weiner
Staff Scientist / Associate Astronomer, MMT / Steward Observatory
bjw at as.arizona.edu
http://mingus.mmto.arizona.edu/~bjw/ <http://mingus.as.arizona.edu/~bjw/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200425/9b68a11a/attachment.html>

From msk at astro.umd.edu  Mon Apr 27 11:45:33 2020
From: msk at astro.umd.edu (Michael S. P. Kelley)
Date: Mon, 27 Apr 2020 11:45:33 -0400
Subject: [AstroPy] ANN: sbpy bugfix release v0.2.2
Message-ID: <CAGEqR4Ss-fq07Otwuu3hirUuG23yOdchddWy3oK2o_t4sBLveg@mail.gmail.com>

Dear all,

The sbpy project is pleased to announce the a bugfix release of sbpy:
v0.2.2.  sbpy is an astropy affiliated package for small body (comet
and asteroid) research.  Notable highlights:

* H,G1,G2 function of Penttil? et al. (2016), HG12_Pen16, now
correctly implemented (#233)
* Fixed a crash calculating total number of molecules with the Haser
(1957) coma model (#240)
* Ephemeris retrieval from JPL Horizons no longer requires any
specific columns (#242)
* sbpy is fully pip installable in a clean environment
* Several documentation and testing suite fixes

sbpy is available at GitHub (github.com/NASA-Planetary-Science/sbpy/)
and PyPI.  Install/upgrade with `pip install -U sbpy`.

Cheers,
Mike Kelley for the sbpy developers

From hessman at astro.physik.uni-goettingen.de  Wed Apr 29 09:19:18 2020
From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman)
Date: Wed, 29 Apr 2020 15:19:18 +0200
Subject: [AstroPy] astropy.table.Table problems with VOTable input and FITS
 output
Message-ID: <7B989FF8-4AB5-4197-8B8F-D3E9AA252E21@astro.physik.uni-goettingen.de>

I'm trying to read tables exported by exoplanet.eu (exoplanet databse portal) in VOTable format.

Here's a mini 1-row table in their format:



astropy.table.Table didn't like the extra "description" attribute for the <RESOURCE> tag used by exoplanet.eu

	<RESOURCE description="Exoplanet ...">

(the description should have been placed as an extra daughter tag) but that was easily removed.  Thereafter, I got this error when trying to re-write it as a FITS table (where I can store metadata - the old problem with astropy VOTables...):

Python 3.5.9 (default, Nov  2 2019, 03:07:41) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from astropy.table import Table
>>> tab = Table.read ('test.vot',format='votable')
>>> tab.write ('test.fits',format='fits',overwrite=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/table/connect.py", line 114, in __call__
    registry.write(instance, *args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/registry.py", line 566, in write
    writer(data, *args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/connect.py", line 387, in write_table_fits
    table_hdu = table_to_hdu(input, character_as_bytes=True)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/convenience.py", line 480, in table_to_hdu
    table_hdu = BinTableHDU.from_columns(np.array(table.filled()), header=hdr, character_as_bytes=True)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/hdu/table.py", line 125, in from_columns
    coldefs = cls._columns_type(columns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py", line 1375, in __init__
    self._init_from_array(input)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py", line 1410, in _init_from_array
    format = self._col_format_cls.from_recformat(ftype)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py", line 273, in from_recformat
    return cls(_convert_format(recformat, reverse=True))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py", line 2401, in _convert_format
    return _convert_record2fits(format)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py", line 2364, in _convert_record2fits
    raise ValueError('Illegal format `{}`.'.format(format))
ValueError: Illegal format `object`.


Note that the table was initially input just fine: all of the data is there and accessible.  The problem was just in storing it in FITS format.

Any ideas?

Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/70c13247/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.vot
Type: application/octet-stream
Size: 21366 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/70c13247/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/70c13247/attachment-0003.html>

From dburke.gw at gmail.com  Wed Apr 29 10:45:35 2020
From: dburke.gw at gmail.com (Doug Burke)
Date: Wed, 29 Apr 2020 10:45:35 -0400
Subject: [AstroPy] astropy.table.Table problems with VOTable input and
 FITS output
In-Reply-To: <7B989FF8-4AB5-4197-8B8F-D3E9AA252E21@astro.physik.uni-goettingen.de>
References: <7B989FF8-4AB5-4197-8B8F-D3E9AA252E21@astro.physik.uni-goettingen.de>
Message-ID: <CALkjVLD8fNDXpepWPQE7m7pZ1CpnX7p4Z_QhuVEipD+gRnOLdg@mail.gmail.com>

Rick,

I've seen this when dealing with a VOTable which has variable-length string
columns. The column is stored as an object rather than a string, and the
FITS serializer can't handle this.

You can see the affected columns with something like:

In [14]: for col in tab.columns:
    ...:     if tab[col].dtype == object: print(col)
    ...:
name
planet_status
updated
publication
detection_type
mass_detection_type
radius_detection_type
alternate_names
molecules
star_name
star_sp_type
star_detected_disc
star_magnetic_field
star_alternate_names

I worked around this by manually converting to string values - e.g.
something like the following, but there may be a nicer way to do this:

In [20]: for col in tab.columns:
    ...:     if tab[col].dtype != object: continue
    ...:     tab[col] = [str(n) for n in tab[col]]
    ...:

However, in this case it just leads to more errors - e.g.

In [21]: tab.write('delme.fits')
WARNING: table contains column(s) with defined 'format', 'description', or
'meta' info attributes. These will be dropped unless you install PyYAML.
[astropy.io.fits.connect]
---------------------------------------------------------------------------
UnitScaleError                            Traceback (most recent call last)
~/anaconda/envs/sherpa-sample-flux/lib/python3.8/site-packages/astropy/io/fits/convenience.py
in table_to_hdu(table, character_as_bytes)
    517             try:
--> 518                 col.unit = unit.to_string(format='fits')
    519             except UnitScaleError:

~/anaconda/envs/sherpa-sample-flux/lib/python3.8/site-packages/astropy/units/core.py
in to_string(self, format)
    604         f = unit_format.get_format(format)
--> 605         return f.to_string(self)
    606

~/anaconda/envs/sherpa-sample-flux/lib/python3.8/site-packages/astropy/units/format/fits.py
in to_string(cls, unit)
    120             if base % 1.0 != 0.0:
--> 121                 raise core.UnitScaleError(
    122                     "The FITS unit format is not able to represent
scales "

UnitScaleError: The FITS unit format is not able to represent scales that
are not powers of 10.  Multiply your data by 1.898125e+27.

During handling of the above exception, another exception occurred:

UnitScaleError                            Traceback (most recent call last)
<ipython-input-21-721daad32140> in <module>
----> 1 tab.write('delme.fits')

... and some more

On Wed, Apr 29, 2020 at 10:34 AM Frederic V. Hessman <
hessman at astro.physik.uni-goettingen.de> wrote:

> I'm trying to read tables exported by exoplanet.eu (exoplanet databse
> portal) in VOTable format.
>
> Here's a mini 1-row table in their format:
>
>
> astropy.table.Table didn't like the extra "description" attribute for the
> <RESOURCE> tag used by exoplanet.eu
>
> <RESOURCE description="Exoplanet ...">
>
> (the description should have been placed as an extra daughter tag) but
> that was easily removed.  Thereafter, I got this error when trying to
> re-write it as a FITS table (where I can store metadata - the old problem
> with astropy VOTables...):
>
> Python 3.5.9 (default, Nov  2 2019, 03:07:41)
> [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from astropy.table import Table
> >>> tab = Table.read ('test.vot',format='votable')
> >>> tab.write ('test.fits',format='fits',overwrite=True)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/table/connect.py",
> line 114, in __call__
>     registry.write(instance, *args, **kwargs)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/registry.py",
> line 566, in write
>     writer(data, *args, **kwargs)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/connect.py",
> line 387, in write_table_fits
>     table_hdu = table_to_hdu(input, character_as_bytes=True)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/convenience.py",
> line 480, in table_to_hdu
>     table_hdu = BinTableHDU.from_columns(np.array(table.filled()),
> header=hdr, character_as_bytes=True)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/hdu/table.py",
> line 125, in from_columns
>     coldefs = cls._columns_type(columns)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py",
> line 1375, in __init__
>     self._init_from_array(input)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py",
> line 1410, in _init_from_array
>     format = self._col_format_cls.from_recformat(ftype)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py",
> line 273, in from_recformat
>     return cls(_convert_format(recformat, reverse=True))
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py",
> line 2401, in _convert_format
>     return _convert_record2fits(format)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/column.py",
> line 2364, in _convert_record2fits
>     raise ValueError('Illegal format `{}`.'.format(format))
> ValueError: Illegal format `object`.
>
>
> Note that the table was initially input just fine: all of the data is
> there and accessible.  The problem was just in storing it in FITS format.
>
> Any ideas?
>
> Rick
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/49e1e5aa/attachment.html>

From Paolo.Tanga at oca.eu  Wed Apr 29 11:23:53 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Wed, 29 Apr 2020 17:23:53 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
Message-ID: <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/f9190fa8/attachment-0001.html>

From brewer at astro.umass.edu  Wed Apr 29 11:47:40 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Wed, 29 Apr 2020 11:47:40 -0400
Subject: [AstroPy] Problems with solar system ephemerides
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
Message-ID: <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>

Dear List,

   Every once in awhile, I have a colleague who wants to use the AstroPy 
solar system ephemerides. I am getting tired of having to dissuade them, 
so I'd like to discuss the issues that I have with these ephemerides in 
an attempt to get them resolved.

Issue #1: The positions of the bodies are returned in the GCRS and there 
appears to be no way to easily transform them to topocentric astrometric 
positions. By this I mean simply the difference in the ICRS position of 
the body compensated for light time and the ICRS position of the 
observer. This is rather important if one wishes to place the body on a 
background map in the ICRS. It is also the only way to compare the 
output of AstroPy's ephemerides with that of JPL Horizons or Brandon 
Rhodes' Skyfield. Why isn't there a builtin frame for doing this?

Issue #2: Currently, there is also no builtin frame for transforming the 
returned positions to apparent place. By this I mean the topocentric 
position with respect to the true equator and equinox of date. This is 
quite important to people such as myself who still like their origin of 
right ascension to be an actual location on the sky rather than a 
convenient mathematical construct. It allows one to point an equatorial 
mounted telescope using the local sidereal time to calculate the hour 
angle. And again, this is the only way to compare the output of 
AstroPy's ephemerides with that of JPL Horizons or Skyfield. It is also 
quite simple to do. Just adjust the CIRS right ascension by subtracting 
the equation of the equinoxes. Note: I did find a function for doing 
this in solar_system.py, _apparent_position_in_true_coordinates(), but 
it feels sort of kludgy to use this. There should be a builtin frame for 
this.

Issue #3: This is a fairly minor quibble, but the functions atciqz() and 
aticq() are calculating the gravitational light deflection from the Sun 
incorrectly. The third argument of erfa.ld() should be the time delayed 
heliocentric position vector of the target body. I do realize that SOFA 
has this problem also.

    Sincerely,

      Michael Brewer



From s.littlefair at sheffield.ac.uk  Wed Apr 29 12:00:26 2020
From: s.littlefair at sheffield.ac.uk (Stuart P Littlefair)
Date: Wed, 29 Apr 2020 17:00:26 +0100
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
Message-ID: <CAOrDc-8T66WJ8dgynvt+jo2sX-AgyP3DcStCGWJLLs85isUGbg@mail.gmail.com>

Hi Michael,

Ignoring your third issue for the moment (for convenience).

In summary you'd like an astrometric frame added to the built-in frames,
and you'd also like a geocentric apparent coordinate frame you can use as
an alternative to CIRS? Sounds eminently reasonable; you could always raise
an issue on the astropy github page requesting this.

It's feature freeze week for V4.1, so things are a bit busy at the moment,
but I'm sure it'll happen if you ask.

Stuart

On Wed, 29 Apr 2020 at 16:48, Michael Brewer <brewer at astro.umass.edu> wrote:

> Dear List,
>
>    Every once in awhile, I have a colleague who wants to use the AstroPy
> solar system ephemerides. I am getting tired of having to dissuade them,
> so I'd like to discuss the issues that I have with these ephemerides in
> an attempt to get them resolved.
>
> Issue #1: The positions of the bodies are returned in the GCRS and there
> appears to be no way to easily transform them to topocentric astrometric
> positions. By this I mean simply the difference in the ICRS position of
> the body compensated for light time and the ICRS position of the
> observer. This is rather important if one wishes to place the body on a
> background map in the ICRS. It is also the only way to compare the
> output of AstroPy's ephemerides with that of JPL Horizons or Brandon
> Rhodes' Skyfield. Why isn't there a builtin frame for doing this?
>
> Issue #2: Currently, there is also no builtin frame for transforming the
> returned positions to apparent place. By this I mean the topocentric
> position with respect to the true equator and equinox of date. This is
> quite important to people such as myself who still like their origin of
> right ascension to be an actual location on the sky rather than a
> convenient mathematical construct. It allows one to point an equatorial
> mounted telescope using the local sidereal time to calculate the hour
> angle. And again, this is the only way to compare the output of
> AstroPy's ephemerides with that of JPL Horizons or Skyfield. It is also
> quite simple to do. Just adjust the CIRS right ascension by subtracting
> the equation of the equinoxes. Note: I did find a function for doing
> this in solar_system.py, _apparent_position_in_true_coordinates(), but
> it feels sort of kludgy to use this. There should be a builtin frame for
> this.
>
> Issue #3: This is a fairly minor quibble, but the functions atciqz() and
> aticq() are calculating the gravitational light deflection from the Sun
> incorrectly. The third argument of erfa.ld() should be the time delayed
> heliocentric position vector of the target body. I do realize that SOFA
> has this problem also.
>
>     Sincerely,
>
>       Michael Brewer
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Stuart Littlefair

-------------------------------------------------------

*I don't expect you to respond to my email outside your working hours. *

*At the University of Sheffield we value and encourage flexible working
patterns, so please be assured that I respect your working pattern and I am
looking forward to your response when you are next working. *

-------------------------------------------------------

Dept. of Physics & Astronomy,
Univ. of Sheffield, Sheffield, S3 7RH.

email: S.Littlefair at sheffield.ac.uk
phone: +44 114 2224525
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/0401d805/attachment.html>

From brewer at astro.umass.edu  Wed Apr 29 12:42:14 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Wed, 29 Apr 2020 12:42:14 -0400
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <CAOrDc-8T66WJ8dgynvt+jo2sX-AgyP3DcStCGWJLLs85isUGbg@mail.gmail.com>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <CAOrDc-8T66WJ8dgynvt+jo2sX-AgyP3DcStCGWJLLs85isUGbg@mail.gmail.com>
Message-ID: <d7fd13a5-924a-bcd9-356a-e57c7adf6b03@astro.umass.edu>

Hi Stuart,

 > you could always raise an issue on the astropy github page requesting 
this.

   Will do.

 > you'd also like a geocentric apparent coordinate frame you can use as 
an alternative to CIRS?

    Yes, in the sense that "geocentric" also includes topocentric when a 
site location is present.

    Thank you for your reply,

       Michael Brewer

On 04/29/2020 12:00 PM, Stuart P Littlefair wrote:
> Hi Michael,
>
> Ignoring your third issue for the moment (for convenience).
>
> In summary you'd like an astrometric frame added to the built-in 
> frames, and you'd also like a geocentric apparent coordinate frame you 
> can use as an alternative to CIRS? Sounds eminently reasonable; you 
> could always raise an issue on the astropy github page requesting this.
>
> It's feature freeze week for V4.1, so things are a bit busy at the 
> moment, but I'm sure it'll happen if you ask.
>
> Stuart
>
> On Wed, 29 Apr 2020 at 16:48, Michael Brewer <brewer at astro.umass.edu 
> <mailto:brewer at astro.umass.edu>> wrote:
>
>     Dear List,
>
>        Every once in awhile, I have a colleague who wants to use the
>     AstroPy
>     solar system ephemerides. I am getting tired of having to dissuade
>     them,
>     so I'd like to discuss the issues that I have with these
>     ephemerides in
>     an attempt to get them resolved.
>
>     Issue #1: The positions of the bodies are returned in the GCRS and
>     there
>     appears to be no way to easily transform them to topocentric
>     astrometric
>     positions. By this I mean simply the difference in the ICRS
>     position of
>     the body compensated for light time and the ICRS position of the
>     observer. This is rather important if one wishes to place the body
>     on a
>     background map in the ICRS. It is also the only way to compare the
>     output of AstroPy's ephemerides with that of JPL Horizons or Brandon
>     Rhodes' Skyfield. Why isn't there a builtin frame for doing this?
>
>     Issue #2: Currently, there is also no builtin frame for
>     transforming the
>     returned positions to apparent place. By this I mean the topocentric
>     position with respect to the true equator and equinox of date.
>     This is
>     quite important to people such as myself who still like their
>     origin of
>     right ascension to be an actual location on the sky rather than a
>     convenient mathematical construct. It allows one to point an
>     equatorial
>     mounted telescope using the local sidereal time to calculate the hour
>     angle. And again, this is the only way to compare the output of
>     AstroPy's ephemerides with that of JPL Horizons or Skyfield. It is
>     also
>     quite simple to do. Just adjust the CIRS right ascension by
>     subtracting
>     the equation of the equinoxes. Note: I did find a function for doing
>     this in solar_system.py, _apparent_position_in_true_coordinates(),
>     but
>     it feels sort of kludgy to use this. There should be a builtin
>     frame for
>     this.
>
>     Issue #3: This is a fairly minor quibble, but the functions
>     atciqz() and
>     aticq() are calculating the gravitational light deflection from
>     the Sun
>     incorrectly. The third argument of erfa.ld() should be the time
>     delayed
>     heliocentric position vector of the target body. I do realize that
>     SOFA
>     has this problem also.
>
>         Sincerely,
>
>           Michael Brewer
>
>
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at python.org <mailto:AstroPy at python.org>
>     https://mail.python.org/mailman/listinfo/astropy
>
>
>
> -- 
> Stuart Littlefair
>
> -------------------------------------------------------
>
> */I don't expect you to respond to my email outside your working hours. /*
> /
> /
> /At the University of Sheffield we value and encourage flexible 
> working patterns, so please be assured that I respect your working 
> pattern and I am looking forward to your response when you are next 
> working. /
> /
> /
> -------------------------------------------------------
>
> Dept. of Physics & Astronomy,
> Univ. of Sheffield, Sheffield, S3 7RH.
>
> email: S.Littlefair at sheffield.ac.uk <mailto:S.Littlefair at sheffield.ac.uk>
> phone: +44 114 2224525
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200429/2f6adbc5/attachment-0001.html>

From derek at astro.physik.uni-goettingen.de  Wed Apr 29 13:47:37 2020
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Wed, 29 Apr 2020 19:47:37 +0200
Subject: [AstroPy] astropy.table.Table problems with VOTable input and
 FITS output
In-Reply-To: <CALkjVLD8fNDXpepWPQE7m7pZ1CpnX7p4Z_QhuVEipD+gRnOLdg@mail.gmail.com>
References: <7B989FF8-4AB5-4197-8B8F-D3E9AA252E21@astro.physik.uni-goettingen.de>
 <CALkjVLD8fNDXpepWPQE7m7pZ1CpnX7p4Z_QhuVEipD+gRnOLdg@mail.gmail.com>
Message-ID: <09505603-A04C-4F53-8120-E2EAE72A75FB@astro.physik.uni-goettingen.de>

Hi,

Rick, first I recommend that, if possible, you switch to Python 3.6 - 3.8, so you would be able to use the
current release of Astropy ? I could not reproduce the read error on

<RESOURCE type="results">
  <DESCRIPTION>Encyclopedia of extrasolar planet</DESCRIPTION>

so this seems to be fixed in 4.0.1.

> On 29 Apr 2020, at 4:45 pm, Doug Burke <dburke.gw at gmail.com> wrote:
> 
> I've seen this when dealing with a VOTable which has variable-length string columns. The column is stored as an object rather than a string, and the FITS serializer can't handle this.
> 
> You can see the affected columns with something like:
> 
...
> I worked around this by manually converting to string values - e.g. something like the following, but there may be a nicer way to do this:
> 
> In [20]: for col in tab.columns:
>     ...:     if tab[col].dtype != object: continue
>     ...:     tab[col] = [str(n) for n in tab[col]]
>     ?:
> 
For the example file I was able to use
    if tab[col].dtype = object:
        tab[col] = tab[col].astype('str?)

should the be `objects` not representable as strings, this would certainly raise an error, but for
the present problem with variable-length strings (and possibly also the `unicodeChar` type)
that ought to do the job.

> However, in this case it just leads to more errors - e.g.
> 
> In [21]: tab.write('delme.fits')
> WARNING: table contains column(s) with defined 'format', 'description', or 'meta' info attributes. These will be dropped unless you install PyYAML. [astropy.io.fits.connect]
> ---------------------------------------------------------------------------
> UnitScaleError                            Traceback (most recent call last)
>     122                     "The FITS unit format is not able to represent scales ?
> 
...
> UnitScaleError: The FITS unit format is not able to represent scales that are not powers of 10.  Multiply your data by 1.898125e+27.


This is a result of the `jovian` units not being supported in FITS.
This could be worked around e.g. by

>>> from astropy import units as u
>>> for col in tab.columns:
...     if tab[col].dtype == object:
...         tab[col] = tab[col].astype('str')
...     elif tab[col].unit is not None and (tab[col].unit.to_string().startswith('jov') or tab[col].unit.to_string().endswith('jup')):
...         tab[col] = tab[col].to(tab[col].unit.to_system(u.si)[0].bases[0])

unfortunately not a very elegant solution either. For a somewhat more general and robust alternative it might be better
to change the second test to

...     elif tab[col].unit is not None:
...         try:
...             tab[col].unit.to_string('fits')
...         except astropy.units.core.UnitScaleError:
...             tab[col] = tab[col].to(tab[col].unit.to_system(u.si)[0].bases[0])

Cheers,
						Derek


From hessman at astro.physik.uni-goettingen.de  Thu Apr 30 10:35:54 2020
From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman)
Date: Thu, 30 Apr 2020 16:35:54 +0200
Subject: [AstroPy] VOTable problems
In-Reply-To: <mailman.1456.1588173843.24659.astropy@python.org>
References: <mailman.1456.1588173843.24659.astropy@python.org>
Message-ID: <29869684-3272-4038-A85A-FE6FC14D34E2@astro.physik.uni-goettingen.de>

I thanked Doug for his help, but now I think I've found the real problems, one with strings and another with units.

Here's a simple VOTable containing a single row with a string and a float column:

% more test.vot
<?xml version="1.0" encoding="utf-8"?>
<VOTABLE version="1.3" xmlns="http://www.ivoa.net/xml/VOTable/v1.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.ivoa.net/xml/VOTable/v1.3">
 <RESOURCE type="results">
  <DESCRIPTION>Test of astropy.table.Table and astropy.io.fits treatment of VOTable's</DESCRIPTION>
  <TABLE>
   <FIELD ID="astring" arraysize="16" datatype="char" name="astring" ucd="meta.id;src" unit="">
    <DESCRIPTION>A random string</DESCRIPTION>
   </FIELD>
   <FIELD ID="mass" datatype="double" name="mass" ucd="phys.mass" unit="jovMass">
    <DESCRIPTION>A random mass in units of M_Jupiter</DESCRIPTION>
   </FIELD>
   <DATA>
    <TABLEDATA>
     <TR>
      <TD>Hello, world!</TD>
      <TD>1.234567</TD>
     </TR>
    </TABLEDATA>
   </DATA>
  </TABLE>
 </RESOURCE>
</VOTABLE>

Now, when you read this in, no problem:

>>> from astropy.table import Table
>>> tab = Table.read ('test.xml',format='votable')
>>> tab
<Table masked=True length=1>
   astring      mass  
              jovMass 
   bytes16    float64 
------------- --------
Hello, world! 1.234567

but when you try to store it...

>>> tab.write ('test.fits',format='fits')
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/convenience.py", line 518, in table_to_hdu
    col.unit = unit.to_string(format='fits')
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/units/core.py", line 607, in to_string
    return f.to_string(self)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/units/format/fits.py", line 124, in to_string
    "{0:e}.".format(unit.scale))
astropy.units.core.UnitScaleError: The FITS unit format is not able to represent scales that are not powers of 10.  Multiply your data by 1.898187e+27.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/table/connect.py", line 114, in __call__
    registry.write(instance, *args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/registry.py", line 566, in write
    writer(data, *args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/connect.py", line 387, in write_table_fits
    table_hdu = table_to_hdu(input, character_as_bytes=True)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/astropy/io/fits/convenience.py", line 525, in table_to_hdu
    "the data or change the units.".format(col.name, str(scale)))
astropy.units.core.UnitScaleError: The column 'mass' could not be stored in FITS format because it has a scale '(1.0)' that is not recognized by the FITS standard. Either scale the data or change the units.

If one deletes the unit of the "mass" column, everything is ok.  If one uses a FITS-compatible unit like "solMass", everything is ok.  Thus, the problem is that the astropy implementation of converting a votable input into a FITS output won't accept non-FITS units.  The IVOA standard allows one to use any reasonable units and suggests that one follow the style of the FITS standard, but "jovMass" (Jovian masses, in the same syntax as "solMass" = Solar masses) isn't a FITS standard.  Generally, the IVOA standard should be the measure of things.  There are lots of tables that don't want to have to use wierd units like the FITS-acceptable "solMass/1047" or "1.8982e27*solMass".

astropy should simply send a warning, saying that the FITS file created doesn't conform to the nominal FITS standard, but who cares, as long as the data has been stored.

The problem Doug mentioned has to do with strings:  note that above I used a FIELD with the following syntax

	<FIELD ID="astring" arraysize="16" datatype="char" name="astring" ucd="meta.id;src" unit="">

Had I used the IVOA standard syntax

	<FIELD ID="astring" arraysize="*" datatype="char" name="astring" ucd="meta.id;src" unit="">

(i.e. strings of varying length), I would have gotten the problem with string objects mentioned by Doug.  The astropy implementation doesn't implement the standard IVOA syntax in a fashion that leads to a correct translation into FITS.

Yet another reason (other than the total lack of metadata storage) to work over the votable implementation.  A great task for a younger and better programmer than me....

Rick


> Message: 1
> Date: Wed, 29 Apr 2020 10:45:35 -0400
> From: Doug Burke <dburke.gw at gmail.com>
> To: Astronomical Python mailing list <astropy at python.org>
> Subject: Re: [AstroPy] astropy.table.Table problems with VOTable input
> 	and FITS output
> Message-ID:
> 	<CALkjVLD8fNDXpepWPQE7m7pZ1CpnX7p4Z_QhuVEipD+gRnOLdg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Rick,
> 
> I've seen this when dealing with a VOTable which has variable-length string
> columns. The column is stored as an object rather than a string, and the
> FITS serializer can't handle this.
> 
> You can see the affected columns with something like:
> 
> In [14]: for col in tab.columns:
>    ...:     if tab[col].dtype == object: print(col)
>    ...:
> name
> planet_status
> updated
> publication
> detection_type
> mass_detection_type
> radius_detection_type
> alternate_names
> molecules
> star_name
> star_sp_type
> star_detected_disc
> star_magnetic_field
> star_alternate_names
> 
> I worked around this by manually converting to string values - e.g.
> something like the following, but there may be a nicer way to do this:
> 
> In [20]: for col in tab.columns:
>    ...:     if tab[col].dtype != object: continue
>    ...:     tab[col] = [str(n) for n in tab[col]]
>    ...:
> 
> However, in this case it just leads to more errors - e.g.
> 
> In [21]: tab.write('delme.fits')
> WARNING: table contains column(s) with defined 'format', 'description', or
> 'meta' info attributes. These will be dropped unless you install PyYAML.
> [astropy.io.fits.connect]
> ---------------------------------------------------------------------------
> UnitScaleError                            Traceback (most recent call last)
> ~/anaconda/envs/sherpa-sample-flux/lib/python3.8/site-packages/astropy/io/fits/convenience.py
> in table_to_hdu(table, character_as_bytes)
>    517             try:
> --> 518                 col.unit = unit.to_string(format='fits')
>    519             except UnitScaleError:
> 
> ~/anaconda/envs/sherpa-sample-flux/lib/python3.8/site-packages/astropy/units/core.py
> in to_string(self, format)
>    604         f = unit_format.get_format(format)
> --> 605         return f.to_string(self)
>    606
> 
> ~/anaconda/envs/sherpa-sample-flux/lib/python3.8/site-packages/astropy/units/format/fits.py
> in to_string(cls, unit)
>    120             if base % 1.0 != 0.0:
> --> 121                 raise core.UnitScaleError(
>    122                     "The FITS unit format is not able to represent
> scales "
> 
> UnitScaleError: The FITS unit format is not able to represent scales that
> are not powers of 10.  Multiply your data by 1.898125e+27.
> 
> During handling of the above exception, another exception occurred:
> 
> UnitScaleError                            Traceback (most recent call last)
> <ipython-input-21-721daad32140> in <module>
> ----> 1 tab.write('delme.fits')
> 
> ... and some more
> 
> On Wed, Apr 29, 2020 at 10:34 AM Frederic V. Hessman <
> hessman at astro.physik.uni-goettingen.de> wrote:


From derek at astro.physik.uni-goettingen.de  Thu Apr 30 15:03:54 2020
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Thu, 30 Apr 2020 21:03:54 +0200
Subject: [AstroPy] VOTable problems
In-Reply-To: <29869684-3272-4038-A85A-FE6FC14D34E2@astro.physik.uni-goettingen.de>
References: <mailman.1456.1588173843.24659.astropy@python.org>
 <29869684-3272-4038-A85A-FE6FC14D34E2@astro.physik.uni-goettingen.de>
Message-ID: <28E4842B-5C1A-4C75-87A1-759154E54D15@astro.physik.uni-goettingen.de>

Hi Rick,
> 
> astropy.units.core.UnitScaleError: The column 'mass' could not be stored in FITS format because it has a scale '(1.0)' that is not recognized by the FITS standard. Either scale the data or change the units.
> 
> If one deletes the unit of the "mass" column, everything is ok.  If one uses a FITS-compatible unit like "solMass", everything is ok.  Thus, the problem is that the astropy implementation of converting a votable input into a FITS output won't accept non-FITS units.  The IVOA standard allows one to use any reasonable units and suggests that one follow the style of the FITS standard, but "jovMass" (Jovian masses, in the same syntax as "solMass" = Solar masses) isn't a FITS standard.  Generally, the IVOA standard should be the measure of things.  There are lots of tables that don't want to have to use wierd units like the FITS-acceptable "solMass/1047" or "1.8982e27*solMass?.
> 
the IVOA standard actually allows the user to invent any kind of units, reasonable or not.
Jovian or Jupiter masses, radii etc. per the VOUnit standard are not ?known? units either,
but simply ?unrecognised units? that a parser is expected to accept.
So transforming everything that the VOTable format would permit to FITS is a challenging task.
For FITS, the measure of things is the official standard accepted and published by the IAU, and
the principal philosophy of astropy?s fits module is to be forgiving on input, but strict with output: https://docs.astropy.org/en/latest/io/fits/usage/verification.html#verification
Further down it also states that any of these verification rules can be changed to the ?warn? or ?silent?
level if explicitly requested, but that admittedly does not make life much easier, since none of these
options are accepted by the convenience functions for directly creating HDUs from tables.
As long as one has identifiable units, the easier solution will probably still be converting to a
standard-conforming unit as suggested in my first reply:

> tab[col] = tab[col].to(tab[col].unit.to_system(u.si)[0].bases[0])

Again, admittedly fairly awkward syntax (unless someone can suggest a more straightforward way
to code this), but least you don?t need to treat every unit individually. Though you might of course
prefer ?Mjup? to ?kg? in your example?
And it would certainly be nice to have an option for making `table_to_hdu` take care of this automatically.

> astropy should simply send a warning, saying that the FITS file created doesn't conform to the nominal FITS standard, but who cares, as long as the data has been stored.
> 
> The problem Doug mentioned has to do with strings:  note that above I used a FIELD with the following syntax
> 
> 	<FIELD ID="astring" arraysize="16" datatype="char" name="astring" ucd="meta.id;src" unit="">
> 
> Had I used the IVOA standard syntax
> 
> 	<FIELD ID="astring" arraysize="*" datatype="char" name="astring" ucd="meta.id;src" unit="">
> 
> (i.e. strings of varying length), I would have gotten the problem with string objects mentioned by Doug.  The astropy implementation doesn't implement the standard IVOA syntax in a fashion that leads to a correct translation into FITS.
> 
The astropy implementation should implement the standard in a way that is correctly reading VOTable files
into functional astropy Tables. Translation into FITS format is quite a different thing, especially with the two
following somewhat distinct standards. Acceptance of physical and nonphysical units is one example you?ve
pointed out; variable-length or -width table entries another that I think is very hard to accommodate in FITS.

> Yet another reason (other than the total lack of metadata storage) to work over the votable implementation.  A great task for a younger and better programmer than me....

If you could file an issue on GitHub with the specific problems arising with your data, that would certainly
help keeping it on the radar. Having someone able to devote a substantial part of their workforce to that
task would of course help as well, but at least for the FITS side some familiarity with the over two decades
of development history of PyFITS and astropy io.fits combined could probably also come in handy. ;-)

Cheers,
					Derek


From ejensen1 at swarthmore.edu  Thu Apr 30 23:09:37 2020
From: ejensen1 at swarthmore.edu (Eric Jensen)
Date: Thu, 30 Apr 2020 23:09:37 -0400
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
Message-ID: <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>

Hi Paolo, 

Like Ben, I?m a little unclear on exactly what you are trying to achieve beyond what you?ve demonstrated already.  (I have learned from your example!)  You have shown that Horizons provides astrometric coordinates that are ICRS, and that these are straightforward to insert into a SkyCoord object as you show in your example.  

If for some reason you want to use the apparent coordinates instead, then you need to put them into a SkyCoord frame that precesses, which as I understand it is what the PrecessedGeocentric frame is for.  So with a slight modification of your example, you can do this: 

asteroid = Horizons(id='Apollonia', location='500', 
                    epochs=time.jd)
ast_eph_app = asteroid.ephemerides(quantities='2,19,20,21',
                                   extra_precision=True)

# Build SkyCoord from apparent coordinates at observation 
# epoch and then convert to GCRS 
ast_coord_app=coord.SkyCoord(ra=ast_eph_app['RA_app'],
                             dec=ast_eph_app['DEC_app'],
                             distance=ast_eph_app['delta'],
                             frame='precessedgeocentric',
                             obstime=time, equinox=time)
ast_coord_app_trans = ast_coord_app.transform_to(GCRS(obstime=time))

Doing this, I get coordinates that differ by about 13 arcsec (mostly in RA) from the GCRS coords you create in the first part of your example using the ICRS coords at the barycenter.  I don?t know what the source of that difference is, but perhaps some of the various GR corrections. 

There are indeed subtleties in converting between various coordinates systems, as you note, but I would say that those subtleties are inherent to the topic in general, not to the astropy software in particular.  That said, examples are quite helpful, so I?d encourage you to submit an example based on your work here for inclusion on the examples page at https://docs.astropy.org/en/stable/generated/examples/ . 

Best,

Eric
 

> On Apr 29, 2020, at 11:23 AM, Paolo Tanga <Paolo.Tanga at oca.eu> wrote:
> 
> Hi Ben
> 
> thank you for taking your time to look into this question, and sorry for the delay.
> 
> I would say, all that I am trying to do is to use the astroquery output in a SkyCoord object coherently. If one manages to do that, than it is possible to take profit of all the SkyCoord methods of course, to manipulate the coordinates (transform_to ) etc.
> 
> As the SkyCoord is a fundamental part of the astropy suite, I would expect that there should be a "easy" method (or at least, a documented one!) to pass from an astroquery/JPL result to SkyCoord. But it turns out that this is not the case.
> 
> So, what we have learned so far, if I am correct, is that:
> 
> - JPL apparent coordinates. Precession - you are totally right - creates the difference between GCRS and the JPL apparent coordinates. In the documentation I would explicitly write that these cannot easily be used in a SkyCoord frame. In fact I tried playing with different reference frames (including GeocentricTrueEquator etc) but I see the same inconsistencies as with GCRS. So, I suppose that if there is a method, it is not straightforward (at least, not for me).
> 
> - JPL astrometric coordinates. If computed with the observer at the barycenter of the Solar System, they can fit a SkyCoord object in ICRS. And this is the only possibility. 
> 
> I think that there could be other subtleties to check, but don't you think that this should be documented somewhere? 
> 
> Note that in the case of the ephemeris of the major planets (get_body()...) a SkyCoord object is directly returned, which is very convenient. 
> 
> Cheers
> 
> Paolo
> 
> 
> 
> On 25/04/2020 10:43, Benjamin Weiner wrote:
>> Hello Paolo,
>> 
>> I am not entirely sure what end result you wish to achieve, nor am I an expert on SkyCoord.  However, I have a suggestion to understand further these discrepancies (and thank you for including the notebook example). In your first example:
>> (a) JPL's barycentric coords to build ICRS at specified time, then transformed to GCRS at specified time.
>> (b) JPL's apparent coords to build GCRS at specified time.
>> 
>> The separation of 16 arcmin between (a) and (b) is due to the precession of the Earth's axis from 2000 to 2020.  This can be seen if we substitute 
>>    time = Time('2000-01-01T00:00:00', scale='utc')
>> in the line of your notebook that sets the time. At 2000-01-01, the separation reduces to 8 arcseconds, which you have identified as coming from the aberration of starlight.
>> 
>> I think that the discrepancy is in building the GCRS coordinates from the apparent RA/Dec.  The JPL apparent coordinates are referenced to the position of the Earth's axis at the specified time. But the axes of GCRS are non-rotating with respect to the axes of BCRS and ICRS - that is, GCRS is fixed to the Earth's center, but not to the Earth's axis, and does not precess.  I believe that this is correct - USNO circular 179 has more gory details on the definition of coordinate frames, see 
>> https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf <https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf>
>> 
>> Cheers,
>> Ben
>> 
>> On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org <mailto:astropy-request at python.org>> wrote:
>> 
>> Message: 1
>> Date: Fri, 24 Apr 2020 15:00:22 +0200
>> From: Paolo Tanga <Paolo.Tanga at oca.eu <mailto:Paolo.Tanga at oca.eu>>
>> To: AstroPy at python.org <mailto:AstroPy at python.org>
>> Subject: [AstroPy] consistency of reference frames between SkyCoord
>>         and JPL Horizons
>> Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu <mailto:b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>> 
>> 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
>> 
>> 
>> -- 
>> Benjamin Weiner   
>> Staff Scientist / Associate Astronomer, MMT / Steward Observatory
>> bjw at as.arizona.edu <mailto:bjw at as.arizona.edu>
>> http://mingus.mmto.arizona.edu/~bjw/ <http://mingus.as.arizona.edu/~bjw/>
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org <mailto:AstroPy at python.org>
>> https://mail.python.org/mailman/listinfo/astropy <https://mail.python.org/mailman/listinfo/astropy>
> -- 
> ---------------------------------------------------------------------
> 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 <http://www.oca.eu/tanga>
>                                          https://twitter.com/ziggypao <https://twitter.com/ziggypao>_______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200430/23b58f35/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200430/23b58f35/attachment-0001.bin>