From mcraig at mnstate.edu  Tue Aug  2 11:15:17 2016
From: mcraig at mnstate.edu (Matthew Craig)
Date: Tue, 2 Aug 2016 15:15:17 +0000
Subject: [AstroPy] ANN: Release of ccdproc 1.1
Message-ID: <D1EA16F6-0724-4F53-B889-F1ECCB84C425@mnstate.edu>

Dear colleagues,

We are pleased to announce the release of ccdproc v1.1.

Ccdproc is is an Astropy affiliated package for basic data
reduction of CCD images.    Besides basic  data reduction, some of
the useful features in ccdproc include:

- propogation of uncertainties and tracking of bad pixels
- ImageFileCollections for easy sorting images by FITS keywords
- combination of images based on WCS
- easily built pipelines

The new release features many bug fixes and the addition of a combination method like IRAF?s clipping of extrema (min and/or max).

Installation
http://ccdproc.readthedocs.org/en/latest/ccdproc/install.html

Documentation
http://ccdproc.readthedocs.org/en/latest/

More Information, repository, and issue tracker
https://github.com/astropy/ccdproc

Special thanks to all the new contributors since the last major
release including Javier Blasco, Elias Holte and James McCorma.

We would also like to thank the contributions to astropy especially
the NDData package, astroscrappy, reproject, numpy, scipy, and the
astropy-helpers package.

Feedback, contributions, and comments are welcome.  We would
especially be interested in contributions of examples of using ccdproc and
comparisons to other reduction methods.


Cheers,
Steve Crawford and Matt Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160802/50538c3f/attachment.html>

From rays at blue-cove.com  Tue Aug  2 11:49:49 2016
From: rays at blue-cove.com (R Schumacher)
Date: Tue, 02 Aug 2016 08:49:49 -0700
Subject: [AstroPy] ANN: Release of ccdproc 1.1
In-Reply-To: <D1EA16F6-0724-4F53-B889-F1ECCB84C425@mnstate.edu>
References: <D1EA16F6-0724-4F53-B889-F1ECCB84C425@mnstate.edu>
Message-ID: <201608021549.u72Fntrt007055@blue-cove.com>

At 08:15 AM 8/2/2016, Matthew Craig wrote:

>Dear colleagues,
>
>We are pleased to announce the release of ccdproc v1.1.
>
>Ccdproc is is an Astropy affiliated package for basic data
>reduction of CCD images.

Years ago I wrote a script which combined various length exposures 
via exposure time with masked arrays where each contributing exposure 
length had clip/mask points (primarily white clip in long exposures 
and dark in short).
Is such a thing planned? It's a fairly simple algo.
http://ccdproc.readthedocs.io/en/latest/api/ccdproc.Combiner.html#ccdproc.Combiner

The result is high dynamic range, with variable noise in 2D space. 
I'm sure a 2D STD could be calculated per pixel, but I did not.

- Ray Schumacher 



From crawfordsm at gmail.com  Tue Aug  2 12:05:17 2016
From: crawfordsm at gmail.com (Steve Crawford)
Date: Tue, 2 Aug 2016 18:05:17 +0200
Subject: [AstroPy] ANN: Release of ccdproc 1.1
In-Reply-To: <201608021549.u72Fntrt007055@blue-cove.com>
References: <D1EA16F6-0724-4F53-B889-F1ECCB84C425@mnstate.edu>
 <201608021549.u72Fntrt007055@blue-cove.com>
Message-ID: <CAE+obB-FE-ApW9B==PfbRO3773J1MVQigRbvJcsmmeSoZyHdaQ@mail.gmail.com>

Hi Ray--

I think something like that would be possible with scaling in the
current combiner although not 100% sure of what your script might be
doing.     We would certainly welcome that type of contribution as I
think it might be of interested to other people.  If you are willing,
please open an issue or  a pull request and that might be a better
place to discuss it further.   Thanks for your interest!

Cheers
Steve

On Tue, Aug 2, 2016 at 5:49 PM, R Schumacher <rays at blue-cove.com> wrote:
> At 08:15 AM 8/2/2016, Matthew Craig wrote:
>
>> Dear colleagues,
>>
>> We are pleased to announce the release of ccdproc v1.1.
>>
>> Ccdproc is is an Astropy affiliated package for basic data
>> reduction of CCD images.
>
>
> Years ago I wrote a script which combined various length exposures via
> exposure time with masked arrays where each contributing exposure length had
> clip/mask points (primarily white clip in long exposures and dark in short).
> Is such a thing planned? It's a fairly simple algo.
> http://ccdproc.readthedocs.io/en/latest/api/ccdproc.Combiner.html#ccdproc.Combiner
>
> The result is high dynamic range, with variable noise in 2D space. I'm sure
> a 2D STD could be calculated per pixel, but I did not.
>
> - Ray Schumacher
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From elkewschaper at gmail.com  Thu Aug  4 06:33:14 2016
From: elkewschaper at gmail.com (Elke Schaper)
Date: Thu, 4 Aug 2016 12:33:14 +0200
Subject: [AstroPy] Units with time-dependent conversion
Message-ID: <85543EC0-F1BC-463F-8B16-21FFD0F5A5A8@gmail.com>

Dear Astropy-Team,


thanks for a great tool first of all!
Perhaps this question has been asked before:

We would like to add ?Currency? as a unit system to astropy, with units such as ?USD?, ?EUR?, ? 
This would allow to use all of the great astropy functionality (e.g. the close integration with numpy) on monetary data also, combined with all already integrated units.

In principle, new units are easy to add to Astropy.
Now comes the challenge:

Conversions between these units change with time. For example, there are other great Python packages (such as https://pypi.python.org/pypi/CurrencyConverter/0.5 <https://pypi.python.org/pypi/CurrencyConverter/0.5>) to do a time dependent conversion. 

Is it possible to add ?time? as an input parameter to unit conversion in Astropy?
If yes, could you give me some hints how to best go ahead (I would probably need to overwrite some of the internal functionality?). Or is this a solved problem, just I overlooked it?



Thanks a lot, all the best!


Elke





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160804/64dc61bd/attachment.html>

From jjk at uvic.ca  Thu Aug  4 13:26:34 2016
From: jjk at uvic.ca (JJ Kavelaars)
Date: Thu, 4 Aug 2016 10:26:34 -0700
Subject: [AstroPy] Units with time-dependent conversion
In-Reply-To: <85543EC0-F1BC-463F-8B16-21FFD0F5A5A8@gmail.com>
References: <85543EC0-F1BC-463F-8B16-21FFD0F5A5A8@gmail.com>
Message-ID: <35A2976A-6BBC-4A4E-A7A5-28B77F918AA2@uvic.ca>

Perhaps currency is a coordinate transform rather than a unit change.

JJ

> On Aug 4, 2016, at 3:33 AM, Elke Schaper <elkewschaper at gmail.com> wrote:
> 
> Dear Astropy-Team,
> 
> 
> thanks for a great tool first of all!
> Perhaps this question has been asked before:
> 
> We would like to add ?Currency? as a unit system to astropy, with units such as ?USD?, ?EUR?, ? 
> This would allow to use all of the great astropy functionality (e.g. the close integration with numpy) on monetary data also, combined with all already integrated units.
> 
> In principle, new units are easy to add to Astropy.
> Now comes the challenge:
> 
> Conversions between these units change with time. For example, there are other great Python packages (such as https://pypi.python.org/pypi/CurrencyConverter/0.5 <https://pypi.python.org/pypi/CurrencyConverter/0.5>) to do a time dependent conversion. 
> 
> Is it possible to add ?time? as an input parameter to unit conversion in Astropy?
> If yes, could you give me some hints how to best go ahead (I would probably need to overwrite some of the internal functionality?). Or is this a solved problem, just I overlooked it?
> 
> 
> 
> Thanks a lot, all the best!
> 
> 
> Elke
> 
> 
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160804/89eaaeb9/attachment.html>

From baweaver at lbl.gov  Thu Aug  4 13:27:00 2016
From: baweaver at lbl.gov (Benjamin Alan Weaver)
Date: Thu, 4 Aug 2016 10:27:00 -0700
Subject: [AstroPy] PyDL v0.5.2 released
Message-ID: <CAC0qNe8Cg-=SjEnBAYvzwy9hJKUX+M5Mp=hb647LhrYf5yCK2g@mail.gmail.com>

Hello y'all,

PyDL v0.5.2 has been released.  This is primarily a bug fix release.  See
http://pydl.readthedocs.io/en/stable/pydl/changes.html for details.

PyDL is available at https://pypi.python.org/pypi/pydl

Kia ora koutou,
Benjamin Alan Weaver

-- 
Outside of a dog, a book is man's best friend. Inside of a dog it's too
dark to read.
  --Groucho Marx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160804/7570a503/attachment.html>

From thomas.robitaille at gmail.com  Tue Aug  9 12:23:51 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 9 Aug 2016 17:23:51 +0100
Subject: [AstroPy] Astropy Proposal for Enhancement: A roadmap for Python
	3-only support
Message-ID: <CAGMHX_2oaw3fWTrreKUWVUURZDqUNdPCUfHRvPJwk-qF=4WbBQ@mail.gmail.com>

Hi everyone,

[note that this was previously sent to astropy-dev only, but we are
now sending it out more widely to make sure users have a chance to
comment]

Python 2.7 will cease to be supported on January 1st 2020. As a
result, a number of scientific Python projects, including IPython,
Matplotlib, Sympy, and others have now signed the Python 3 statement,
which states that scientific Python packages will drop support for
Python 2 no later than 2020. For instance, the IPython developers have
now released IPython 5.0, which will be the last major release to
support Python 2.

I have written an Astropy Proposal for Enhancement (APE) that outlines
a suggested roadmap for future Astropy releases:

  https://github.com/astrofrog/astropy-APEs/blob/ape-python-3/APE10.rst

[for the background, APEs are a mechanism within the Astropy project
inspired by the Python Enhancement Proposals (PEPs), with the aim of
describing possible big changes that users and developers can then
comment on]

In this suggested roadmap, we would release a long term support (LTS)
version compatible with Python 2 and 3 next spring, which would be
supported until the end of 2019, while the first major release not
compatible with Python 2 would be in December 2017.

It is important to note that ending support for Python 2 by the end of
2019 does not mean that Python2 users will no longer be able to
install or use Astropy from 2020 onwards. Existing Astropy releases
will remain available indefinitely. Instead, the proposed roadmap
means that only new features developed after mid-2017 will be
available only to Python 3 users, and that we will not fix bugs for
Python 2-compatible releases after 2019.

We welcome feedback on this APE for the next couple of weeks, and by
August 19th at the latest. You can leave feedback on this pull
request:

 https://github.com/astropy/astropy-APEs/pull/13

After this date, depending on the level of consensus, the Astropy
coordination committee will either accept the APE (if there are no or
almost no objections), or settle on a decision process or a way
forward (if the APE is controversial).

Thanks!
Tom


From pdzwig at summaventures.com  Wed Aug 10 11:12:08 2016
From: pdzwig at summaventures.com (Peter Dzwig)
Date: Wed, 10 Aug 2016 16:12:08 +0100
Subject: [AstroPy] Units with time-dependent conversion
In-Reply-To: <35A2976A-6BBC-4A4E-A7A5-28B77F918AA2@uvic.ca>
References: <85543EC0-F1BC-463F-8B16-21FFD0F5A5A8@gmail.com>
 <35A2976A-6BBC-4A4E-A7A5-28B77F918AA2@uvic.ca>
Message-ID: <a606f18d-4093-8d8f-920d-8a56f95a6523@summaventures.com>

...but how much historic data do you want to have to hold? and at what granularity?

Peter Dzwig

On 04/08/2016 18:26, JJ Kavelaars wrote:
> Perhaps currency is a coordinate transform rather than a unit change.
> 
> JJ
> 
>> On Aug 4, 2016, at 3:33 AM, Elke Schaper <elkewschaper at gmail.com
>> <mailto:elkewschaper at gmail.com>> wrote:
>>
>> Dear Astropy-Team,
>>
>>
>> thanks for a great tool first of all!
>> Perhaps this question has been asked before:
>>
>> We would like to add ?Currency? as a unit system to astropy, with units such
>> as ?USD?, ?EUR?, ? 
>> This would allow to use all of the great astropy functionality (e.g. the close
>> integration with numpy) on monetary data also, combined with all already
>> integrated units.
>>
>> In principle, new units are easy to add to Astropy.
>> Now comes the challenge:
>>
>> Conversions between these units change with time. For example, there are other
>> great Python packages (such
>> as https://pypi.python.org/pypi/CurrencyConverter/0.5) to do a time dependent
>> conversion. 
>>
>> Is it possible to add ?time? as an input parameter to unit conversion in Astropy?
>> If yes, could you give me some hints how to best go ahead (I would probably
>> need to overwrite some of the internal functionality?). Or is this a solved
>> problem, just I overlooked it?
>>
>>
>>
>> Thanks a lot, all the best!
>>
>>
>> Elke
>>
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 

-- 

===========================================================
Dr Peter Dzwig				



From erwin at mpe.mpg.de  Sat Aug 13 04:38:54 2016
From: erwin at mpe.mpg.de (Peter Erwin)
Date: Sat, 13 Aug 2016 10:38:54 +0200
Subject: [AstroPy] Python code for reading STSDAS table files?
Message-ID: <948F6118-9AE8-41D7-8A1A-10572F61AF09@mpe.mpg.de>

Does anyone know of any Python code for reading STSDAS table files (in their
native binary format)?

(Obviously there are STSDAS tools for generating FITS and text-file tables from
STSDAS tables, but I was wondering if there was a way to read the STSDAS
tables directly.)

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 varunb at iucaa.in  Wed Aug 17 01:59:01 2016
From: varunb at iucaa.in (Varun Bhalerao)
Date: Wed, 17 Aug 2016 11:29:01 +0530
Subject: [AstroPy] Reading Time columns from ascii tables
Message-ID: <728F1469-30DA-40CD-8366-B5C0DB89283A@iucaa.in>

Dear all,

I have a table which has UT dates, and I want the final astropy Table to have astropy.time.Time objects. Currently, I have a roundabout way of doing it. Can I directly supply the dtype or something else to tell Table.read() that this is a astropy.time column?

Sample table:
rccd160711.0024_s.fits 13.113 0.005 2016-07-18T17:37:07
rccd160711.0025_s.fits 14.269 0.011 2016-07-18T17:37:12
rccd160711.0026_s.fits 14.203 0.011 2016-07-18T17:37:12
rccd160711.0027_s.fits 14.224 0.010 2016-07-18T17:37:12
rccd160711.0028_s.fits 13.637 0.007 2016-07-18T17:37:10
rccd160711.0029_s.fits 13.657 0.007 2016-07-18T17:37:10
rccd160711.0030_s.fits 13.659 0.007 2016-07-18T17:37:11

Current code:
from astropy.table import Table, column
tab = Table.read("sample.txt", names=("filename", "mag", "err", "time"), format="ascii")

# Now replace the time column
timecol = Column(name="time", data=Time(tab["time"]))
tab.remove_column("time")
tab.add_column(timecol)


Thanks,
-- Varun
____________________
-  Varun Bhalerao  -
Office: A 214, IUCAA
Ph: +91 20 2560 4214
www.iucaa.in/~varunb

This email is encrypted and signed with OpenPGP.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/astropy/attachments/20160817/ee898c91/attachment.sig>

From hessman at astro.physik.uni-goettingen.de  Wed Aug 17 06:30:05 2016
From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman)
Date: Wed, 17 Aug 2016 12:30:05 +0200
Subject: [AstroPy] Fixing broken FITS headers
Message-ID: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>

I'm stuck with some FITS files with headers where non-ascii characters have been used (German umlauts).  If I try to read them using astropy.io.fits, I of course get an input error, since the ascii codec balks :

WARNING: VerifyWarning: Error validating header for HDU #0 (note: Astropy uses zero-based indexing).
    'ascii' codec can't decode byte 0xf6 in position 896: ordinal not in range(128)
There may be extra bytes after the last HDU or the file is corrupted. [astropy.io.fits.hdu.hdulist]
Traceback (most recent call last):
  File "/Users/hessman/Library/python/fitsfix.py", line 23, in <module>
    hdus = fits.open(thing)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/astropy/io/fits/hdu/hdulist.py", line 138, in fitsopen
    return HDUList.fromfile(name, mode, memmap, save_backup, cache, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/astropy/io/fits/hdu/hdulist.py", line 280, in fromfile
    save_backup=save_backup, cache=cache, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/astropy/io/fits/hdu/hdulist.py", line 870, in _readfrom
    raise IOError('Empty or corrupt FITS file')
OSError: Empty or corrupt FITS file

Is there some easy way of forcing acceptance (so that I can repair the header) or replacing the codec?  Don?t see anything obvious in the API?.

The write() method has an output_verify option (e.g. ?fix+warn?) : would be very nice to have an input_verify option as well.

Rick



From derek at astro.physik.uni-goettingen.de  Wed Aug 17 06:50:50 2016
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Wed, 17 Aug 2016 12:50:50 +0200
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
Message-ID: <93902A37-01C6-4F33-B762-E41518442BDF@astro.physik.uni-goettingen.de>

Hi Rick,
> 
> I'm stuck with some FITS files with headers where non-ascii characters have been used (German umlauts).  If I try to read them using astropy.io.fits, I of course get an input error, since the ascii codec balks :
> 
> WARNING: VerifyWarning: Error validating header for HDU #0 (note: Astropy uses zero-based indexing).
>    'ascii' codec can't decode byte 0xf6 in position 896: ordinal not in range(128)
> There may be extra bytes after the last HDU or the file is corrupted. [astropy.io.fits.hdu.hdulist]
> Traceback (most recent call last):
>  File "/Users/hessman/Library/python/fitsfix.py", line 23, in <module>
>    hdus = fits.open(thing)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/astropy/io/fits/hdu/hdulist.py", line 138, in fitsopen
>    return HDUList.fromfile(name, mode, memmap, save_backup, cache, **kwargs)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/astropy/io/fits/hdu/hdulist.py", line 280, in fromfile
>    save_backup=save_backup, cache=cache, **kwargs)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/astropy/io/fits/hdu/hdulist.py", line 870, in _readfrom
>    raise IOError('Empty or corrupt FITS file')
> OSError: Empty or corrupt FITS file
> 
> Is there some easy way of forcing acceptance (so that I can repair the header) or replacing the codec?  Don?t see anything obvious in the API?.
> 
there are some comments regarding this in io/fits/header.py incl. the suggestion to use `decode_latin`
instead of `decode_ascii` for the unicode conversion; however nothing in that direction seems to have
been implemented yet.
But there is a similar issue on file
https://github.com/astropy/astropy/issues/5093
which indicates that for the time being you might be able to work around the error by using the Python2.7
version, skipping the whole string/unicode conversion.

Greetings from Heidelberg!

				Derek




From demitri.muna at gmail.com  Wed Aug 17 10:22:02 2016
From: demitri.muna at gmail.com (Demitri Muna)
Date: Wed, 17 Aug 2016 10:22:02 -0400
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
Message-ID: <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>

Hi Rick,

On Aug 17, 2016, at 6:30 AM, Frederic V. Hessman <hessman at astro.physik.uni-goettingen.de> wrote:

> Is there some easy way of forcing acceptance (so that I can repair the header) or replacing the codec?  Don?t see anything obvious in the API?.

Not speaking as someone who wrote the software, but it wouldn't be an easy thing to do. The FITS format is extremely specific on a byte-to-byte basis, and trying to understand how a file is broken wouldn't be straightforward. I actually recommend such a program should not be part of astropy.io.fits but something standalone, but that's neither here nor there.

Since the problem is in the first header, it's easier to solve. The format of the header is a series of 80 byte (80 character) cards. The last one has a keyword of "END" followed by 77 spaces. There may be additional empty (spaces) 80 character blocks after that before the data starts.

To fix the file, I'd open it as a binary file and begin reading it 80 bytes at a time. Cast those bytes to a UTF-8 string. One of those "lines" will contain your umlaut (hopefully there is just one?). If the line doesn't contain the umlaut, write it back (as binary!) out to a new file. Replace the umlaut character with something valid in the string and write it to the new file. Now just read the rest of the file from that point and write it directly to the new file.

If there is more than one umlaut you just need to repeat this. Remember that the character is two bytes, so the line that contains it is one character short from what the actual header line is. It will be a matter of bookkeeping then. This may sound complicated, but it should be pretty straightforward.


Do you know what software wrote that file? I'd strongly argue that any FITS writer should not output invalid files in the first place. My guess is that it came from IDL, which as far as FITS writers go, is the wild west.

Cheers,
Demitri

_________________________________________
Demitri Muna
http://muna.com

Department of Astronomy
La Ohio State University

My Projects:
http://nightlightapp.io
http://trillianverse.org
http://scicoder.org




From derek at astro.physik.uni-goettingen.de  Wed Aug 17 10:50:04 2016
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Wed, 17 Aug 2016 16:50:04 +0200
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
Message-ID: <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>

On 17 Aug 2016, at 4:22 pm, Demitri Muna <demitri.muna at gmail.com> wrote:
> 
>> Is there some easy way of forcing acceptance (so that I can repair the header) or replacing the codec?  Don?t see anything obvious in the API?.
> 
> Not speaking as someone who wrote the software, but it wouldn't be an easy thing to do. The FITS format is extremely specific on a byte-to-byte basis, and trying to understand how a file is broken wouldn't be straightforward. I actually recommend such a program should not be part of astropy.io.fits but something standalone, but that's neither here nor there.
> 
> Since the problem is in the first header, it's easier to solve. The format of the header is a series of 80 byte (80 character) cards. The last one has a keyword of "END" followed by 77 spaces. There may be additional empty (spaces) 80 character blocks after that before the data starts.
> 
> To fix the file, I'd open it as a binary file and begin reading it 80 bytes at a time. Cast those bytes to a UTF-8 string. One of those "lines" will contain your umlaut (hopefully there is just one?). If the line doesn't contain the umlaut, write it back (as binary!) out to a new file. Replace the umlaut character with something valid in the string and write it to the new file. Now just read the rest of the file from that point and write it directly to the new file.
> 
I?d agree it?s probably not that straightforward (which might be why the `decode_latin` idea
has never been implemented thus far), and after doing some experiments I found that while
astropy-py27 will open the file and the hdu, it still throws an error on accessing the header
card with the umlaut, and hdu.verify('fix') fails on the header as well.

If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
noted, make sure to replace each umlaut with two ASCII chars.

HTH,
					Derek




From demitri.muna at gmail.com  Wed Aug 17 14:04:59 2016
From: demitri.muna at gmail.com (Demitri Muna)
Date: Wed, 17 Aug 2016 14:04:59 -0400
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
Message-ID: <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>


On Aug 17, 2016, at 10:50 AM, Derek Homeier <derek at astro.physik.uni-goettingen.de> wrote:

> If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
> noted, make sure to replace each umlaut with two ASCII chars.

Nice tip! If you resize your terminal window to display 80 characters in width it will be pretty obvious what kind of padding is needed.

Demitri

_________________________________________
Demitri Muna
http://muna.com

Department of Astronomy
Der Ohio State University


My Projects:
http://nightlightapp.io
http://trillianverse.org
http://scicoder.org






From thomas.robitaille at gmail.com  Wed Aug 17 17:45:42 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Wed, 17 Aug 2016 22:45:42 +0100
Subject: [AstroPy] Units with time-dependent conversion
In-Reply-To: <85543EC0-F1BC-463F-8B16-21FFD0F5A5A8@gmail.com>
References: <85543EC0-F1BC-463F-8B16-21FFD0F5A5A8@gmail.com>
Message-ID: <CAGMHX_012QoY2oi900Bg1NNHM3tkypPJbGr7xVMAtmYPrzBjpA@mail.gmail.com>

Hi Elke,

I think it might be possible to do this by defining a new unit
equivalency that can take a time as an argument:

http://docs.astropy.org/en/stable/units/equivalencies.html#writing-new-equivalencies

The code for this would look something like this:

def currency_conversion(time):
    # figure out the conversion rates based on time
    return [(u.EUR, u.USD, lambda x: x * EUR2USD, lambda x: x / EUR2USD), ...]

and you can return as many pairs of conversions as you like (see the
above link for more details). The you could use it like:

>>> (4 * u.EUR).to(u.USD, currency_conversion(Time.now()))

Cheers,
Tom



On 4 August 2016 at 11:33, Elke Schaper <elkewschaper at gmail.com> wrote:
> Dear Astropy-Team,
>
>
> thanks for a great tool first of all!
> Perhaps this question has been asked before:
>
> We would like to add ?Currency? as a unit system to astropy, with units such
> as ?USD?, ?EUR?, ?
> This would allow to use all of the great astropy functionality (e.g. the
> close integration with numpy) on monetary data also, combined with all
> already integrated units.
>
> In principle, new units are easy to add to Astropy.
> Now comes the challenge:
>
> Conversions between these units change with time. For example, there are
> other great Python packages (such as
> https://pypi.python.org/pypi/CurrencyConverter/0.5) to do a time dependent
> conversion.
>
> Is it possible to add ?time? as an input parameter to unit conversion in
> Astropy?
> If yes, could you give me some hints how to best go ahead (I would probably
> need to overwrite some of the internal functionality?). Or is this a solved
> problem, just I overlooked it?
>
>
>
> Thanks a lot, all the best!
>
>
> Elke
>
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From hjyanghj at gmail.com  Wed Aug 17 23:02:41 2016
From: hjyanghj at gmail.com (Yang Hon-Jang)
Date: Thu, 18 Aug 2016 11:02:41 +0800
Subject: [AstroPy] Where is the cache file de430.bsp in local machine?
Message-ID: <CACVX7WRg-ZcupAcY8a-8Lv+vwtHNNLjizGb+hKasRdcNq4akhA@mail.gmail.com>

First time I execute the script get_body('sun', t,  ephemeris='jpl'),
I see following message?
Downloading
http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de430.bsp
[Done]

But I can't locate the file de430.bsp in my local computer.
Where is it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160818/5af9004a/attachment.html>

From aldcroft at head.cfa.harvard.edu  Wed Aug 17 23:07:16 2016
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Wed, 17 Aug 2016 23:07:16 -0400
Subject: [AstroPy] Reading Time columns from ascii tables
In-Reply-To: <728F1469-30DA-40CD-8366-B5C0DB89283A@iucaa.in>
References: <728F1469-30DA-40CD-8366-B5C0DB89283A@iucaa.in>
Message-ID: <CAMtEP6x_=Hvu+N9TQ+mFtPUEA6qtw8Acfv4v4s9yQMZTxfPL7A@mail.gmail.com>

On Wed, Aug 17, 2016 at 1:59 AM, Varun Bhalerao <varunb at iucaa.in> wrote:

> Dear all,
>
> I have a table which has UT dates, and I want the final astropy Table to
> have astropy.time.Time objects. Currently, I have a roundabout way of doing
> it. Can I directly supply the dtype or something else to tell Table.read()
> that this is a astropy.time column?
>
> Sample table:
> rccd160711.0024_s.fits 13.113 0.005 2016-07-18T17:37:07
> rccd160711.0025_s.fits 14.269 0.011 2016-07-18T17:37:12
> rccd160711.0026_s.fits 14.203 0.011 2016-07-18T17:37:12
> rccd160711.0027_s.fits 14.224 0.010 2016-07-18T17:37:12
> rccd160711.0028_s.fits 13.637 0.007 2016-07-18T17:37:10
> rccd160711.0029_s.fits 13.657 0.007 2016-07-18T17:37:10
> rccd160711.0030_s.fits 13.659 0.007 2016-07-18T17:37:11
>
> Current code:
> from astropy.table import Table, column
> tab = Table.read("sample.txt", names=("filename", "mag", "err", "time"),
> format="ascii")
>
> # Now replace the time column
> timecol = Column(name="time", data=Time(tab["time"]))
> tab.remove_column("time")
> tab.add_column(timecol)
>

Hi Varun,

It is *almost* possible to do this directly:

In [25]: from astropy.time import Time
In [26]: from astropy.io import ascii
In [27]: t = Table.read('sample.dat', format='ascii.no_header',
converters={'col4': [(Time, ascii.NoType)]})
In [28]: t
Out[28]:
<Table length=4>
         col1            col2    col3            col4
        str22          float64 float64          object
---------------------- ------- ------- -----------------------
rccd160711.0024_s.fits  13.113   0.005 2016-07-18T17:37:07.000
rccd160711.0025_s.fits  14.269   0.011 2016-07-18T17:37:12.000
rccd160711.0026_s.fits  14.203   0.011 2016-07-18T17:37:12.000
rccd160711.0027_s.fits  14.224    0.01 2016-07-18T17:37:12.000

In [29]: type(t['col4'])
Out[29]: astropy.time.core.Time

Unfortunately there is currently a limitation that one cannot rename mixin
columns such as the Time column.  That should be fixed.

But there is at least a quicker, more direct workaround:

tab = Table.read("sample.txt", names=("filename", "mag", "err", "time"),
format="ascii")
tab.replace_column('time', Time(tab['time']))

- Tom


>
>
> Thanks,
> -- Varun
> ____________________
> -  Varun Bhalerao  -
> Office: A 214, IUCAA
> Ph: +91 20 2560 4214
> www.iucaa.in/~varunb
>
> This email is encrypted and signed with OpenPGP.
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160817/04e5ae35/attachment.html>

From hessman at astro.physik.uni-goettingen.de  Thu Aug 18 02:44:49 2016
From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman)
Date: Thu, 18 Aug 2016 08:44:49 +0200
Subject: [AstroPy] AstroPy Digest, Vol 119, Issue 8
In-Reply-To: <mailman.87583.1471489660.2321.astropy@scipy.org>
References: <mailman.87583.1471489660.2321.astropy@scipy.org>
Message-ID: <8B7C5D43-A82F-4721-85B2-7480B9CE0A2A@astro.physik.uni-goettingen.de>

Thanks for all the suggestions!

From: Demitri Muna
> Not speaking as someone who wrote the software, but it wouldn't be an easy thing to do. The FITS format is extremely specific on a byte-to-byte basis, and trying to understand how a file is broken wouldn't be straightforward. I actually recommend such a program should not be part of astropy.io.fits but something standalone, but that's neither here nor there.

True, but in the real world one encounters this kind of problem, and astropy is for astronomers, not for computer scientists?

> Do you know what software wrote that file? I'd strongly argue that any FITS writer should not output invalid files in the first place. My guess is that it came from IDL, which as far as FITS writers go, is the wild west.

These were from CCDSoft, where one might have expected more checking, but English-speaking customers are unlikely to use umlauts, so ?.

From: Derek Homeier
> If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
> noted, make sure to replace each umlaut with two ASCII chars.

I?d forgotten vi -b, obviously the solution of choice for a small number of images!

In the meanwhile, I fixed things using my ImageJ FitsJ class and a few lines of java (ugh!).  Would have been nicer to catch an astropy.io.fits.LazyFITSProgrammer exception.

Rick

From xavier.gnata at gmail.com  Thu Aug 18 18:18:45 2016
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Fri, 19 Aug 2016 00:18:45 +0200
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
Message-ID: <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>


>
> On Aug 17, 2016, at 10:50 AM, Derek Homeier <derek at astro.physik.uni-goettingen.de> wrote:
>
>> If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
>> noted, make sure to replace each umlaut with two ASCII chars.
>
> Nice tip! If you resize your terminal window to display 80 characters in width it will be pretty obvious what kind of padding is needed.
>
> Demitri


I faced the same issue some months ago and I fixed it with a small 
python *script*. I found it already pretty disgusting.
Using an editor to fix our data is against most of the best practices 
when it comes to data handling.
fitsio with pyhon3 is *broken*. It use to be ok with python2.7.
Ok, these files are not following the standard. However, io.fits was 
able to open them without a warning with python2.7. That's bad but 
that's to late to change that. A fair amount of data has been produced 
that way. We need to be able to read then again with up to date means.
It does work anymore with python3 (8 years after the first python3 
release). That's not what one can expect from an io lib and from such a 
widely used scientific data format.
I hope it will  be fixed asap.

Xavier


From parejkoj at uw.edu  Thu Aug 18 18:46:47 2016
From: parejkoj at uw.edu (John K. Parejko)
Date: Thu, 18 Aug 2016 15:46:47 -0700
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
Message-ID: <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>

We should not expect our FITS readers to behave correctly when given invalid files. The fact that those files were handled ok in astropy under python2.7 was due entirely to luck. Yes, there are many badly formatted FITS files out in the wild, but that's not the fault of astropy.io.fits.

John

On 18Aug 2016, at 15:18, Xavier Gnata <xavier.gnata at gmail.com> wrote:

>> On Aug 17, 2016, at 10:50 AM, Derek Homeier <derek at astro.physik.uni-goettingen.de> wrote:
>> 
>>> If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
>>> noted, make sure to replace each umlaut with two ASCII chars.
>> 
>> Nice tip! If you resize your terminal window to display 80 characters in width it will be pretty obvious what kind of padding is needed.
>> 
>> Demitri
> 
> 
> I faced the same issue some months ago and I fixed it with a small python *script*. I found it already pretty disgusting.
> Using an editor to fix our data is against most of the best practices when it comes to data handling.
> fitsio with pyhon3 is *broken*. It use to be ok with python2.7.
> Ok, these files are not following the standard. However, io.fits was able to open them without a warning with python2.7. That's bad but that's to late to change that. A fair amount of data has been produced that way. We need to be able to read then again with up to date means.
> It does work anymore with python3 (8 years after the first python3 release). That's not what one can expect from an io lib and from such a widely used scientific data format.
> I hope it will  be fixed asap.
> 
> Xavier
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

--
*************************
John Parejko
parejkoj at uw.edu
http://staff.washington.edu/parejkoj/
Department of Physics and Astronomy
University of Washington
Seattle, WA
**************************













From rowen at uw.edu  Thu Aug 18 18:53:46 2016
From: rowen at uw.edu (Russell Owen)
Date: Thu, 18 Aug 2016 15:53:46 -0700
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
 <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
Message-ID: <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>

I will push back gently on this. Where practical it is best to be liberal in what you read, though of course the code should always write correct files.

? Russell

> On Aug 18, 2016, at 3:46 PM, John K. Parejko <parejkoj at uw.edu> wrote:
> 
> We should not expect our FITS readers to behave correctly when given invalid files. The fact that those files were handled ok in astropy under python2.7 was due entirely to luck. Yes, there are many badly formatted FITS files out in the wild, but that's not the fault of astropy.io.fits.
> 
> John
> 
> On 18Aug 2016, at 15:18, Xavier Gnata <xavier.gnata at gmail.com> wrote:
> 
>>> On Aug 17, 2016, at 10:50 AM, Derek Homeier <derek at astro.physik.uni-goettingen.de> wrote:
>>> 
>>>> If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
>>>> noted, make sure to replace each umlaut with two ASCII chars.
>>> 
>>> Nice tip! If you resize your terminal window to display 80 characters in width it will be pretty obvious what kind of padding is needed.
>>> 
>>> Demitri
>> 
>> 
>> I faced the same issue some months ago and I fixed it with a small python *script*. I found it already pretty disgusting.
>> Using an editor to fix our data is against most of the best practices when it comes to data handling.
>> fitsio with pyhon3 is *broken*. It use to be ok with python2.7.
>> Ok, these files are not following the standard. However, io.fits was able to open them without a warning with python2.7. That's bad but that's to late to change that. A fair amount of data has been produced that way. We need to be able to read then again with up to date means.
>> It does work anymore with python3 (8 years after the first python3 release). That's not what one can expect from an io lib and from such a widely used scientific data format.
>> I hope it will  be fixed asap.
>> 
>> Xavier
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From derek at astro.physik.uni-goettingen.de  Thu Aug 18 19:44:44 2016
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Fri, 19 Aug 2016 01:44:44 +0200
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
 <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
 <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
Message-ID: <41C915B1-5F20-4BE2-9E35-7DAF76E03EB3@astro.physik.uni-goettingen.de>

On 19 Aug 2016, at 12:53 am, Russell Owen <rowen at uw.edu> wrote:
> 
> I will push back gently on this. Where practical it is best to be liberal in what you read, though of course the code should always write correct files.
> 
> ? Russell
> 
>> On Aug 18, 2016, at 3:46 PM, John K. Parejko <parejkoj at uw.edu> wrote:
>> 
>> We should not expect our FITS readers to behave correctly when given invalid files. The fact that those files were handled ok in astropy under python2.7 was due entirely to luck. Yes, there are many badly formatted FITS files out in the wild, but that's not the fault of astropy.io.fits.
>> 
And that could be bad luck as well, as the issue I referenced earlier shows:
https://github.com/astropy/astropy/issues/5093

This was not in fact a problem of non-ASCII characters in the header as such,
but of an illegal (2080 bytes) header length, resulting in the first 800 data bytes
being read in as padding. Not surprisingly, those contain a fair share of non-ASCII
bytes, but in Python2.7 they would be silently accepted, resulting in a corrupt data
HDU read in.

My 2d,
					Derek




From hodge at stsci.edu  Fri Aug 19 09:49:27 2016
From: hodge at stsci.edu (Phil Hodge)
Date: Fri, 19 Aug 2016 09:49:27 -0400
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <41C915B1-5F20-4BE2-9E35-7DAF76E03EB3@astro.physik.uni-goettingen.de>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
 <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
 <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
 <41C915B1-5F20-4BE2-9E35-7DAF76E03EB3@astro.physik.uni-goettingen.de>
Message-ID: <12df8639-9cf7-3ac3-95d3-35e9177c5e5f@stsci.edu>

On 08/18/2016 07:44 PM, Derek Homeier wrote:
> This was not in fact a problem of non-ASCII characters in the header as such,
> but of an illegal (2080 bytes) header length, resulting in the first 800 data bytes
> being read in as padding. Not surprisingly, those contain a fair share of non-ASCII
> bytes, but in Python2.7 they would be silently accepted, resulting in a corrupt data
> HDU read in.

That's interesting.  I wonder if the author of CCDSoft just misread the 
FITS block size to be 2080 instead of 2880.  If so, the binary portion 
might also be padded to an incorrect length. One check would be to see 
whether the file size is divisible by 2080 instead of 2880.

Phil


From stsci.perry at gmail.com  Fri Aug 19 09:57:53 2016
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Fri, 19 Aug 2016 09:57:53 -0400
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
 <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
 <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
Message-ID: <8DE6FB75-FBF4-4719-B30F-526B46F4212A@gmail.com>

I?d say that depends. If it was long standing practice, yes I agree (e.g., institution X has produced broken FITS files for the last 10 years and now there are a bazillion of them). On the other hand, as a community we have really caused ourself a lot of pain by allowing this sort of thing to go on. So if these are new files, I?d go to the source and say you are producing broken files, fix them! 

Sure, you can be liberal in what you accept, but that liberality comes a quite an expensive cost in supporting the format since now you have many poorly documented variants, each requiring special code to handle and each causing maintainers in the future to curse us for allowing this crap.

Perry

On Aug 18, 2016, at 6:53 PM, Russell Owen <rowen at uw.edu> wrote:

> I will push back gently on this. Where practical it is best to be liberal in what you read, though of course the code should always write correct files.
> 
> ? Russell
> 
>> On Aug 18, 2016, at 3:46 PM, John K. Parejko <parejkoj at uw.edu> wrote:
>> 
>> We should not expect our FITS readers to behave correctly when given invalid files. The fact that those files were handled ok in astropy under python2.7 was due entirely to luck. Yes, there are many badly formatted FITS files out in the wild, but that's not the fault of astropy.io.fits.
>> 
>> John
>> 
>> On 18Aug 2016, at 15:18, Xavier Gnata <xavier.gnata at gmail.com> wrote:
>> 
>>>> On Aug 17, 2016, at 10:50 AM, Derek Homeier <derek at astro.physik.uni-goettingen.de> wrote:
>>>> 
>>>>> If it is not a large number of files, you might simply edit the headers with ?vi -b? and, as Demitri
>>>>> noted, make sure to replace each umlaut with two ASCII chars.
>>>> 
>>>> Nice tip! If you resize your terminal window to display 80 characters in width it will be pretty obvious what kind of padding is needed.
>>>> 
>>>> Demitri
>>> 
>>> 
>>> I faced the same issue some months ago and I fixed it with a small python *script*. I found it already pretty disgusting.
>>> Using an editor to fix our data is against most of the best practices when it comes to data handling.
>>> fitsio with pyhon3 is *broken*. It use to be ok with python2.7.
>>> Ok, these files are not following the standard. However, io.fits was able to open them without a warning with python2.7. That's bad but that's to late to change that. A fair amount of data has been produced that way. We need to be able to read then again with up to date means.
>>> It does work anymore with python3 (8 years after the first python3 release). That's not what one can expect from an io lib and from such a widely used scientific data format.
>>> I hope it will  be fixed asap.
>>> 
>>> Xavier
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> --
>> *************************
>> John Parejko
>> parejkoj at uw.edu
>> http://staff.washington.edu/parejkoj/
>> Department of Physics and Astronomy
>> University of Washington
>> Seattle, WA
>> **************************
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From npkuin at gmail.com  Fri Aug 19 13:01:32 2016
From: npkuin at gmail.com (Paul Kuin)
Date: Fri, 19 Aug 2016 18:01:32 +0100
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <8DE6FB75-FBF4-4719-B30F-526B46F4212A@gmail.com>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
 <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
 <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
 <8DE6FB75-FBF4-4719-B30F-526B46F4212A@gmail.com>
Message-ID: <CANoQ6N0W_jdmxaXgs_b=hCHkWvKmhi3-k8vQwyfKpEvw537pBg@mail.gmail.com>

It seems to me that the header should stick to the standard as the metadata
is a key thing for describing the data. Anyone who wants to do a header in
an extended character set should add that as a separate extension below the
main header.

On Fri, Aug 19, 2016 at 2:57 PM, Perry Greenfield <stsci.perry at gmail.com>
wrote:

> I?d say that depends. If it was long standing practice, yes I agree (e.g.,
> institution X has produced broken FITS files for the last 10 years and now
> there are a bazillion of them). On the other hand, as a community we have
> really caused ourself a lot of pain by allowing this sort of thing to go
> on. So if these are new files, I?d go to the source and say you are
> producing broken files, fix them!
>
> Sure, you can be liberal in what you accept, but that liberality comes a
> quite an expensive cost in supporting the format since now you have many
> poorly documented variants, each requiring special code to handle and each
> causing maintainers in the future to curse us for allowing this crap.
>
> Perry
>
> On Aug 18, 2016, at 6:53 PM, Russell Owen <rowen at uw.edu> wrote:
>
> > I will push back gently on this. Where practical it is best to be
> liberal in what you read, though of course the code should always write
> correct files.
> >
> > ? Russell
> >
> >> On Aug 18, 2016, at 3:46 PM, John K. Parejko <parejkoj at uw.edu> wrote:
> >>
> >> We should not expect our FITS readers to behave correctly when given
> invalid files. The fact that those files were handled ok in astropy under
> python2.7 was due entirely to luck. Yes, there are many badly formatted
> FITS files out in the wild, but that's not the fault of astropy.io.fits.
> >>
> >> John
> >>
> >> On 18Aug 2016, at 15:18, Xavier Gnata <xavier.gnata at gmail.com> wrote:
> >>
> >>>> On Aug 17, 2016, at 10:50 AM, Derek Homeier <derek at astro.physik.uni-
> goettingen.de> wrote:
> >>>>
> >>>>> If it is not a large number of files, you might simply edit the
> headers with ?vi -b? and, as Demitri
> >>>>> noted, make sure to replace each umlaut with two ASCII chars.
> >>>>
> >>>> Nice tip! If you resize your terminal window to display 80 characters
> in width it will be pretty obvious what kind of padding is needed.
> >>>>
> >>>> Demitri
> >>>
> >>>
> >>> I faced the same issue some months ago and I fixed it with a small
> python *script*. I found it already pretty disgusting.
> >>> Using an editor to fix our data is against most of the best practices
> when it comes to data handling.
> >>> fitsio with pyhon3 is *broken*. It use to be ok with python2.7.
> >>> Ok, these files are not following the standard. However, io.fits was
> able to open them without a warning with python2.7. That's bad but that's
> to late to change that. A fair amount of data has been produced that way.
> We need to be able to read then again with up to date means.
> >>> It does work anymore with python3 (8 years after the first python3
> release). That's not what one can expect from an io lib and from such a
> widely used scientific data format.
> >>> I hope it will  be fixed asap.
> >>>
> >>> Xavier
> >>> _______________________________________________
> >>> AstroPy mailing list
> >>> AstroPy at scipy.org
> >>> https://mail.scipy.org/mailman/listinfo/astropy
> >>
> >> --
> >> *************************
> >> John Parejko
> >> parejkoj at uw.edu
> >> http://staff.washington.edu/parejkoj/
> >> Department of Physics and Astronomy
> >> University of Washington
> >> Seattle, WA
> >> **************************
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/astropy
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204111 (work)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160819/73abdf22/attachment.html>

From xavier.gnata at gmail.com  Fri Aug 19 15:58:48 2016
From: xavier.gnata at gmail.com (Xavier Gnata)
Date: Fri, 19 Aug 2016 21:58:48 +0200
Subject: [AstroPy] Fixing broken FITS headers
In-Reply-To: <12df8639-9cf7-3ac3-95d3-35e9177c5e5f@stsci.edu>
References: <826DD77E-90B3-4894-A4B2-B868B45FACAE@astro.physik.uni-goettingen.de>
 <A303F159-D192-439A-AB77-108CF1336B2F@gmail.com>
 <9BB41357-412B-4E21-B51C-7CAF1151B729@astro.physik.uni-goettingen.de>
 <6323B54E-A722-465C-A3D0-AE899AFE0148@gmail.com>
 <b18160d5-4bf6-f20e-90e0-06cc981b7368@gmail.com>
 <4C6D6F06-9CDC-442B-8A01-6574B8975B72@uw.edu>
 <4511E8B4-0574-4B66-94FB-F3D0BCAC8E84@uw.edu>
 <41C915B1-5F20-4BE2-9E35-7DAF76E03EB3@astro.physik.uni-goettingen.de>
 <12df8639-9cf7-3ac3-95d3-35e9177c5e5f@stsci.edu>
Message-ID: <dac3481d-09d5-b3b9-ba36-eb7961fa6a66@gmail.com>

OK if the header is too short then the file is invalid. No question 
about that. I was reacting to "with headers where non-ascii characters 
have been used (German umlauts)." : this should be a non issue and we 
should be able to *open* this file (assuming the header size is ok). It 
is the case with python2.7. Getting 2 garbages chars (or whatever else) 
instead of one utf8 is a non issue as long as one can access the data.

Xavier


On 19/08/2016 15:49, Phil Hodge wrote:
> On 08/18/2016 07:44 PM, Derek Homeier wrote:
>> This was not in fact a problem of non-ASCII characters in the header
>> as such,
>> but of an illegal (2080 bytes) header length, resulting in the first
>> 800 data bytes
>> being read in as padding. Not surprisingly, those contain a fair share
>> of non-ASCII
>> bytes, but in Python2.7 they would be silently accepted, resulting in
>> a corrupt data
>> HDU read in.
>
> That's interesting.  I wonder if the author of CCDSoft just misread the
> FITS block size to be 2080 instead of 2880.  If so, the binary portion
> might also be padded to an incorrect length. One check would be to see
> whether the file size is divisible by 2080 instead of 2880.
>
> Phil
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From javed302 at gmail.com  Tue Aug 23 07:14:19 2016
From: javed302 at gmail.com (Javed Rana)
Date: Tue, 23 Aug 2016 11:14:19 +0000
Subject: [AstroPy] Setting and rising of a fixed object in the sky
Message-ID: <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=Qh0f+MYkVQ5OA2XA@mail.gmail.com>

Hello,
Is there any module in astropy that can calculate setting or rising time of
a fixed object on the sky?
Recently I have written a code to calculate the rising and setting time for
any fixed object on the sky using other astropy modules. It might be useful
for others. Is it possible to push it in astorpy?

Thanks in advance,
Javed Rana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160823/6e988f69/attachment.html>

From adrianmpw at gmail.com  Tue Aug 23 09:22:09 2016
From: adrianmpw at gmail.com (Adrian Price-Whelan)
Date: Tue, 23 Aug 2016 09:22:09 -0400
Subject: [AstroPy] Setting and rising of a fixed object in the sky
In-Reply-To: <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=Qh0f+MYkVQ5OA2XA@mail.gmail.com>
References: <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=Qh0f+MYkVQ5OA2XA@mail.gmail.com>
Message-ID: <CAEUL7mFLDuvz=hOR4YV5yajYc6wS-AZMvH0dSs5Fhm0_KPW2sw@mail.gmail.com>

Hi Javed --

Take a look at Astroplan (https://astroplan.readthedocs.org) and in
particular this tutorial:
https://astroplan.readthedocs.io/en/latest/tutorials/summer_triangle.html#observable

If you find that there is any functionality missing or if there are
features you implemented in your own code that you don't see here,
start up a discussion in the GitHub issues:
https://github.com/astropy/astroplan/issues

We'd love to hear any feedback you may have!

Thanks,
Adrian

On Tue, Aug 23, 2016 at 7:14 AM, Javed Rana <javed302 at gmail.com> wrote:
> Hello,
> Is there any module in astropy that can calculate setting or rising time of
> a fixed object on the sky?
> Recently I have written a code to calculate the rising and setting time for
> any fixed object on the sky using other astropy modules. It might be useful
> for others. Is it possible to push it in astorpy?
>
> Thanks in advance,
> Javed Rana
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



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


From bjw at as.arizona.edu  Tue Aug 23 11:19:10 2016
From: bjw at as.arizona.edu (Benjamin Weiner)
Date: Tue, 23 Aug 2016 17:19:10 +0200
Subject: [AstroPy] Setting and rising of a fixed object in the sky
Message-ID: <CAAKCKFGw-oQ1=-qogzMQevqoiSrvW5g0=TD74--0UP3b7oLtuQ@mail.gmail.com>

?Hi Javed and Adrian,

Pyephem, http://rhodesmill.org/pyephem/
is a fairly mature and widely used package for celestial computations with
a lot of functionality, including rise and set for both fixed and moving
objects (and much more).?

?I gather that astroplan is intended to be more closely integrated with
astropy, but it would be helpful to address in the astroplan docs ?what its
intended scope is and to what degree it will be compatible with (or
supplant) existing code.

Ben



>
> Message: 1
> Date: Tue, 23 Aug 2016 11:14:19 +0000
> From: Javed Rana <javed302 at gmail.com>
> To: "astropy at scipy.org" <astropy at scipy.org>
> Subject: [AstroPy] Setting and rising of a fixed object in the sky
> Message-ID:
>         <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=Qh0f+MYkVQ5OA2XA@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
> Is there any module in astropy that can calculate setting or rising time of
> a fixed object on the sky?
> Recently I have written a code to calculate the rising and setting time for
> any fixed object on the sky using other astropy modules. It might be useful
> for others. Is it possible to push it in astorpy?
>
> Thanks in advance,
> Javed Rana
>

-- 
Benjamin Weiner
Associate Astronomer, Steward Observatory
bjw at as.arizona.edu
http://mingus.as.arizona.edu/~bjw/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160823/cd786101/attachment.html>

From javed302 at gmail.com  Tue Aug 23 12:38:23 2016
From: javed302 at gmail.com (Javed Rana)
Date: Tue, 23 Aug 2016 16:38:23 +0000
Subject: [AstroPy] Setting and rising of a fixed object in the sky
In-Reply-To: <CAAKCKFGw-oQ1=-qogzMQevqoiSrvW5g0=TD74--0UP3b7oLtuQ@mail.gmail.com>
References: <CAAKCKFGw-oQ1=-qogzMQevqoiSrvW5g0=TD74--0UP3b7oLtuQ@mail.gmail.com>
Message-ID: <CAPSMbOgYnjXk8WKSSp03OE4kEJOvNRCE+0kn9kiinxMmJcFatg@mail.gmail.com>

Hi Adrian and Benjamin,
Thanks a lot. I have used the Astroplan and Pyephem both to calculate
setting time for an fixed object. Setting and rising computation in
Astroplan is little slow for very large number of fixed objects. Pyephem
does it fast, but for now I am not using ephem because there is another
module with the name as ephem. So what could be the better way?

Thanks in advance,
Javed Rana

On Tue, Aug 23, 2016 at 8:49 PM Benjamin Weiner <bjw at as.arizona.edu> wrote:

> ?Hi Javed and Adrian,
>
> Pyephem, http://rhodesmill.org/pyephem/
> is a fairly mature and widely used package for celestial computations with
> a lot of functionality, including rise and set for both fixed and moving
> objects (and much more).?
>
> ?I gather that astroplan is intended to be more closely integrated with
> astropy, but it would be helpful to address in the astroplan docs ?what its
> intended scope is and to what degree it will be compatible with (or
> supplant) existing code.
>
> Ben
>
>
>
>>
>> Message: 1
>> Date: Tue, 23 Aug 2016 11:14:19 +0000
>> From: Javed Rana <javed302 at gmail.com>
>> To: "astropy at scipy.org" <astropy at scipy.org>
>> Subject: [AstroPy] Setting and rising of a fixed object in the sky
>> Message-ID:
>>         <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=
>> Qh0f+MYkVQ5OA2XA at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>
>
>>
>> Hello,
>> Is there any module in astropy that can calculate setting or rising time
>> of
>> a fixed object on the sky?
>> Recently I have written a code to calculate the rising and setting time
>> for
>> any fixed object on the sky using other astropy modules. It might be
>> useful
>> for others. Is it possible to push it in astorpy?
>>
>> Thanks in advance,
>> Javed Rana
>>
>
> --
> Benjamin Weiner
> Associate Astronomer, Steward Observatory
> bjw at as.arizona.edu
> http://mingus.as.arizona.edu/~bjw/
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160823/6da73a0b/attachment.html>

From thomas.robitaille at gmail.com  Tue Aug 23 12:51:32 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 23 Aug 2016 17:51:32 +0100
Subject: [AstroPy] Setting and rising of a fixed object in the sky
In-Reply-To: <CAPSMbOgYnjXk8WKSSp03OE4kEJOvNRCE+0kn9kiinxMmJcFatg@mail.gmail.com>
References: <CAAKCKFGw-oQ1=-qogzMQevqoiSrvW5g0=TD74--0UP3b7oLtuQ@mail.gmail.com>
 <CAPSMbOgYnjXk8WKSSp03OE4kEJOvNRCE+0kn9kiinxMmJcFatg@mail.gmail.com>
Message-ID: <CAGMHX_3L3j=y15OHQoTHBgoBPBt7Kk6AfaWNmQVtgw-QLPd2qw@mail.gmail.com>

Hi Javed,

Could you show the code you have written to use Astroplan? There are
ways to set up Astropy coordinates that are more efficient than
others, so maybe we can make suggestions to make it run faster.

Cheers,
Tom


On 23 August 2016 at 17:38, Javed Rana <javed302 at gmail.com> wrote:
> Hi Adrian and Benjamin,
> Thanks a lot. I have used the Astroplan and Pyephem both to calculate
> setting time for an fixed object. Setting and rising computation in
> Astroplan is little slow for very large number of fixed objects. Pyephem
> does it fast, but for now I am not using ephem because there is another
> module with the name as ephem. So what could be the better way?
>
> Thanks in advance,
> Javed Rana
>
> On Tue, Aug 23, 2016 at 8:49 PM Benjamin Weiner <bjw at as.arizona.edu> wrote:
>>
>> Hi Javed and Adrian,
>>
>> Pyephem, http://rhodesmill.org/pyephem/
>> is a fairly mature and widely used package for celestial computations with
>> a lot of functionality, including rise and set for both fixed and moving
>> objects (and much more).
>>
>> I gather that astroplan is intended to be more closely integrated with
>> astropy, but it would be helpful to address in the astroplan docs what its
>> intended scope is and to what degree it will be compatible with (or
>> supplant) existing code.
>>
>> Ben
>>
>>
>>>
>>>
>>> Message: 1
>>> Date: Tue, 23 Aug 2016 11:14:19 +0000
>>> From: Javed Rana <javed302 at gmail.com>
>>> To: "astropy at scipy.org" <astropy at scipy.org>
>>> Subject: [AstroPy] Setting and rising of a fixed object in the sky
>>> Message-ID:
>>>
>>> <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=Qh0f+MYkVQ5OA2XA at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>>
>>>
>>> Hello,
>>> Is there any module in astropy that can calculate setting or rising time
>>> of
>>> a fixed object on the sky?
>>> Recently I have written a code to calculate the rising and setting time
>>> for
>>> any fixed object on the sky using other astropy modules. It might be
>>> useful
>>> for others. Is it possible to push it in astorpy?
>>>
>>> Thanks in advance,
>>> Javed Rana
>>
>>
>> --
>> Benjamin Weiner
>> Associate Astronomer, Steward Observatory
>> bjw at as.arizona.edu
>> http://mingus.as.arizona.edu/~bjw/
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From javed302 at gmail.com  Wed Aug 24 01:33:40 2016
From: javed302 at gmail.com (Javed Rana)
Date: Wed, 24 Aug 2016 05:33:40 +0000
Subject: [AstroPy] Setting and rising of a fixed object in the sky
In-Reply-To: <CAGMHX_3L3j=y15OHQoTHBgoBPBt7Kk6AfaWNmQVtgw-QLPd2qw@mail.gmail.com>
References: <CAAKCKFGw-oQ1=-qogzMQevqoiSrvW5g0=TD74--0UP3b7oLtuQ@mail.gmail.com>
 <CAPSMbOgYnjXk8WKSSp03OE4kEJOvNRCE+0kn9kiinxMmJcFatg@mail.gmail.com>
 <CAGMHX_3L3j=y15OHQoTHBgoBPBt7Kk6AfaWNmQVtgw-QLPd2qw@mail.gmail.com>
Message-ID: <CAPSMbOjeQBZUi6GG8DL=m56yUCRwT4dxBTWjbriD_d2BfA2U4w@mail.gmail.com>

Hi Tom,

The below code is where I am using astroplan-
Here it is setting and rising time computation for 400 objects. Please have
look on it and let me know if I can make it faster.


import numpy as np
import astropy.units as u
from astropy.time import Time
from astropy.coordinates import SkyCoord, EarthLocation
from astroplan import Observer

locate= EarthLocation(lat=19.*u.deg, lon=73.*u.deg)
observ = Observer(location=locate, name="IGO")
stars_ra= np.linspace(90., 160., 400)
stars_dec= np.linspace(-30., 30., 400)
stars_coord= SkyCoord(ra=stars_ra*u.deg, dec=stars_dec*u.deg)

stars_ris = [observ.target_rise_time(Time.now(), star_coord, 'next',
horizon=25.*u.deg) for star_coord in stars_coord]

stars_set= [observ.target_set_time(Time.now(), star_coord, 'next',
horizon=25.*u.deg) for star_coord in stars_coord]

Thanks in advance,
Javed



On Tue, Aug 23, 2016 at 10:21 PM Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Javed,
>
> Could you show the code you have written to use Astroplan? There are
> ways to set up Astropy coordinates that are more efficient than
> others, so maybe we can make suggestions to make it run faster.
>
> Cheers,
> Tom
>
>
> On 23 August 2016 at 17:38, Javed Rana <javed302 at gmail.com> wrote:
> > Hi Adrian and Benjamin,
> > Thanks a lot. I have used the Astroplan and Pyephem both to calculate
> > setting time for an fixed object. Setting and rising computation in
> > Astroplan is little slow for very large number of fixed objects. Pyephem
> > does it fast, but for now I am not using ephem because there is another
> > module with the name as ephem. So what could be the better way?
> >
> > Thanks in advance,
> > Javed Rana
> >
> > On Tue, Aug 23, 2016 at 8:49 PM Benjamin Weiner <bjw at as.arizona.edu>
> wrote:
> >>
> >> Hi Javed and Adrian,
> >>
> >> Pyephem, http://rhodesmill.org/pyephem/
> >> is a fairly mature and widely used package for celestial computations
> with
> >> a lot of functionality, including rise and set for both fixed and moving
> >> objects (and much more).
> >>
> >> I gather that astroplan is intended to be more closely integrated with
> >> astropy, but it would be helpful to address in the astroplan docs what
> its
> >> intended scope is and to what degree it will be compatible with (or
> >> supplant) existing code.
> >>
> >> Ben
> >>
> >>
> >>>
> >>>
> >>> Message: 1
> >>> Date: Tue, 23 Aug 2016 11:14:19 +0000
> >>> From: Javed Rana <javed302 at gmail.com>
> >>> To: "astropy at scipy.org" <astropy at scipy.org>
> >>> Subject: [AstroPy] Setting and rising of a fixed object in the sky
> >>> Message-ID:
> >>>
> >>> <CAPSMbOizR_ivn-Xhmsny_AoJqkRuWKUYu=Qh0f+MYkVQ5OA2XA at mail.gmail.com>
> >>> Content-Type: text/plain; charset="utf-8"
> >>>
> >>>
> >>>
> >>> Hello,
> >>> Is there any module in astropy that can calculate setting or rising
> time
> >>> of
> >>> a fixed object on the sky?
> >>> Recently I have written a code to calculate the rising and setting time
> >>> for
> >>> any fixed object on the sky using other astropy modules. It might be
> >>> useful
> >>> for others. Is it possible to push it in astorpy?
> >>>
> >>> Thanks in advance,
> >>> Javed Rana
> >>
> >>
> >> --
> >> Benjamin Weiner
> >> Associate Astronomer, Steward Observatory
> >> bjw at as.arizona.edu
> >> http://mingus.as.arizona.edu/~bjw/
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160824/ed51c656/attachment.html>

From renaud.miel at nao.ac.jp  Wed Aug 24 02:05:27 2016
From: renaud.miel at nao.ac.jp (Renaud Miel)
Date: Wed, 24 Aug 2016 15:05:27 +0900
Subject: [AstroPy] astropy test results: meaning of xpassed and xfailed
In-Reply-To: <6485d8f8-4eb4-c3a6-8d74-6d633a0ac4fc@nao.ac.jp>
References: <6485d8f8-4eb4-c3a6-8d74-6d633a0ac4fc@nao.ac.jp>
Message-ID: <a36fff1d-fa3b-e40a-4796-5b42ade6b8d5@nao.ac.jp>

Hi,

I have installed and tested astropy 1.1.2 on a RHEL6 machine (python 2.6.6).
Looking at the results shown below, some tests are reported as xpassed 
or xfailed.

Anyone knowing what it means ? Can these xpassed/xfailed results be 
safely ignored ?

test_astropy_package_analytic_functions.log  :===================== 4 passed, 1 skipped in 0.26 seconds ======================
test_astropy_package_config.log              :========================== 17 passed in 1.15 seconds ===========================
test_astropy_package_constants.log           :===================== 16 passed, 9 xfailed in 0.20 seconds =====================
test_astropy_package_convolution.log         :============== 722 passed, 24 skipped, 6 xfailed in 7.12 seconds ===============
test_astropy_package_coordinates.log         :============= 816 passed, 20 skipped, 14 xfailed in 44.18 seconds ==============
test_astropy_package_cosmology.log           :==================== 10 passed, 30 skipped in 0.73 seconds =====================
test_astropy_package__erfa.log               :=========================== 5 passed in 0.58 seconds ===========================
test_astropy_package_io.log                  :============= 1457 passed, 64 skipped, 6 xfailed in 52.95 seconds ==============
test_astropy_package_modeling.log            :=================== 386 passed, 137 skipped in 4.42 seconds ====================
test_astropy_package_nddata.log              :==================== 270 passed, 13 skipped in 1.38 seconds ====================
test_astropy_package_stats.log               :==================== 34 passed, 22 skipped in 2.92 seconds =====================
test_astropy_package_table.log               :============== 2125 passed, 8 skipped, 3 xfailed in 33.77 seconds ==============
test_astropy_package_tests.log               :================ 1 failed, 43 passed, 2 skipped in 0.98 seconds ================
test_astropy_package_time.log                :=============== 337 passed, 3 skipped, 1 xfailed in 3.98 seconds ===============
test_astropy_package_units.log               :============= 2711 passed, 17 skipped, 6 xfailed in 82.73 seconds ==============
test_astropy_package_utils.log               :============== 219 passed, 20 skipped, 2 xfailed in 5.78 seconds ===============
test_astropy_package_visualization.log       :==================== 123 passed, 17 skipped in 0.56 seconds ====================
test_astropy_package_wcs.log                 :==================== 345 passed, 2 xpassed in 6.73 seconds =====================

  * <http://alma-comp.mtk.nao.ac.jp:8080/jira/secure/AddComment%21default.jspa?id=15924>

Renaud Miel

renaud.miel at nao.ac.jp

Computing Team, Chile Observatory,
National Astronomical Observatory of Japan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160824/a3964017/attachment.html>

From renaud.miel at nao.ac.jp  Wed Aug 24 02:16:29 2016
From: renaud.miel at nao.ac.jp (Renaud Miel)
Date: Wed, 24 Aug 2016 15:16:29 +0900
Subject: [AstroPy] astropy 1.1.2 RHEL6 (python 2.6.6) test_imports.py :
 ImportError: cannot import name _erfa
Message-ID: <6438093f-bf91-3252-76d3-cecff5807af0@nao.ac.jp>

Hi,

Does anyone know if this failure can be safely ignored ?

astropy.test(package='tests')  fails importing _erfa in test_imports.py
but
astropy.test(package='_erfa') is successful (5 passed)

Thanks

-- 
Renaud Miel

renaud.miel at nao.ac.jp

Computing Team, Chile Observatory,
National Astronomical Observatory of Japan




Logfile:

============================= test session starts ==============================

platform linux2 -- Python 2.6.6 -- py-1.4.30 -- pytest-2.7.3
rootdir: /remote/home/renaud/sys_work/sys-175_astropy/results/python-2.6/customized_user_install/rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests, inifile:

Running tests with Astropy version 1.1.2.
Running tests in /remote/home/renaud/sys_work/sys-175_astropy/results/python-2.6/customized_user_install/rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests.

Date: 2016-08-24T13:19:30

Platform: Linux-2.6.32-431.29.2.el6.x86_64-x86_64-with-redhat-6.4-Santiago

Executable: /usr/bin/python

Full Python Version:
2.6.6 (r266:84292, Aug  9 2016, 06:11:56)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]

encodings: sys: ascii, locale: UTF-8, filesystem: UTF-8, unicode bits: 20
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.7.2
Scipy: not available
Matplotlib: not available
h5py: not available
Pandas: not available

collected 46 items

rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/test_logger.py .............................
rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_imports.py F.
rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_open_file_detection.py .
rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_quantity_helpers.py .
rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_run_tests.py ........
rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_skip_remote_data.py s
rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_socketblocker.py ...s

=================================== FAILURES ===================================
_________________________________ test_imports _________________________________

     def test_imports():
         """
         This just imports all modules in astropy, making sure they don't have any
         dependencies that sneak through
         """
     
         from ...utils import find_current_module
     
         pkgornm = find_current_module(1).__name__.split('.')[0]
     
         if isinstance(pkgornm, six.string_types):
             package = pkgutil.get_loader(pkgornm).load_module(pkgornm)
         elif (isinstance(pkgornm, types.ModuleType) and
                 '__init__' in pkgornm.__file__):
             package = pkgornm
         else:
             msg = 'test_imports is not determining a valid package/package name'
             raise TypeError(msg)
     
         if hasattr(package, '__path__'):
             pkgpath = package.__path__
         elif hasattr(package, '__file__'):
             pkgpath = os.path.split(package.__file__)[0]
         else:
             raise AttributeError('package to generate config items for does not '
                                  'have __file__ or __path__')
     
         if six.PY3:
             excludes = _py2_packages
         else:
             excludes = _py3_packages
     
         prefix = package.__name__ + '.'
     
         def onerror(name):
             if not any(name.startswith(excl) for excl in excludes):
                 # A legitimate error occurred in a module that wasn't excluded
                 raise
     
         for imper, nm, ispkg in pkgutil.walk_packages(pkgpath, prefix,
>                                                     onerror=onerror):

rhel6/python-2.6/lib/python2.6/site-packages/astropy/tests/tests/test_imports.py:67:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib64/python2.6/pkgutil.py:113: in walk_packages
     onerror(name)
/usr/lib64/python2.6/pkgutil.py:110: in walk_packages
     __import__(name)
rhel6/python-2.6/lib/python2.6/site-packages/astropy/convolution/__init__.py:6: in <module>
     from .core import *
rhel6/python-2.6/lib/python2.6/site-packages/astropy/convolution/core.py:25: in <module>
     from .utils import (discretize_model, add_kernel_arrays_1D,
rhel6/python-2.6/lib/python2.6/site-packages/astropy/convolution/utils.py:7: in <module>
     from ..modeling.core import FittableModel, custom_model
rhel6/python-2.6/lib/python2.6/site-packages/astropy/modeling/__init__.py:11: in <module>
     from . import models
rhel6/python-2.6/lib/python2.6/site-packages/astropy/modeling/models.py:10: in <module>
     from .core import custom_model
rhel6/python-2.6/lib/python2.6/site-packages/astropy/modeling/core.py:48: in <module>
     from ..nddata.utils import add_array, extract_array
rhel6/python-2.6/lib/python2.6/site-packages/astropy/nddata/__init__.py:23: in <module>
     from .utils import *
rhel6/python-2.6/lib/python2.6/site-packages/astropy/nddata/utils.py:11: in <module>
     from astropy.coordinates import SkyCoord
rhel6/python-2.6/lib/python2.6/site-packages/astropy/coordinates/__init__.py:13: in <module>
     from .baseframe import *
rhel6/python-2.6/lib/python2.6/site-packages/astropy/coordinates/baseframe.py:1181: in <module>
     from .earth import EarthLocation
rhel6/python-2.6/lib/python2.6/site-packages/astropy/coordinates/earth.py:11: in <module>
     from .builtin_frames import ITRS
rhel6/python-2.6/lib/python2.6/site-packages/astropy/coordinates/builtin_frames/__init__.py:44: in <module>
     from . import icrs_cirs_transforms
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

     """
     from __future__ import (absolute_import, unicode_literals, division,
                             print_function)
     
     import numpy as np
     
     from ... import units as u
     from ..baseframe import frame_transform_graph
     from ..transformations import FunctionTransform
     from ..representation import (SphericalRepresentation, CartesianRepresentation,
                                   UnitSphericalRepresentation)
>   from ... import _erfa as erfa
E   ImportError: cannot import name _erfa

rhel6/python-2.6/lib/python2.6/site-packages/astropy/coordinates/builtin_frames/icrs_cirs_transforms.py:17: ImportError
----------------------------- Captured stderr call -----------------------------
WARNING: AstropyDeprecationWarning: Python 2.6 will no longer be supported from Astropy v1.2.0 and above [astropy]
/remote/home/renaud/sys_work/sys-175_astropy/results/python-2.6/customized_user_install/rhel6/python-2.6/lib/python2.6/site-packages/astropy/analytic_functions/blackbody.py:30: RuntimeWarning: overflow encountered in expm1
   _has_buggy_expm1 = np.isnan(np.expm1(1000))
================ 1 failed, 43 passed, 2 skipped in 0.98 seconds ================





From hjyanghj at gmail.com  Thu Aug 25 01:18:58 2016
From: hjyanghj at gmail.com (Yang Hon-Jang)
Date: Thu, 25 Aug 2016 13:18:58 +0800
Subject: [AstroPy] Why get_body('earth',
	...).cartesian.x.value is not equal zero?
Message-ID: <CACVX7WQ6Le=XRXNHsn4TxRFs9NoBXjjMDns9_SwXK6MyZ+r-7A@mail.gmail.com>

Use
```
from astropy.time import Time
from astropy.coordinates import get_body
earth=get_body('earth',Time('2016-08-25'), ephemeris='jpl')
earth.cartesian
```
I got
```

<CartesianRepresentation (x, y, z) in km
    (2.85036473, -2.4131942, -0.63855691)>

```

My question:
Why not (x,y,z)==(0,0,0)?
Is it because center of mass of earth is not equal to shape center of
earth(center of ellipsoid) OR?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160825/4ad257e0/attachment.html>

From taozhi_yaoyao at 126.com  Fri Aug 26 21:49:14 2016
From: taozhi_yaoyao at 126.com (=?GBK?B?wfXDztH+?=)
Date: Sat, 27 Aug 2016 09:49:14 +0800 (CST)
Subject: [AstroPy] Plot figures in Gal with fits in J2000?
Message-ID: <608fe5e.105f.156c9afc39b.Coremail.taozhi_yaoyao@126.com>

Dear Aplpy gurus,


I always use aplpy.FITSFigure to plot figures for fits files. Is there a way to plot figures in the galactic coordinate with a fits file in J2000 while I can also use aplpy.FITSFigure? I know one can regrid the fits file and change the coordinate to Gal first. I just wonder if there is any simpler way?




Thanks,
Mengyao Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160827/81a60788/attachment.html>

From renaud.miel at nao.ac.jp  Mon Aug 29 02:32:54 2016
From: renaud.miel at nao.ac.jp (Renaud Miel)
Date: Mon, 29 Aug 2016 15:32:54 +0900
Subject: [AstroPy] astropy test results: meaning of xpassed and xfailed
In-Reply-To: <a36fff1d-fa3b-e40a-4796-5b42ade6b8d5@nao.ac.jp>
References: <6485d8f8-4eb4-c3a6-8d74-6d633a0ac4fc@nao.ac.jp>
 <a36fff1d-fa3b-e40a-4796-5b42ade6b8d5@nao.ac.jp>
Message-ID: <dede1fa8-0ab8-aa54-3e4e-24700230d1c0@nao.ac.jp>

Hi,

Ok, this is just pytest jargon.

xpassed: unexpectedly passing

xfailed: expected to fail

http://doc.pytest.org/en/latest/skipping.html


On 2016/08/24 15:05, Renaud Miel wrote:
> Hi,
>
> I have installed and tested astropy 1.1.2 on a RHEL6 machine (python 
> 2.6.6).
> Looking at the results shown below, some tests are reported as xpassed 
> or xfailed.
>
> Anyone knowing what it means ? Can these xpassed/xfailed results be 
> safely ignored ?
>
> test_astropy_package_analytic_functions.log  :===================== 4 passed, 1 skipped in 0.26 seconds ======================
> test_astropy_package_config.log              :========================== 17 passed in 1.15 seconds ===========================
> test_astropy_package_constants.log           :===================== 16 passed, 9 xfailed in 0.20 seconds =====================
> test_astropy_package_convolution.log         :============== 722 passed, 24 skipped, 6 xfailed in 7.12 seconds ===============
> test_astropy_package_coordinates.log         :============= 816 passed, 20 skipped, 14 xfailed in 44.18 seconds ==============
> test_astropy_package_cosmology.log           :==================== 10 passed, 30 skipped in 0.73 seconds =====================
> test_astropy_package__erfa.log               :=========================== 5 passed in 0.58 seconds ===========================
> test_astropy_package_io.log                  :============= 1457 passed, 64 skipped, 6 xfailed in 52.95 seconds ==============
> test_astropy_package_modeling.log            :=================== 386 passed, 137 skipped in 4.42 seconds ====================
> test_astropy_package_nddata.log              :==================== 270 passed, 13 skipped in 1.38 seconds ====================
> test_astropy_package_stats.log               :==================== 34 passed, 22 skipped in 2.92 seconds =====================
> test_astropy_package_table.log               :============== 2125 passed, 8 skipped, 3 xfailed in 33.77 seconds ==============
> test_astropy_package_tests.log               :================ 1 failed, 43 passed, 2 skipped in 0.98 seconds ================
> test_astropy_package_time.log                :=============== 337 passed, 3 skipped, 1 xfailed in 3.98 seconds ===============
> test_astropy_package_units.log               :============= 2711 passed, 17 skipped, 6 xfailed in 82.73 seconds ==============
> test_astropy_package_utils.log               :============== 219 passed, 20 skipped, 2 xfailed in 5.78 seconds ===============
> test_astropy_package_visualization.log       :==================== 123 passed, 17 skipped in 0.56 seconds ====================
> test_astropy_package_wcs.log                 :==================== 345 passed, 2 xpassed in 6.73 seconds =====================
>
>   * <http://alma-comp.mtk.nao.ac.jp:8080/jira/secure/AddComment%21default.jspa?id=15924>
>
> Renaud Miel
>
> renaud.miel at nao.ac.jp
>
> Computing Team, Chile Observatory,
> National Astronomical Observatory of Japan

-- 
???????
Renaud Miel

renaud.miel at nao.ac.jp

Computing Team, Chile Observatory,
National Astronomical Observatory of Japan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160829/d14b8e88/attachment.html>

From aldcroft at head.cfa.harvard.edu  Tue Aug 30 07:07:45 2016
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Tue, 30 Aug 2016 07:07:45 -0400
Subject: [AstroPy] Roles in the Astropy project
Message-ID: <CAMtEP6xbaaJX=RHUDbuuPECbs8LviHdXc3fFUMGMb-NXqSWkAg@mail.gmail.com>

Dear Astropy community member,
On behalf of the Astropy coordination committee I would like to draw your
attention to an initiative to explicitly define roles within the Astropy
project.  These roles encompass a broad scope of responsibilities ranging
from direct package development to communication, distribution, and
managerial activities.  We have created a new web page describing roles
which is available at the link below:
  http://www.astropy.org/team.html
The primary goal is to ensure sustainability of the project and to minimize
gaps in support.  Another driver is to formally and visibly acknowledge the
people performing these duties and to provide links to the detailed role
descriptions for outside reference.
IMPORTANT: If you have comments or questions about the existing roles, or
would like to volunteer for a role (whether or not unfilled), please
contact us at coordinators at astropy.org.
Best regards,
Tom AldcroftKelle CruzTom RobitailleErik Tollerud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160830/3222899c/attachment.html>

From dps.helio at gmail.com  Tue Aug 30 16:54:35 2016
From: dps.helio at gmail.com (DVD PS)
Date: Tue, 30 Aug 2016 21:54:35 +0100
Subject: [AstroPy] And Google Summer of Code has ended this year!!!
Message-ID: <CAD0QkqVZ0DCfo4Zcr45x8b0C07Y_WdK-m+aXhv6aewH8T+rA6A@mail.gmail.com>

This year has been an amazing one! This year was the first one in which
we've participated as an independent organisation covering many of the
astronomy open source efforts under the Open Astronomy umbrella
organisation.

http://openastronomy.org/members/

Under the Open Astronomy organisation we have been accepted by Google
directly, while in previous years the different organisations had
participated under the Python Software Foundation or NumFocus.  This is
great because it gives us a higher visibility for students and in the open
source communities, and in addition other important advantages: we get some
compensation from Google and two of us will represent the organisation in
the Google Summer of Code mentor summit happening at the end of October.

We got 8 slots from Google, of which 5 went to Astropy and 3 to SunPy.
Sadly the other sub-organisations (yt, chiantipy, juliaAstro, ...) didn't
get any qualified student applicants this time but surely it will change in
the future. From these 8 slots, 7 of them passed the mid-term and all the 7
passed the final evaluation. The students, their projects and the mentors
are the following:

For the Astropy project:

Micky Costa: Astropy: Bridge Sherpa and astropy fitting
<http://myopensauceadventure.blogspot.co.uk/2016/08/dessert.html> (Tom
Aldcroft, Omar Laurino, and Moritz Guenther)

Olga Vorokh: Image processing and source detection in Gammapy
<https://github.com/search?p=1&q=author%3AOlgaVorokh+created%3A%222016-02-10+..+2016-08-23%22&ref=searchresults&type=Issues&utf8=%E2%9C%93>
(Johannes King and Christoph Deil)

Z? Vin?cius: Implement PSF photometry for fitting several overlapping
objects at once <http://mirca.github.io/gsoc-astropy-final/> (Moritz
Guenter, Brigitta Sipocz, and Erik Tollerud)

Karl Vyhmeister: Scheduling capabilities for Astroplan
<http://kvyhastroplan.blogspot.com/2016/08/cleaning-up-and-documenting.html?>
(Brett Morris and Erik Tollerud)

For SunPy:

Tessa Wilkinson: Implementing AIA response function in Sunpy
<http://tdwilkinson.blogspot.co.uk/2016/08/aia-response-summary-this-is-my-final.html>
(Drew Leonard and Will Barnes)

Punyaslok Pattnaik: Improvements to the SunPy Database
<https://punyaslokpattnaik.wordpress.com/2016/08/22/its-already-time/>
(Stuart Mumford and Simon Liedtke)

Sudarshan Konge: Real Time Data Access and Visualisation tools
<https://sudonymousblog.wordpress.com/2016/08/19/gsoc-summary-post/> (David
Perez-Suarez and Jack Ireland)

You can still see all their trip that brought them till the end reading
their blogs, available at:

http://openastronomy.org/Universe_OA/

If you would like to give us suggestions on how to improve the program (to
us as an umbrella, or to Google itself) or you want to get more involved
either as a mentor or as a sub-organisation, do not hesitate to contact
us.  There's a lot that we can do better in the coming years!!

Thanks for all the summer!
David Perez-Suarez, Tom Aldcroft,  Erik Tollerud, Stuart Mumford
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160830/47b1522e/attachment.html>

From derek at astro.physik.uni-goettingen.de  Wed Aug 31 16:57:45 2016
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Wed, 31 Aug 2016 22:57:45 +0200
Subject: [AstroPy] PR 3655 (Fortran-style and large exponents in
	ascii.io)
In-Reply-To: <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de>
References: <2A662C22-9D61-4B73-B90F-C942A71C0EB1@astro.physik.uni-goettingen.de>
 <37B3CF6D-2455-4D31-B987-4A796B34981B@gmail.com>
 <35D16723-409F-40BE-90A6-61A3B8109994@astro.physik.uni-goettingen.de>
Message-ID: <14702044-8E25-423B-BD3B-770F43685CDF@astro.physik.uni-goettingen.de>

On 12 Jul 2016, at 2:54 am, Derek Homeier <derek at astro.physik.uni-goettingen.de> wrote:
> 
> On 12 Jul 2016, at 2:36 am, Evert Rol <evert.rol at gmail.com> wrote:
>> 
>> Probably not.
>> There is the astropy developer mailing list, which is separate to this mailing list(*), but if you've updated the PR, the astropy maintainers should get informed automatically.
>> Best I can advice, is to keep your PR up-to-date with the current master, verify all tests still pass on Github, and wait (or possibly ping people on GitHub through a comment).
>> The PR will need someone to review it, and a knowledgeable reviewer may not have found time yet to do that.
>> 
> Thanks, I had completely missed the -dev list as it is not on the Scipy archive!
> I commented on the changes made to pass all CI tests a few weeks ago, so I
> guess I?m just gonna give it a little more time.

As another follow-up to this story, just in case any of the developers are still following this list,
is it possible at all to sign up to astropy-dev as a normal mailing list?
The only way right now appears to be with ones Google+ account, which is a major pain at
this point as Google seems unable to restore access to my original account (which I haven?t
used in years to be fair), but at the same time refuses to link my preferred mail address to my
backup account, apparently because it is still linked to the lost original account?
Maybe I am too old-fashioned to join then, but a plain old mailing list that does not require a
specific provider would still seem a helpful instrument.

Cheers,
					Derek