From herve.aussel at cea.fr  Thu Jul  6 11:20:49 2017
From: herve.aussel at cea.fr (=?utf-8?Q?Herv=C3=A9_Aussel?=)
Date: Thu, 6 Jul 2017 17:20:49 +0200
Subject: [AstroPy] Question on astropy.coordinates internals
Message-ID: <6C794AF3-7AFC-4F96-9775-011435D522D2@cea.fr>

	Hello, 

I am working on a package to handle spacecrafts attitudes in python, and I would like to build on the astropy.coordinates package, especially to handle transformations between reference frames. I have a few questions regarding the internals of the package. 

- What is the correct way to check that an input is a bona fide reference frame ? Playing around, I have come with this:
import astropy.coordinates as coord
isinstance(my_input_frame, coord.baseframe.FrameMeta)

- Is there a way to access the directly the coodinate tranformation matrix ? So far, I use the transformation on each of the cartesian unit vector to build the rotation matrix, but this is a bit clunky...

Thanks for your help, 

Cheers, 

Herv?



-----------------------------------------------------------------------------------------
Herv? Aussel

EC SPV Lead

AIM Paris-Saclay                                  phone: (+33) 01 69 08 95 79
UMR 7158                                             fax  : (+33) 01 69 08 65 77
Bat 709 CE-Saclay                              
Orme des Merisiers                              email: herve.aussel at cea.fr
F 91 191 Gif-sur-Yvette





From paola.galdi at gmail.com  Thu Jul  6 15:23:24 2017
From: paola.galdi at gmail.com (Paola Galdi)
Date: Thu, 6 Jul 2017 12:23:24 -0700
Subject: [AstroPy] reconstruct signal from periodogram
Message-ID: <CAFE-DiVB5rdhwACsZRO6mh4FFjsE2ZVT+PQv+siBr2VV19u3TA@mail.gmail.com>

Hello,
I've been working with the LombScargle class from astropy.stats and I have
a question about using the periodogram to reconstruct the signal at given
time points.

My problem is that I have a time series where some of the time points are
censored, and I'd like to reconstruct the signal in the missing points by
using the frequency content of uncensored data.

So far I've been able to obtain the best fit sinusoid (as in
http://docs.astropy.org/en/stable/stats/lombscargle.html) but what I'd like
to do is to reconstruct the signal using all frequencies.

I tried to sum up all the sinusoidal models for each frequency (weighted by
powers) but the result was a quite flat line around the mean of the signal.

Do you have any suggestions on how I could achieve signal reconstruction?

Thank you,
Paola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20170706/df722e79/attachment.html>

From erwin at mpe.mpg.de  Fri Jul  7 06:12:41 2017
From: erwin at mpe.mpg.de (Peter Erwin)
Date: Fri, 7 Jul 2017 12:12:41 +0200
Subject: [AstroPy] Problems constructing astropy.wcs.WCS object from
 multi-plane 2MASS images
Message-ID: <C412C0CF-C27E-4AA0-9902-C0419AEE320A@mpe.mpg.de>

Hi,

I'm having trouble constructing WCS objects from 2MASS galaxy images.
(My goal is to determine the pixel coordinates of the galaxy center in the
J-band images, given the RA and Dec from e.g. NED or HyperLeda.)

For single-filter images from the 2MASS Large Galaxy Atlas, the following
works just fine:
>>> imdata,hdr = fits.getdata(fits_filename, header=True)
>>> wcsObj = astropy.wcs.WCS(header=hdr)


But for galaxies not in the Large Galaxy Atlas, using the "datacube" JHK images (obtained via NED), 
produces this error:

>>> imdata,hdr = fits.getdata(fits_filename, header=True)
>>> wcsObj = astropy.wcs.WCS(header=hdr)
WARNING: FITSFixedWarning: 'celfix' made the change 'Unrecognized projection code (-SI in CTYPE2)'. [astropy.wcs.wcs]
---------------------------------------------------------------------------
InconsistentAxisTypesError                Traceback (most recent call last)
<ipython-input-123-a63c9d39ae30> in <module>()
----> 1 wcsObj = astropy.wcs.WCS(header=hdr)

/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/astropy/wcs/wcs.py in __init__(self, header, fobj, key, minerr, relax, naxis, keysel, colsel, fix, translate_units, _do_set)
    502 
    503         if _do_set:
--> 504             self.wcs.set()
    505 
    506         for fd in close_fds:

InconsistentAxisTypesError: ERROR 4 in wcs_types() at line 2432 of file cextern/wcslib/C/wcs.c:
Unrecognized projection code (-SI in CTYPE2).


This is puzzling, because the headers for both the Large Galaxy Atlas images and the
JHK datacubes seem to be very similar; in particular, the CTYPE2 header keyword
is 'DEC--SIN' for both sorts of image.


Here's the header from a Large Galaxy Atlas image:

SIMPLE  =                    T
BITPIX  =                  -32
NAXIS   =                    2
NAXIS1  =                  800
NAXIS2  =                  800
BLOCKED =                    T / TAPE MAY BE BLOCKED IN MULTIPLES OF 2880
EXTEND  =                    T / TAPE MAY HAVE STANDARD FITS EXTENSIONS
BSCALE  =                   1.
BZERO   =                   0.
ORIGIN  = '2MASS   '           / 2MASS Survey Camera
CTYPE1  = 'RA---SIN'
CTYPE2  = 'DEC--SIN'
CRPIX1  =                400.5
CRPIX2  =                400.5
CRVAL1  =           23.5757103
CRVAL2  =         -29.41875076
CDELT1  =     -0.0002777777845
CDELT2  =      0.0002777777845
CROTA2  =                   0.
EQUINOX =                2000.
JMAGZP  =          20.98749924 /   V3 Photometric zero point calibration
COMMENTC= 'CAL updated by T.H. Jarrett, IPAC/Caltech'
SIGMA   =         0.7034527063 /   Background Residual RMS noise (dn)
COMMENT1= '2MASS mosaic image'
COMMENT2= 'created by T.H. Jarrett, IPAC/Caltech'
END


And here's the header for a typical JHK datacube (note that it actually
has *six* image planes: the first three are sky-subtracted J, H, and K, while
the second three are sky-and-star-subtracted J, H, and K):

SIMPLE  =                    T
BITPIX  =                  -32
NAXIS   =                    3
NAXIS1  =                  301
NAXIS2  =                  301
NAXIS3  =                    6
BLOCKED =                    T / TAPE MAY BE BLOCKED IN MULTIPLES OF 2880
EXTEND  =                    T / TAPE MAY HAVE STANDARD FITS EXTENSIONS
ORIGIN  = '2MASS   '           / 2MASS Survey Camera
TELESCOP= '2MASS   '           / North=Mt.Hopkins,South=CTIO
GID     = '002433  '           / 2MASS ID #
NNAME   = 'NGC_3412'           / NED Cat Name
SCANNO  = '136     '           / Scan Number
COADDNO = '209     '           / Coadd Number
ORDATE  = '971215n '           / Observation Ref Date (yymmdd)
UTDATE  = '971215  '           / UT Date of Frame (IC) (yymmdd)
UT      = '12:42:44.02'        / Time of Frame (IC) (sxgsml)
DATE-OBS= '1997-12-15T12:42:44.02' / Observation Ref Date
EQUINOX =                2000. / Equinox
CTYPE1  = 'RA---SIN'           / Orthographic Projection
CTYPE2  = 'DEC---SIN'          / Orthographic Projection
CTYPE3  = 'JHKs cube'          / 1=J,2=H,3=Ks; 4=J,5=H,6=Ks
RA      =          162.7221375 / RA  at Frame Center, J2000 (deg)
DEC     =           13.4121418 / Dec at Frame Center, J2000 (deg)
CRVAL1  =          162.7221375 / RA  at Frame Center, J2000 (deg)
CRVAL2  =           13.4121418 / Dec at Frame Center, J2000 (deg)
CRPIX1  =                 151. / Axis 1 Reference Pixel
CRPIX2  =                 151. / Axis 2 Reference Pixel
CROTA2  =       0.002134113805 / Image Twist  E of N, J2000 (deg)
CDELT1  =     -0.0002777777845 / Axis 1 Pixel Size (deg)
CDELT2  =      0.0002777777845 / Axis 2 Pixel Size (deg)
JSKYVAL =           53.5084343 / GALWORKS J Sky Measurement
JSKYSIG =         0.4580373764 / GALWORKS J Noise Measurement
HSKYVAL =          281.6602478 / GALWORKS H Sky Measurement
HSKYSIG =         0.8120117188 / GALWORKS H Noise Measurement
KSKYVAL =          260.6483765 / GALWORKS K Sky Measurement
KSKYSIG =         0.8488883972 / GALWORKS K Noise Measurement
CALID   = ' V3-CALIBRATED'     / Calibration ID
JSEESH  =          1.052999973 / Seeing J shape parameter
HSEESH  =          1.018000007 / Seeing H shape parameter
KSEESH  =          1.034999967 / Seeing K shape parameter
JMAGZP  =              21.0540   / Calibrated J zero point from CALMAN
HMAGZP  =              20.6830   / Calibrated H zero point from CALMAN
KMAGZP  =              20.0540   / Calibrated K zero point from CALMAN
AMASS_FC=          1.052941084 / Airmass (aprox) at this position
COMMENT > Planes 1, 2 and 3 represent the background
COMMENT > subtracted images of the J, H and Ks bands;
COMMENT > Planes 4,5,6 represent the background **and**
COMMENT > star subtracted images of the J, H and Ks bands
HISTORY > GALWORKS Version 3
HISTORY > image created by galworks,  Tom Jarrett, IPAC/Caltech/JPL
END

Any suggestions?

cheers,

Peter

=============================================================
Peter Erwin                   Max-Planck-Insitute for Extraterrestrial 
erwin at mpe.mpg.de              Physics, Giessenbachstrasse
tel. +49 (0)176 2481 7713     85748 Garching, Germany
fax  +49 (0)89 30000 3495     http://www.mpe.mpg.de/~erwin




From alexandre.beelen at ias.u-psud.fr  Fri Jul  7 07:54:25 2017
From: alexandre.beelen at ias.u-psud.fr (Alexandre Beelen)
Date: Fri, 7 Jul 2017 13:54:25 +0200
Subject: [AstroPy] Problems constructing astropy.wcs.WCS object from
 multi-plane 2MASS images
In-Reply-To: <C412C0CF-C27E-4AA0-9902-C0419AEE320A@mpe.mpg.de>
References: <C412C0CF-C27E-4AA0-9902-C0419AEE320A@mpe.mpg.de>
Message-ID: <b4ed61f7-2489-978a-e61f-14e330c49896@ias.u-psud.fr>

Hi,

It might be a typo, but CTYPE2 should be

'DEC--SIN'
and not
'DEC---SIN'

a.

On 07/07/2017 12:12, Peter Erwin wrote:
> CTYPE2  = 'DEC---SIN'          / Orthographic Projection

From adrianmpw at gmail.com  Fri Jul  7 09:04:10 2017
From: adrianmpw at gmail.com (Adrian Price-Whelan)
Date: Fri, 7 Jul 2017 09:04:10 -0400
Subject: [AstroPy] Question on astropy.coordinates internals
In-Reply-To: <6C794AF3-7AFC-4F96-9775-011435D522D2@cea.fr>
References: <6C794AF3-7AFC-4F96-9775-011435D522D2@cea.fr>
Message-ID: <CAEUL7mFAPOdai2dJmFLGAtJv=ZL7huqWyrTKKD2K+c4qLF8doQ@mail.gmail.com>

Hi Herv? --

> What is the correct way to check that an input is a bona fide reference frame ? Playing around, I have come with this:

Slightly better I think is to check:

isinstance(my_input_frame, coord.baseframe.BaseCoordinateFrame)

> Is there a way to access the directly the coodinate tranformation matrix ? So far, I use the transformation on each of the cartesian unit vector to build the rotation matrix, but this is a bit clunky...

Which coordinate transformation matrix? If a given transformation is
implemented as one of the MatrixTransform classes, you can get the
matrix directly from the function that implements the transformation.
These are all in astropy/coordinates/builtin_frames/. An example would
be the transformation from FK5 to Galactic coordinates, implemented in
astropy/coordinates/builtin_frames/galactic_transforms.py

With a given set of FK5 coordinates (as an FK5 instance "fk5"), you can do:

fk5_coords = coord.FK5(ra=18*u.deg, dec=-11*u.deg)
matrix = coord.builtin_frames.galactic_transforms.fk5_to_gal(fk5_coords,
coord.Galactic)

However, not all transformations are implemented as MatrixTransform's.
The coloring of the edges in the frame transform graph here:
http://docs.astropy.org/en/latest/coordinates/index.html#module-astropy.coordinates
show what the class of the transformation is. The AffineTransform
transformations (new in v2.0) return a matrix and a vector offset. The
FunctionTransform's implement the transformation directly and return
the new set of coordinates in the desired frame, so it wouldn't be
possible to get a transformation matrix from any of those.

Happy to help more if anything is unclear!

Thanks,
Adrian

On Thu, Jul 6, 2017 at 11:20 AM, Herv? Aussel <herve.aussel at cea.fr> wrote:
>         Hello,
>
> I am working on a package to handle spacecrafts attitudes in python, and I would like to build on the astropy.coordinates package, especially to handle transformations between reference frames. I have a few questions regarding the internals of the package.
>
> - What is the correct way to check that an input is a bona fide reference frame ? Playing around, I have come with this:
> import astropy.coordinates as coord
> isinstance(my_input_frame, coord.baseframe.FrameMeta)
>
> - Is there a way to access the directly the coodinate tranformation matrix ? So far, I use the transformation on each of the cartesian unit vector to build the rotation matrix, but this is a bit clunky...
>
> Thanks for your help,
>
> Cheers,
>
> Herv?
>
>
>
> -----------------------------------------------------------------------------------------
> Herv? Aussel
>
> EC SPV Lead
>
> AIM Paris-Saclay                                  phone: (+33) 01 69 08 95 79
> UMR 7158                                             fax  : (+33) 01 69 08 65 77
> Bat 709 CE-Saclay
> Orme des Merisiers                              email: herve.aussel at cea.fr
> F 91 191 Gif-sur-Yvette
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy



-- 
Adrian M. Price-Whelan
Lyman Spitzer, Jr. Postdoctoral Fellow
Princeton University
http://adrian.pw

From erik.tollerud at gmail.com  Sat Jul  8 00:24:33 2017
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Sat, 8 Jul 2017 00:24:33 -0400
Subject: [AstroPy] ANN: Astropy v2.0 released
Message-ID: <CAARXUwX0FRbrmjGbji0TswPwiFWCYQHu9C4aON-0UceG9PZbTg@mail.gmail.com>

Dear colleagues,

We are very happy to announce the v2.0 release of the Astropy package,
a core Python package for Astronomy:

http://www.astropy.org

Astropy is a community-driven Python package intended to contain much
of the core functionality and common tools needed for astronomy and
astrophysics.

New and improved major functionality in this release includes:

* Most models now support parameters having units (i.e., being
Quantity objects).
* A new CCDData class that is directly useful for typical astronomical
images and implements the NDData interface.
* Coordinate frame objects can now carry proper motions and radial
velocities, and will carry them through and transform them between
frames. (This functionality is experimental and feedback is greatly
desired.)
* Many of the typical mixin columns for astropy tables can now be
saved into ECSV files and fully round-tripped.
* The fft and direct versions of the convolution algorithm in
astropy.convolution are now more consistent and work better with
typical use cases.
* A variety of additions to the astropy.stats subpackage

In addition, hundreds of smaller improvements and fixes have been
made. An overview of the changes is provided at:

    http://docs.astropy.org/en/stable/whatsnew/2.0.html

Note that the Astropy 2.x series will be the last versions of Astropy
that will support Python 2.x. Future versions of Astropy will only
support Python 3.x.

Instructions for installing Astropy are provided on our website, and
extensive documentation can be found at:

    http://docs.astropy.org

If you make use of the Anaconda Python Distribution, you can update to
Astropy v2.0 with:

 conda update astropy

If you normally use pip, you can upgrade with:

 pip install astropy --upgrade

Please report any issues, or request new features via our GitHub repository:

 https://github.com/astropy/astropy/issues

Over 232 developers have contributed code to Astropy so far, and you
can find out more about the team behind Astropy here:

    http://www.astropy.org/team.html

Astropy v2.0 now repaces v1.0 as the long term support release, and
will be supported until the end of 2019. The next major release of
Astropy (scheduled for January 2018) will only support Python 3.x. So
if you need to use Astropy in a very stable environment in Python 2.7,
you should continue to use the 2.0.x series after 3.0.x is released.

If you use Astropy directly for your work, or as a dependency to
another package, please remember to include the following
acknowledgment at the end of papers:

?This research made use of Astropy, a community-developed core Python
package for Astronomy (Astropy Collaboration, 2013).?

where (Astropy Collaboration, 2013) is a reference to the Astropy paper:

 http://dx.doi.org/10.1051/0004-6361/201322068

Please feel free to forward this announcement to anyone you think
might be interested in this release! The announcement can also be
found online at http://www.astropy.org/announcements/release-2.0.html.


Special thanks to the coordinator for this release: Brigitta Sipocz.

Erik Tollerud, Tom Robitaille, Kelle Cruz, and Tom Aldcroft
on behalf of The Astropy Collaboration

From duncan.macleod at ligo.org  Mon Jul 10 08:34:57 2017
From: duncan.macleod at ligo.org (Duncan Macleod)
Date: Mon, 10 Jul 2017 13:34:57 +0100
Subject: [AstroPy] Revert to astropy 1.3 constants (for testing) in astropy
 2.0
Message-ID: <CAEaL-c4M1DQNwNTGv+=SZVEmFC5aNAuAyB-eRmWsnKBWBYcbVA@mail.gmail.com>

Hi all,

Is there a way to tell astropy.constants to use the version 1.3 constants
(from astropy.constants.astropyconst13) when using the v2.0 package? i.e.
have astropy.constants.M_sun come from iau2012 and not iau2015?

I have a bunch of unit tests are now failing because of the relatively
large changes in some constants.*


Thanks
Duncan

*I understand I could 'just update the tests', but in principle that would
be nice to avoid, I have my reasons.
-- 
Duncan Macleod
duncan.macleod at ligo.org
S?r Cymru Cofund Fellow
School of Physics and Astronomy
Cardiff University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20170710/cbbc387b/attachment.html>

From derek at astro.physik.uni-goettingen.de  Mon Jul 10 09:56:49 2017
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Mon, 10 Jul 2017 15:56:49 +0200
Subject: [AstroPy] Revert to astropy 1.3 constants (for testing) in
 astropy 2.0
In-Reply-To: <CAEaL-c4M1DQNwNTGv+=SZVEmFC5aNAuAyB-eRmWsnKBWBYcbVA@mail.gmail.com>
References: <CAEaL-c4M1DQNwNTGv+=SZVEmFC5aNAuAyB-eRmWsnKBWBYcbVA@mail.gmail.com>
Message-ID: <0C479C10-D032-48E9-AE65-16DD361F1316@astro.physik.uni-goettingen.de>

On 10 Jul 2017, at 2:34 pm, Duncan Macleod <duncan.macleod at ligo.org> wrote:
> 
> Is there a way to tell astropy.constants to use the version 1.3 constants (from astropy.constants.astropyconst13) when using the v2.0 package? i.e. have astropy.constants.M_sun come from iau2012 and not iau2015?
> 
> I have a bunch of unit tests are now failing because of the relatively large changes in some constants.*
> 
Depends on how you currently import them, but replacing e.g.

from astropy import constants as const

with

from astropy.constants import astropyconst13 as const

should have the desired effect.

HTH
						Derek


From duncan.macleod at ligo.org  Mon Jul 10 10:01:52 2017
From: duncan.macleod at ligo.org (Duncan Macleod)
Date: Mon, 10 Jul 2017 15:01:52 +0100
Subject: [AstroPy] Revert to astropy 1.3 constants (for testing) in
 astropy 2.0
In-Reply-To: <0C479C10-D032-48E9-AE65-16DD361F1316@astro.physik.uni-goettingen.de>
References: <CAEaL-c4M1DQNwNTGv+=SZVEmFC5aNAuAyB-eRmWsnKBWBYcbVA@mail.gmail.com>
 <0C479C10-D032-48E9-AE65-16DD361F1316@astro.physik.uni-goettingen.de>
Message-ID: <CAEaL-c5VEwOh1Nyhh=kqPn2D-ACSctDuUjtu-OW5OC3FaUc37Q@mail.gmail.com>

Hi Derek,

Unfortunately, I don't want to change the imports in my module, but only in
the test suite. Essentially I want to mock the constants module back to
astropy-1.3 values.

In the end I ended up with the following in my test module:

from astropy import __version__ as astropy_version
if astropy_version >= '2.0':
    from astropy import constants
    from astropy.constants import (si, astropyconst13)
    units.M_sun._represents = units.Unit(astropyconst13.M_sun)
    constants.M_sun = si.M_sun = astropyconst13.M_sun
    constants.G = si.G = astropyconst13.G
    constants.c = si.c = astropyconst13.c
    constants.pc = si.pc = astropyconst13.pc

to just fix the constants I need without editing the module code that
actually uses them. This is after the module import, but before any
function calls. A bit messy, but does the job.


D

On 10 July 2017 at 14:56, Derek Homeier <
derek at astro.physik.uni-goettingen.de> wrote:

> On 10 Jul 2017, at 2:34 pm, Duncan Macleod <duncan.macleod at ligo.org>
> wrote:
> >
> > Is there a way to tell astropy.constants to use the version 1.3
> constants (from astropy.constants.astropyconst13) when using the v2.0
> package? i.e. have astropy.constants.M_sun come from iau2012 and not
> iau2015?
> >
> > I have a bunch of unit tests are now failing because of the relatively
> large changes in some constants.*
> >
> Depends on how you currently import them, but replacing e.g.
>
> from astropy import constants as const
>
> with
>
> from astropy.constants import astropyconst13 as const
>
> should have the desired effect.
>
> HTH
>                                                 Derek
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>



-- 
Duncan Macleod
duncan.macleod at ligo.org
S?r Cymru Cofund Fellow
School of Physics and Astronomy
Cardiff University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20170710/5ee98f20/attachment.html>

From joaquinbogado at gmail.com  Thu Jul 20 19:09:20 2017
From: joaquinbogado at gmail.com (=?UTF-8?B?Sm9hcXXDrW4=?=)
Date: Thu, 20 Jul 2017 20:09:20 -0300
Subject: [AstroPy] Any experience with .SER files?
Message-ID: <CADaWhunF8+PuQ4v=17-Jd8FFd3ZmV7d3k6uGyVBtZcCiKfRFsQ@mail.gmail.com>

Hello there...
Don't know if any of you have experience with .SER files. It's a video
format without compression very popular among amateur planetary
astrophotographers. I couldn't find any library that allow me to import the
data to astropy so I wrote one myself.

Thing is, the SER format embed a UTC time stamp per frame and what I want
to know is what is the best way to include this information in an astropy
NDData structure.

I already have a read function that reads the frames from the SER file and
returns a numpy array of frames and another numpy array with one astropy
Time per frame. I'm trying to wrote the code in a way I can register the
function using the astropy.io.registry interface.

Thanks for the help. As soon as I solve this, I will  submit the code for
review.

Cheers from Argentina

-- 
Joaqu?n Bogado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20170720/33180318/attachment.html>