From jo.bovy at gmail.com  Wed Jul  1 11:40:06 2015
From: jo.bovy at gmail.com (Jo Bovy)
Date: Wed, 1 Jul 2015 11:40:06 -0400
Subject: [AstroPy] ANN: galpy v1.1 released
Message-ID: <CALeWRE5z-eHtgEVBEuYvzpOBLUytmVbxDvYtQxCMrQmq1Xb3Hg@mail.gmail.com>

Dear colleagues,

I am happy to announce release v1.1 of galpy, a python package for galactic
and MW dynamics. You are receiving this email because I believe this may be
of interest to you. Documentation (including detailed installation
instructions) can be found here: http://galpy.readthedocs.org/en/latest/.
The code is available on github (http://github.com/jobovy/galpy) and can be
installed from there or using pip.

Version 1.1 contains all development since the version 1.0 release last
December. A full list of changes can be found here: http://bit.ly/1HuIsTb;
some of the major improvements are:

- Full Python 3 support;

- The ability to ingest a N-body snapshot, build an axisymmetric
approximation to its potential, and then use that potential like any galpy
potential (e.g., to calculate orbits and actions). Mostly added by Rok
Roskar;

- Support for converting galpy potentials to NEMO potentials, including a
full implementation of galpy's default MW potential for use in NEMO.

- Various new potentials: a disk-like Staeckel potential (Kuzmin-Kutuzov;
added by Wilma Trick), the Plummer potential, and a
3-Miyamoto-Nagai-potential approximation to an exponential disk.


Please report issues by reporting them on github (the preferred method)

http://github.com/jobovy/galpy/issues

or by emailing me. Please let me know if you are using the code so I can
keep you informed of any major updates.

Thanks,

Jo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150701/9b7de2e7/attachment.html>

From stsci.perry at gmail.com  Wed Jul  1 13:44:58 2015
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Wed, 1 Jul 2015 13:44:58 -0400
Subject: [AstroPy] sprint for astropy at scipy?
In-Reply-To: <55928D83.7070106@stsci.edu>
References: <99A9B149-013C-461E-AB6B-74878EA7CF9E@gmail.com>
	<55928D83.7070106@stsci.edu>
Message-ID: <C5CF1F37-B316-4B49-A725-D1131952E5B7@gmail.com>

The number of people that will be present seems marginal. I?d suggest that those that are interested meet Saturday morning in the sprint area and see what is of interest to work on. I haven?t submitted an official sprint topic though.

Perry



On Jun 30, 2015, at 8:37 AM, Howard Bushouse <bushouse at stsci.edu> wrote:

> No, I'll be leaving town Saturday morning.
> 
> -Howard
> 
> On 06/29/2015 12:50 PM, Perry Greenfield wrote:
>> Who plans to be around for part or all of the sprints? I?ll be there Saturday.
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From josevinicius at iecom.org.br  Sun Jul  5 11:42:35 2015
From: josevinicius at iecom.org.br (=?UTF-8?B?Sm9zw6kgVmluw61jaXVz?=)
Date: Sun, 5 Jul 2015 11:42:35 -0400
Subject: [AstroPy] errors returned by astropy.test()
Message-ID: <CAA9_Gr=r3Xon9oeE265didbzCW_=GHFARUR9sZ0DNXSyTUd6Zw@mail.gmail.com>

Hi guys!

I'm trying to install the developer's version of astropy, and after using
>> import astropy
>> astropy.test()
I'm receiving several errors: *= 9 failed, 9053 passed, 170 skipped, 43
xfailed, 2 xpassed in 284.03 seconds == *1

The log of failures is as follows

=================================== FAILURES
===================================

_______________________ test_getitem_metadata_regression
_______________________


*    def test_getitem_metadata_regression():*

*        """*

*        Regression test for #1471: MaskedArray does not call
__array_finalize__ so*

*        the meta-data was not getting copied over. By overloading
_update_from we*

*        are able to work around this bug.*

*        """*



*        # Make sure that meta-data gets propagated with __getitem__*



*        c = table.Column(data=[1,2], name='a', description='b', unit='m',
format="%i", meta={'c': 8})*

*        assert c[1:2].name == 'a'*

*        assert c[1:2].description == 'b'*

*        assert c[1:2].unit == 'm'*

*        assert c[1:2].format == '%i'*

*        assert c[1:2].meta['c'] == 8*



*        c = table.MaskedColumn(data=[1,2], name='a', description='b',
unit='m', format="%i", meta={'c': 8})*

*        assert c[1:2].name == 'a'*

*        assert c[1:2].description == 'b'*

*        assert c[1:2].unit == 'm'*

*        assert c[1:2].format == '%i'*

*        assert c[1:2].meta['c'] == 8*



*        # As above, but with take() - check the method and the function*



*        c = table.Column(data=[1,2,3], name='a', description='b',
unit='m', format="%i", meta={'c': 8})*

*        for subset in [c.take([0, 1]), np.take(c, [0, 1])]:*

*            assert subset.name <http://subset.name> == 'a'*

*            assert subset.description == 'b'*

*            assert subset.unit == 'm'*

*            assert subset.format == '%i'*

*            assert subset.meta['c'] == 8*



*        # Metadata isn't copied for scalar values*

*        if NUMPY_LT_1_8:*

*            with pytest.raises(ValueError):*

*>               c.take(0)*

*E               Failed: DID NOT RAISE*


astropy/table/tests/test_column.py:467: Failed

_______________________ test_getitem_metadata_regression
_______________________


*    def test_getitem_metadata_regression():*

*        """*

*        Regression test for #1471: MaskedArray does not call
__array_finalize__ so*

*        the meta-data was not getting copied over. By overloading
_update_from we*

*        are able to work around this bug.*

*        """*



*        # Make sure that meta-data gets propagated with __getitem__*



*        c = table.Column(data=[1,2], name='a', description='b', unit='m',
format="%i", meta={'c': 8})*

*        assert c[1:2].name == 'a'*

*        assert c[1:2].description == 'b'*

*        assert c[1:2].unit == 'm'*

*        assert c[1:2].format == '%i'*

*        assert c[1:2].meta['c'] == 8*



*        c = table.MaskedColumn(data=[1,2], name='a', description='b',
unit='m', format="%i", meta={'c': 8})*

*        assert c[1:2].name == 'a'*

*        assert c[1:2].description == 'b'*

*        assert c[1:2].unit == 'm'*

*        assert c[1:2].format == '%i'*

*        assert c[1:2].meta['c'] == 8*



*        # As above, but with take() - check the method and the function*



*        c = table.Column(data=[1,2,3], name='a', description='b',
unit='m', format="%i", meta={'c': 8})*

*        for subset in [c.take([0, 1]), np.take(c, [0, 1])]:*

*            assert subset.name <http://subset.name> == 'a'*

*            assert subset.description == 'b'*

*            assert subset.unit == 'm'*

*            assert subset.format == '%i'*

*            assert subset.meta['c'] == 8*



*        # Metadata isn't copied for scalar values*

*        if NUMPY_LT_1_8:*

*            with pytest.raises(ValueError):*

*>               c.take(0)*

*E               Failed: DID NOT RAISE*


astropy/table/tests/test_column.py:467: Failed

_______________________ test_masked_row_with_object_col
________________________


*    def test_masked_row_with_object_col():*

*        """*

*        Numpy < 1.8 has a bug in masked array that prevents access a row
if there is*

*        a column with object type.*

*        """*

*        t = table.Table([[1]], dtype=['O'], masked=True)*

*        if NUMPY_LT_1_8:*

*            with pytest.raises(ValueError):*

*                t['col0'].mask = False*

*>               t[0].as_void()*

*E               Failed: DID NOT RAISE*


astropy/table/tests/test_row.py:26: Failed

______________ TestRow.test_row_and_as_void_with_objects[masked]
_______________


self = <astropy.table.tests.test_row.TestRow instance at 0x108ed2ab8>

table_types = <astropy.table.tests.conftest.TableTypes instance at
0x108ed2368>


*    def test_row_and_as_void_with_objects(self, table_types):*

*        """Test the deprecated data property and as_void() method"""*

*        t = table_types.Table([[{'a': 1}, {'b': 2}]], names=('a',))*

*        assert t[0][0] == {'a': 1}*

*        assert t[0]['a'] == {'a': 1}*

*        if NUMPY_LT_1_8 and t.masked:*

*            # With numpy < 1.8 there is a bug setting mvoid with*

*            # an object.*

*            with pytest.raises(ValueError):*

*>               t[0].as_void()*

*E               Failed: DID NOT RAISE*


astropy/table/tests/test_row.py:197: Failed

_______________________ test_masked_row_with_object_col
________________________


*    def test_masked_row_with_object_col():*

*        """*

*        Numpy < 1.8 has a bug in masked array that prevents access a row
if there is*

*        a column with object type.*

*        """*

*        t = table.Table([[1]], dtype=['O'], masked=True)*

*        if NUMPY_LT_1_8:*

*            with pytest.raises(ValueError):*

*                t['col0'].mask = False*

*>               t[0].as_void()*

*E               Failed: DID NOT RAISE*


astropy/table/tests/test_row.py:26: Failed

______________ TestRow.test_row_and_as_void_with_objects[masked]
_______________


self = <astropy.table.tests.test_row.TestRow instance at 0x10928e128>

table_types = <astropy.table.tests.conftest.TableTypes instance at
0x105bae128>


*    def test_row_and_as_void_with_objects(self, table_types):*

*        """Test the deprecated data property and as_void() method"""*

*        t = table_types.Table([[{'a': 1}, {'b': 2}]], names=('a',))*

*        assert t[0][0] == {'a': 1}*

*        assert t[0]['a'] == {'a': 1}*

*        if NUMPY_LT_1_8 and t.masked:*

*            # With numpy < 1.8 there is a bug setting mvoid with*

*            # an object.*

*            with pytest.raises(ValueError):*

*>               t[0].as_void()*

*E               Failed: DID NOT RAISE*


astropy/table/tests/test_row.py:197: Failed

_________________________ test_repr_array_of_quantity
__________________________


*    def test_repr_array_of_quantity():*

*        """*

*        Test print/repr of object arrays of Quantity objects with
different*

*        units.*



*        Regression test for the issue first reported in*

*        https://github.com/astropy/astropy/issues/3777
<https://github.com/astropy/astropy/issues/3777>*

*        """*



*        a = np.array([1 * u.m, 2 * u.s], dtype=object)*

*        if NUMPY_LT_1_7:*

*            # Numpy 1.6.x has some different defaults for how to display
object*

*            # arrays (it uses the str() of the objects instead of the
repr()*

*            assert repr(a) == 'array([1.0 m, 2.0 s], dtype=object)'*

*            assert str(a) == '[1.0 m 2.0 s]'*

*        else:*

*>           assert repr(a) == 'array([<Quantity 1.0 m>, <Quantity 2.0 s>],
dtype=object)'*

*E           assert 'array([1.0, ...dtype=object)' ==
'array([<Quant...dtype=object)'*

*E             - array([1.0, 2.0], dtype=object)*

*E             + array([<Quantity 1.0 m>, <Quantity 2.0 s>], dtype=object)*


astropy/units/tests/test_quantity.py:1180: AssertionError

______________________ TestQuantityStatsFuncs.test_median
______________________


self =
<astropy.units.tests.test_quantity_array_methods.TestQuantityStatsFuncs
object at 0x109b710d0>


*    def test_median(self):*

*        q1 = np.array([1., 2., 4., 5., 6.]) * u.m*

*>       assert np.median(q1) == 4. * u.m*

*E       assert 4.0 == (4.0 * Unit("m"))*

*E        +  where 4.0 = <function median at 0x1027548c0>(<Quantity [ 1.,
2., 4., 5., 6.] m>)*

*E        +    where <function median at 0x1027548c0> = np.median*

*E        +  and   Unit("m") = u.m*


astropy/units/tests/test_quantity_array_methods.py:178: AssertionError

__________________ TestQuantityStatsFuncs.test_median_inplace
__________________


self =
<astropy.units.tests.test_quantity_array_methods.TestQuantityStatsFuncs
object at 0x109b7c2d0>


*    def test_median_inplace(self):*

*        q1 = np.array([1., 2., 4., 5., 6.]) * u.m*

*        qi = 1.5 * u.s*

*        np.median(q1, out=qi)*

*>       assert qi == 4 * u.m*

*E       assert <Quantity 4.0 s> == (4 * Unit("m"))*

*E        +  where Unit("m") = u.m*


astropy/units/tests/test_quantity_array_methods.py:184: AssertionError

*= 9 failed, 9053 passed, 170 skipped, 43 xfailed, 2 xpassed in 284.03
seconds ==*

1

Does anybody know what might be causing these errors? Is there anything to
be concerned with?

Thank you in advance.

Astropy 1.1.dev12835
Darwin-14.3.0 - 64bit
Python 2.7.6
Numpy 1.8.0rc1
Scipy 0.13.0b1
Matplotlib 1.3.1
h5py 2.5.0
CVLattes: http://lattes.cnpq.br/3267230342393209
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150705/f421b9d6/attachment.html>

From embray at stsci.edu  Sun Jul  5 12:01:31 2015
From: embray at stsci.edu (Erik Bray)
Date: Sun, 5 Jul 2015 12:01:31 -0400
Subject: [AstroPy] errors returned by astropy.test()
In-Reply-To: <CAA9_Gr=r3Xon9oeE265didbzCW_=GHFARUR9sZ0DNXSyTUd6Zw@mail.gmail.com>
References: <CAA9_Gr=r3Xon9oeE265didbzCW_=GHFARUR9sZ0DNXSyTUd6Zw@mail.gmail.com>
Message-ID: <559954DB.6030006@stsci.edu>

Hi,

You seem to have a pre-release version of Numpy for some reason--specifically 
Numpy 1.8.0rc1.  So some code that works around issues with Numpy versions less 
than 1.8.0 is behaving awkwardly, since 1.8.0rc1 is technically less than 1.8.0 
(granted, those checks should probably ignore pre-release specifiers).

In other words, upgrade your Numpy to a released version and it should be fine.

Erik

On 07/05/2015 11:42 AM, Jos? Vin?cius wrote:
> Hi guys!
>
> I'm trying to install the developer's version of astropy, and after using
>  >> import astropy
>  >> astropy.test()
> I'm receiving several errors: *= 9 failed, 9053 passed, 170 skipped, 43 xfailed,
> 2 xpassed in 284.03 seconds == *1
>
> The log of failures is as follows
>
> =================================== FAILURES ===================================
>
> _______________________ test_getitem_metadata_regression _______________________
>
>
> *    def test_getitem_metadata_regression():*
>
> *        """*
>
> *        Regression test for #1471: MaskedArray does not call __array_finalize__ so*
>
> *        the meta-data was not getting copied over. By overloading _update_from we*
>
> *        are able to work around this bug.*
>
> *        """*
>
> **
>
> *        # Make sure that meta-data gets propagated with __getitem__*
>
> **
>
> *        c = table.Column(data=[1,2], name='a', description='b', unit='m',
> format="%i", meta={'c': 8})*
>
> *        assert c[1:2].name == 'a'*
>
> *        assert c[1:2].description == 'b'*
>
> *        assert c[1:2].unit == 'm'*
>
> *        assert c[1:2].format == '%i'*
>
> *        assert c[1:2].meta['c'] == 8*
>
> **
>
> *        c = table.MaskedColumn(data=[1,2], name='a', description='b', unit='m',
> format="%i", meta={'c': 8})*
>
> *        assert c[1:2].name == 'a'*
>
> *        assert c[1:2].description == 'b'*
>
> *        assert c[1:2].unit == 'm'*
>
> *        assert c[1:2].format == '%i'*
>
> *        assert c[1:2].meta['c'] == 8*
>
> **
>
> *        # As above, but with take() - check the method and the function*
>
> **
>
> *        c = table.Column(data=[1,2,3], name='a', description='b', unit='m',
> format="%i", meta={'c': 8})*
>
> *        for subset in [c.take([0, 1]), np.take(c, [0, 1])]:*
>
> *            assert subset.name <http://subset.name> == 'a'*
>
> *            assert subset.description == 'b'*
>
> *            assert subset.unit == 'm'*
>
> *            assert subset.format == '%i'*
>
> *            assert subset.meta['c'] == 8*
>
> **
>
> *        # Metadata isn't copied for scalar values*
>
> *        if NUMPY_LT_1_8:*
>
> *            with pytest.raises(ValueError):*
>
> *>               c.take(0)*
>
> *E               Failed: DID NOT RAISE*
>
>
> astropy/table/tests/test_column.py:467: Failed
>
> _______________________ test_getitem_metadata_regression _______________________
>
>
> *    def test_getitem_metadata_regression():*
>
> *        """*
>
> *        Regression test for #1471: MaskedArray does not call __array_finalize__ so*
>
> *        the meta-data was not getting copied over. By overloading _update_from we*
>
> *        are able to work around this bug.*
>
> *        """*
>
> **
>
> *        # Make sure that meta-data gets propagated with __getitem__*
>
> **
>
> *        c = table.Column(data=[1,2], name='a', description='b', unit='m',
> format="%i", meta={'c': 8})*
>
> *        assert c[1:2].name == 'a'*
>
> *        assert c[1:2].description == 'b'*
>
> *        assert c[1:2].unit == 'm'*
>
> *        assert c[1:2].format == '%i'*
>
> *        assert c[1:2].meta['c'] == 8*
>
> **
>
> *        c = table.MaskedColumn(data=[1,2], name='a', description='b', unit='m',
> format="%i", meta={'c': 8})*
>
> *        assert c[1:2].name == 'a'*
>
> *        assert c[1:2].description == 'b'*
>
> *        assert c[1:2].unit == 'm'*
>
> *        assert c[1:2].format == '%i'*
>
> *        assert c[1:2].meta['c'] == 8*
>
> **
>
> *        # As above, but with take() - check the method and the function*
>
> **
>
> *        c = table.Column(data=[1,2,3], name='a', description='b', unit='m',
> format="%i", meta={'c': 8})*
>
> *        for subset in [c.take([0, 1]), np.take(c, [0, 1])]:*
>
> *            assert subset.name <http://subset.name> == 'a'*
>
> *            assert subset.description == 'b'*
>
> *            assert subset.unit == 'm'*
>
> *            assert subset.format == '%i'*
>
> *            assert subset.meta['c'] == 8*
>
> **
>
> *        # Metadata isn't copied for scalar values*
>
> *        if NUMPY_LT_1_8:*
>
> *            with pytest.raises(ValueError):*
>
> *>               c.take(0)*
>
> *E               Failed: DID NOT RAISE*
>
>
> astropy/table/tests/test_column.py:467: Failed
>
> _______________________ test_masked_row_with_object_col ________________________
>
>
> *    def test_masked_row_with_object_col():*
>
> *        """*
>
> *        Numpy < 1.8 has a bug in masked array that prevents access a row if
> there is*
>
> *        a column with object type.*
>
> *        """*
>
> *        t = table.Table([[1]], dtype=['O'], masked=True)*
>
> *        if NUMPY_LT_1_8:*
>
> *            with pytest.raises(ValueError):*
>
> *                t['col0'].mask = False*
>
> *>               t[0].as_void()*
>
> *E               Failed: DID NOT RAISE*
>
>
> astropy/table/tests/test_row.py:26: Failed
>
> ______________ TestRow.test_row_and_as_void_with_objects[masked] _______________
>
>
> self = <astropy.table.tests.test_row.TestRow instance at 0x108ed2ab8>
>
> table_types = <astropy.table.tests.conftest.TableTypes instance at 0x108ed2368>
>
>
> *    def test_row_and_as_void_with_objects(self, table_types):*
>
> *        """Test the deprecated data property and as_void() method"""*
>
> *        t = table_types.Table([[{'a': 1}, {'b': 2}]], names=('a',))*
>
> *        assert t[0][0] == {'a': 1}*
>
> *        assert t[0]['a'] == {'a': 1}*
>
> *        if NUMPY_LT_1_8 and t.masked:*
>
> *            # With numpy < 1.8 there is a bug setting mvoid with*
>
> *            # an object.*
>
> *            with pytest.raises(ValueError):*
>
> *>               t[0].as_void()*
>
> *E               Failed: DID NOT RAISE*
>
>
> astropy/table/tests/test_row.py:197: Failed
>
> _______________________ test_masked_row_with_object_col ________________________
>
>
> *    def test_masked_row_with_object_col():*
>
> *        """*
>
> *        Numpy < 1.8 has a bug in masked array that prevents access a row if
> there is*
>
> *        a column with object type.*
>
> *        """*
>
> *        t = table.Table([[1]], dtype=['O'], masked=True)*
>
> *        if NUMPY_LT_1_8:*
>
> *            with pytest.raises(ValueError):*
>
> *                t['col0'].mask = False*
>
> *>               t[0].as_void()*
>
> *E               Failed: DID NOT RAISE*
>
>
> astropy/table/tests/test_row.py:26: Failed
>
> ______________ TestRow.test_row_and_as_void_with_objects[masked] _______________
>
>
> self = <astropy.table.tests.test_row.TestRow instance at 0x10928e128>
>
> table_types = <astropy.table.tests.conftest.TableTypes instance at 0x105bae128>
>
>
> *    def test_row_and_as_void_with_objects(self, table_types):*
>
> *        """Test the deprecated data property and as_void() method"""*
>
> *        t = table_types.Table([[{'a': 1}, {'b': 2}]], names=('a',))*
>
> *        assert t[0][0] == {'a': 1}*
>
> *        assert t[0]['a'] == {'a': 1}*
>
> *        if NUMPY_LT_1_8 and t.masked:*
>
> *            # With numpy < 1.8 there is a bug setting mvoid with*
>
> *            # an object.*
>
> *            with pytest.raises(ValueError):*
>
> *>               t[0].as_void()*
>
> *E               Failed: DID NOT RAISE*
>
>
> astropy/table/tests/test_row.py:197: Failed
>
> _________________________ test_repr_array_of_quantity __________________________
>
>
> *    def test_repr_array_of_quantity():*
>
> *        """*
>
> *        Test print/repr of object arrays of Quantity objects with different*
>
> *        units.*
>
> **
>
> *        Regression test for the issue first reported in*
>
> *https://github.com/astropy/astropy/issues/3777*
>
> *        """*
>
> **
>
> *        a = np.array([1 * u.m, 2 * u.s], dtype=object)*
>
> *        if NUMPY_LT_1_7:*
>
> *            # Numpy 1.6.x has some different defaults for how to display object*
>
> *            # arrays (it uses the str() of the objects instead of the repr()*
>
> *            assert repr(a) == 'array([1.0 m, 2.0 s], dtype=object)'*
>
> *            assert str(a) == '[1.0 m 2.0 s]'*
>
> *        else:*
>
> *>           assert repr(a) == 'array([<Quantity 1.0 m>, <Quantity 2.0 s>],
> dtype=object)'*
>
> *E           assert 'array([1.0, ...dtype=object)' ==
> 'array([<Quant...dtype=object)'*
>
> *E             - array([1.0, 2.0], dtype=object)*
>
> *E             + array([<Quantity 1.0 m>, <Quantity 2.0 s>], dtype=object)*
>
>
> astropy/units/tests/test_quantity.py:1180: AssertionError
>
> ______________________ TestQuantityStatsFuncs.test_median ______________________
>
>
> self = <astropy.units.tests.test_quantity_array_methods.TestQuantityStatsFuncs
> object at 0x109b710d0>
>
>
> *    def test_median(self):*
>
> *        q1 = np.array([1., 2., 4., 5., 6.]) * u.m*
>
> *>       assert np.median(q1) == 4. * u.m*
>
> *E       assert 4.0 == (4.0 * Unit("m"))*
>
> *E        +  where 4.0 = <function median at 0x1027548c0>(<Quantity [ 1., 2.,
> 4., 5., 6.] m>)*
>
> *E        +    where <function median at 0x1027548c0> = np.median*
>
> *E        +  and   Unit("m") = u.m*
>
>
> astropy/units/tests/test_quantity_array_methods.py:178: AssertionError
>
> __________________ TestQuantityStatsFuncs.test_median_inplace __________________
>
>
> self = <astropy.units.tests.test_quantity_array_methods.TestQuantityStatsFuncs
> object at 0x109b7c2d0>
>
>
> *    def test_median_inplace(self):*
>
> *        q1 = np.array([1., 2., 4., 5., 6.]) * u.m*
>
> *        qi = 1.5 * u.s*
>
> *        np.median(q1, out=qi)*
>
> *>       assert qi == 4 * u.m*
>
> *E       assert <Quantity 4.0 s> == (4 * Unit("m"))*
>
> *E        +  where Unit("m") = u.m*
>
>
> astropy/units/tests/test_quantity_array_methods.py:184: AssertionError
>
> *= 9 failed, 9053 passed, 170 skipped, 43 xfailed, 2 xpassed in 284.03 seconds ==*
>
> 1
>
>
> Does anybody know what might be causing these errors? Is there anything to be
> concerned with?
>
> Thank you in advance.
>
> Astropy 1.1.dev12835
> Darwin-14.3.0 - 64bit
> Python 2.7.6
> Numpy 1.8.0rc1
> Scipy 0.13.0b1
> Matplotlib 1.3.1
> h5py 2.5.0
> CVLattes: http://lattes.cnpq.br/3267230342393209
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From josevinicius at iecom.org.br  Sun Jul  5 18:35:21 2015
From: josevinicius at iecom.org.br (=?UTF-8?B?Sm9zw6kgVmluw61jaXVz?=)
Date: Sun, 5 Jul 2015 18:35:21 -0400
Subject: [AstroPy] errors returned by astropy.test()
In-Reply-To: <559954DB.6030006@stsci.edu>
References: <CAA9_Gr=r3Xon9oeE265didbzCW_=GHFARUR9sZ0DNXSyTUd6Zw@mail.gmail.com>
	<559954DB.6030006@stsci.edu>
Message-ID: <CAA9_GrnSRj8cJ8d5KytxK7T3fmGL8VVVJBf3tT6m_ETHTQnb=g@mail.gmail.com>

Erik,

With numpy 1.9.2, it's working just fine.

Thanks!

Ze.

Skype: joseviniciusmirca (feel free to call me)
CVLattes: http://lattes.cnpq.br/3267230342393209

On Sun, Jul 5, 2015 at 12:01 PM, Erik Bray <embray at stsci.edu> wrote:

> Hi,
>
> You seem to have a pre-release version of Numpy for some
> reason--specifically
> Numpy 1.8.0rc1.  So some code that works around issues with Numpy versions
> less
> than 1.8.0 is behaving awkwardly, since 1.8.0rc1 is technically less than
> 1.8.0
> (granted, those checks should probably ignore pre-release specifiers).
>
> In other words, upgrade your Numpy to a released version and it should be
> fine.
>
> Erik
>
> On 07/05/2015 11:42 AM, Jos? Vin?cius wrote:
> > Hi guys!
> >
> > I'm trying to install the developer's version of astropy, and after using
> >  >> import astropy
> >  >> astropy.test()
> > I'm receiving several errors: *= 9 failed, 9053 passed, 170 skipped, 43
> xfailed,
> > 2 xpassed in 284.03 seconds == *1
> >
> > The log of failures is as follows
> >
> > =================================== FAILURES
> ===================================
> >
> > _______________________ test_getitem_metadata_regression
> _______________________
> >
> >
> > *    def test_getitem_metadata_regression():*
> >
> > *        """*
> >
> > *        Regression test for #1471: MaskedArray does not call
> __array_finalize__ so*
> >
> > *        the meta-data was not getting copied over. By overloading
> _update_from we*
> >
> > *        are able to work around this bug.*
> >
> > *        """*
> >
> > **
> >
> > *        # Make sure that meta-data gets propagated with __getitem__*
> >
> > **
> >
> > *        c = table.Column(data=[1,2], name='a', description='b',
> unit='m',
> > format="%i", meta={'c': 8})*
> >
> > *        assert c[1:2].name == 'a'*
> >
> > *        assert c[1:2].description == 'b'*
> >
> > *        assert c[1:2].unit == 'm'*
> >
> > *        assert c[1:2].format == '%i'*
> >
> > *        assert c[1:2].meta['c'] == 8*
> >
> > **
> >
> > *        c = table.MaskedColumn(data=[1,2], name='a', description='b',
> unit='m',
> > format="%i", meta={'c': 8})*
> >
> > *        assert c[1:2].name == 'a'*
> >
> > *        assert c[1:2].description == 'b'*
> >
> > *        assert c[1:2].unit == 'm'*
> >
> > *        assert c[1:2].format == '%i'*
> >
> > *        assert c[1:2].meta['c'] == 8*
> >
> > **
> >
> > *        # As above, but with take() - check the method and the function*
> >
> > **
> >
> > *        c = table.Column(data=[1,2,3], name='a', description='b',
> unit='m',
> > format="%i", meta={'c': 8})*
> >
> > *        for subset in [c.take([0, 1]), np.take(c, [0, 1])]:*
> >
> > *            assert subset.name <http://subset.name> == 'a'*
> >
> > *            assert subset.description == 'b'*
> >
> > *            assert subset.unit == 'm'*
> >
> > *            assert subset.format == '%i'*
> >
> > *            assert subset.meta['c'] == 8*
> >
> > **
> >
> > *        # Metadata isn't copied for scalar values*
> >
> > *        if NUMPY_LT_1_8:*
> >
> > *            with pytest.raises(ValueError):*
> >
> > *>               c.take(0)*
> >
> > *E               Failed: DID NOT RAISE*
> >
> >
> > astropy/table/tests/test_column.py:467: Failed
> >
> > _______________________ test_getitem_metadata_regression
> _______________________
> >
> >
> > *    def test_getitem_metadata_regression():*
> >
> > *        """*
> >
> > *        Regression test for #1471: MaskedArray does not call
> __array_finalize__ so*
> >
> > *        the meta-data was not getting copied over. By overloading
> _update_from we*
> >
> > *        are able to work around this bug.*
> >
> > *        """*
> >
> > **
> >
> > *        # Make sure that meta-data gets propagated with __getitem__*
> >
> > **
> >
> > *        c = table.Column(data=[1,2], name='a', description='b',
> unit='m',
> > format="%i", meta={'c': 8})*
> >
> > *        assert c[1:2].name == 'a'*
> >
> > *        assert c[1:2].description == 'b'*
> >
> > *        assert c[1:2].unit == 'm'*
> >
> > *        assert c[1:2].format == '%i'*
> >
> > *        assert c[1:2].meta['c'] == 8*
> >
> > **
> >
> > *        c = table.MaskedColumn(data=[1,2], name='a', description='b',
> unit='m',
> > format="%i", meta={'c': 8})*
> >
> > *        assert c[1:2].name == 'a'*
> >
> > *        assert c[1:2].description == 'b'*
> >
> > *        assert c[1:2].unit == 'm'*
> >
> > *        assert c[1:2].format == '%i'*
> >
> > *        assert c[1:2].meta['c'] == 8*
> >
> > **
> >
> > *        # As above, but with take() - check the method and the function*
> >
> > **
> >
> > *        c = table.Column(data=[1,2,3], name='a', description='b',
> unit='m',
> > format="%i", meta={'c': 8})*
> >
> > *        for subset in [c.take([0, 1]), np.take(c, [0, 1])]:*
> >
> > *            assert subset.name <http://subset.name> == 'a'*
> >
> > *            assert subset.description == 'b'*
> >
> > *            assert subset.unit == 'm'*
> >
> > *            assert subset.format == '%i'*
> >
> > *            assert subset.meta['c'] == 8*
> >
> > **
> >
> > *        # Metadata isn't copied for scalar values*
> >
> > *        if NUMPY_LT_1_8:*
> >
> > *            with pytest.raises(ValueError):*
> >
> > *>               c.take(0)*
> >
> > *E               Failed: DID NOT RAISE*
> >
> >
> > astropy/table/tests/test_column.py:467: Failed
> >
> > _______________________ test_masked_row_with_object_col
> ________________________
> >
> >
> > *    def test_masked_row_with_object_col():*
> >
> > *        """*
> >
> > *        Numpy < 1.8 has a bug in masked array that prevents access a
> row if
> > there is*
> >
> > *        a column with object type.*
> >
> > *        """*
> >
> > *        t = table.Table([[1]], dtype=['O'], masked=True)*
> >
> > *        if NUMPY_LT_1_8:*
> >
> > *            with pytest.raises(ValueError):*
> >
> > *                t['col0'].mask = False*
> >
> > *>               t[0].as_void()*
> >
> > *E               Failed: DID NOT RAISE*
> >
> >
> > astropy/table/tests/test_row.py:26: Failed
> >
> > ______________ TestRow.test_row_and_as_void_with_objects[masked]
> _______________
> >
> >
> > self = <astropy.table.tests.test_row.TestRow instance at 0x108ed2ab8>
> >
> > table_types = <astropy.table.tests.conftest.TableTypes instance at
> 0x108ed2368>
> >
> >
> > *    def test_row_and_as_void_with_objects(self, table_types):*
> >
> > *        """Test the deprecated data property and as_void() method"""*
> >
> > *        t = table_types.Table([[{'a': 1}, {'b': 2}]], names=('a',))*
> >
> > *        assert t[0][0] == {'a': 1}*
> >
> > *        assert t[0]['a'] == {'a': 1}*
> >
> > *        if NUMPY_LT_1_8 and t.masked:*
> >
> > *            # With numpy < 1.8 there is a bug setting mvoid with*
> >
> > *            # an object.*
> >
> > *            with pytest.raises(ValueError):*
> >
> > *>               t[0].as_void()*
> >
> > *E               Failed: DID NOT RAISE*
> >
> >
> > astropy/table/tests/test_row.py:197: Failed
> >
> > _______________________ test_masked_row_with_object_col
> ________________________
> >
> >
> > *    def test_masked_row_with_object_col():*
> >
> > *        """*
> >
> > *        Numpy < 1.8 has a bug in masked array that prevents access a
> row if
> > there is*
> >
> > *        a column with object type.*
> >
> > *        """*
> >
> > *        t = table.Table([[1]], dtype=['O'], masked=True)*
> >
> > *        if NUMPY_LT_1_8:*
> >
> > *            with pytest.raises(ValueError):*
> >
> > *                t['col0'].mask = False*
> >
> > *>               t[0].as_void()*
> >
> > *E               Failed: DID NOT RAISE*
> >
> >
> > astropy/table/tests/test_row.py:26: Failed
> >
> > ______________ TestRow.test_row_and_as_void_with_objects[masked]
> _______________
> >
> >
> > self = <astropy.table.tests.test_row.TestRow instance at 0x10928e128>
> >
> > table_types = <astropy.table.tests.conftest.TableTypes instance at
> 0x105bae128>
> >
> >
> > *    def test_row_and_as_void_with_objects(self, table_types):*
> >
> > *        """Test the deprecated data property and as_void() method"""*
> >
> > *        t = table_types.Table([[{'a': 1}, {'b': 2}]], names=('a',))*
> >
> > *        assert t[0][0] == {'a': 1}*
> >
> > *        assert t[0]['a'] == {'a': 1}*
> >
> > *        if NUMPY_LT_1_8 and t.masked:*
> >
> > *            # With numpy < 1.8 there is a bug setting mvoid with*
> >
> > *            # an object.*
> >
> > *            with pytest.raises(ValueError):*
> >
> > *>               t[0].as_void()*
> >
> > *E               Failed: DID NOT RAISE*
> >
> >
> > astropy/table/tests/test_row.py:197: Failed
> >
> > _________________________ test_repr_array_of_quantity
> __________________________
> >
> >
> > *    def test_repr_array_of_quantity():*
> >
> > *        """*
> >
> > *        Test print/repr of object arrays of Quantity objects with
> different*
> >
> > *        units.*
> >
> > **
> >
> > *        Regression test for the issue first reported in*
> >
> > *https://github.com/astropy/astropy/issues/3777*
> >
> > *        """*
> >
> > **
> >
> > *        a = np.array([1 * u.m, 2 * u.s], dtype=object)*
> >
> > *        if NUMPY_LT_1_7:*
> >
> > *            # Numpy 1.6.x has some different defaults for how to
> display object*
> >
> > *            # arrays (it uses the str() of the objects instead of the
> repr()*
> >
> > *            assert repr(a) == 'array([1.0 m, 2.0 s], dtype=object)'*
> >
> > *            assert str(a) == '[1.0 m 2.0 s]'*
> >
> > *        else:*
> >
> > *>           assert repr(a) == 'array([<Quantity 1.0 m>, <Quantity 2.0
> s>],
> > dtype=object)'*
> >
> > *E           assert 'array([1.0, ...dtype=object)' ==
> > 'array([<Quant...dtype=object)'*
> >
> > *E             - array([1.0, 2.0], dtype=object)*
> >
> > *E             + array([<Quantity 1.0 m>, <Quantity 2.0 s>],
> dtype=object)*
> >
> >
> > astropy/units/tests/test_quantity.py:1180: AssertionError
> >
> > ______________________ TestQuantityStatsFuncs.test_median
> ______________________
> >
> >
> > self =
> <astropy.units.tests.test_quantity_array_methods.TestQuantityStatsFuncs
> > object at 0x109b710d0>
> >
> >
> > *    def test_median(self):*
> >
> > *        q1 = np.array([1., 2., 4., 5., 6.]) * u.m*
> >
> > *>       assert np.median(q1) == 4. * u.m*
> >
> > *E       assert 4.0 == (4.0 * Unit("m"))*
> >
> > *E        +  where 4.0 = <function median at 0x1027548c0>(<Quantity [
> 1., 2.,
> > 4., 5., 6.] m>)*
> >
> > *E        +    where <function median at 0x1027548c0> = np.median*
> >
> > *E        +  and   Unit("m") = u.m*
> >
> >
> > astropy/units/tests/test_quantity_array_methods.py:178: AssertionError
> >
> > __________________ TestQuantityStatsFuncs.test_median_inplace
> __________________
> >
> >
> > self =
> <astropy.units.tests.test_quantity_array_methods.TestQuantityStatsFuncs
> > object at 0x109b7c2d0>
> >
> >
> > *    def test_median_inplace(self):*
> >
> > *        q1 = np.array([1., 2., 4., 5., 6.]) * u.m*
> >
> > *        qi = 1.5 * u.s*
> >
> > *        np.median(q1, out=qi)*
> >
> > *>       assert qi == 4 * u.m*
> >
> > *E       assert <Quantity 4.0 s> == (4 * Unit("m"))*
> >
> > *E        +  where Unit("m") = u.m*
> >
> >
> > astropy/units/tests/test_quantity_array_methods.py:184: AssertionError
> >
> > *= 9 failed, 9053 passed, 170 skipped, 43 xfailed, 2 xpassed in 284.03
> seconds ==*
> >
> > 1
> >
> >
> > Does anybody know what might be causing these errors? Is there anything
> to be
> > concerned with?
> >
> > Thank you in advance.
> >
> > Astropy 1.1.dev12835
> > Darwin-14.3.0 - 64bit
> > Python 2.7.6
> > Numpy 1.8.0rc1
> > Scipy 0.13.0b1
> > Matplotlib 1.3.1
> > h5py 2.5.0
> > CVLattes: http://lattes.cnpq.br/3267230342393209
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150705/73b1a2bd/attachment.html>

From antony at cosmologist.info  Mon Jul  6 06:58:55 2015
From: antony at cosmologist.info (Antony Lewis)
Date: Mon, 6 Jul 2015 11:58:55 +0100
Subject: [AstroPy] ANN: GetDist sample analysis and plotting
Message-ID: <001d01d0b7da$c1454400$43cfcc00$@cosmologist.info>

Hi all,

There are lots of sampling programs these days, but it seems very 
few good sample analysis/plotting packages. So I've released a python 
package called GetDist which is now available in a fairly stable form at

  https://pypi.python.org/pypi/GetDist/
  https://github.com/cmbant/getdist

For (new) documentation, plot gallery and tutorial see

 http://getdist.readthedocs.org/en/latest/

Features include:

 - Plotting library 
   Make custom publication-ready 1D, 2D, 3D-scatter, triangle and other
plots

- Named parameters -
   Simple handling of many parameters using parameter names, including LaTeX
labels and prior bounds

- Optimized Kernel Density Estimation 
  Automated optimal bandwidth choice for 1D and 2D densities 
 (Botev et al. Improved Sheather-Jones method), with boundary and bias
correction; works with multi-modal and strongly correlated distributions

- Convergence diagnostics
   Including correlation length and diagonalized Gelman-Rubin statistics

- LaTeX tables for marginalized 1D constraints

- Point and click GUI 
   Select chain files, view plots, marginalized constraints, LaTeX tables
and more
   Built-in support for Planck parameter chain grids

If used to load chains from data files, currently GetDist uses the CosmoMC
sampler's simple plain text chain format (documented on the GetDist page).
This could easily be extended if there are other formats that people want to
use.

Suggestions/contributions welcome.

Antony



From trive at astro.su.se  Tue Jul  7 10:25:23 2015
From: trive at astro.su.se (=?UTF-8?B?VGjDuGdlciBFbWlsICBSaXZlcmEtVGhvcnNlbg==?=)
Date: Tue, 07 Jul 2015 16:25:23 +0200
Subject: [AstroPy] Fit statistics in astropy.fitting
Message-ID: <559BE153.8040009@astro.su.se>

This may be me having missed something, but is it not possible to get
fit statistics - goodmes-of-fit, confidence intervals etc. - from a
fitter in astropy.fitting?
I have usually been using LMFit for this kind of task, but
Astropy.modelling and astropy.fitting seem much quicker and simpler to
use - but I cannot seem to get fit statistics from the fitter anywhere.

Am I missing something or is it simply not implemented?


Emil Rivera-Thorsen
Ph.D. candidate, Astronomy
Stockholm University
Sweden


From burtscher at mpe.mpg.de  Tue Jul  7 11:10:32 2015
From: burtscher at mpe.mpg.de (Leonard Burtscher)
Date: Tue, 7 Jul 2015 17:10:32 +0200
Subject: [AstroPy] Extend io.fits class to support wavelength vector?
Message-ID: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>

Hi,

I'm new to this list, but reasonably sure that this question hasn't been asked the last year or so.

When opening a FITS file that includes a spectrum I would like to directly have access to the wavelength vector and store it in a variable, e.g.

hdu=fits.open("test.fits",ext=2,wave=wave)

where

hdr=hdu[2].header
wave=(np.arange(hdr['NAXISi'])+1-hdr['CRPIXi'])*hdr['CDELTi']+hdr['CRVALi']

and

i is chosen such that CTYPEi=="WAVE". The unit is given by CUNITi and could be converted by default to e.g. meters. In case of more than one WAVE axis or missing header information, a warning should be given and the routine could fall back to the usual behaviour without constructing the wavelength vector.

Since this is a very generically used functionality, wouldn't it make sense to implement this into the core of the astropy package?

Cheers,
Leo



From mdroe at stsci.edu  Tue Jul  7 11:44:34 2015
From: mdroe at stsci.edu (Michael Droettboom)
Date: Tue, 7 Jul 2015 11:44:34 -0400
Subject: [AstroPy] Extend io.fits class to support wavelength vector?
In-Reply-To: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
References: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
Message-ID: <559BF3E2.1020002@stsci.edu>

I think you probably want to look at the `astropy.wcs` package which 
handles the conversion from raw values to physical values and back based 
on a FITS header.

Mike

On 07/07/2015 11:10 AM, Leonard Burtscher wrote:
> Hi,
>
> I'm new to this list, but reasonably sure that this question hasn't been asked the last year or so.
>
> When opening a FITS file that includes a spectrum I would like to directly have access to the wavelength vector and store it in a variable, e.g.
>
> hdu=fits.open("test.fits",ext=2,wave=wave)
>
> where
>
> hdr=hdu[2].header
> wave=(np.arange(hdr['NAXISi'])+1-hdr['CRPIXi'])*hdr['CDELTi']+hdr['CRVALi']
>
> and
>
> i is chosen such that CTYPEi=="WAVE". The unit is given by CUNITi and could be converted by default to e.g. meters. In case of more than one WAVE axis or missing header information, a warning should be given and the routine could fall back to the usual behaviour without constructing the wavelength vector.
>
> Since this is a very generically used functionality, wouldn't it make sense to implement this into the core of the astropy package?
>
> Cheers,
> Leo
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From tim.jenness at gmail.com  Tue Jul  7 11:47:55 2015
From: tim.jenness at gmail.com (Tim Jenness)
Date: Tue, 7 Jul 2015 08:47:55 -0700
Subject: [AstroPy] Extend io.fits class to support wavelength vector?
In-Reply-To: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
References: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
Message-ID: <CA+G92Rfk-fRzKc9vbj30Y7Pv3KeRcTpqDDjuUJsfa4WRjEy0dw@mail.gmail.com>

What you are describing is a specific implementation of a world coordinate
system for wavelength. There are many ways that a spectral axis can be
defined using FITS headers (you also have to worry about reference frames
and observer locations in theory) and this should be handled by a generic
WCS infrastructure rather than trying to teach the FITS reader how to do
it. The starlink-pyast package is designed for this, just as are other WCS
libraries.

-- 
Tim Jenness


On Tue, Jul 7, 2015 at 8:10 AM, Leonard Burtscher <burtscher at mpe.mpg.de>
wrote:

> Hi,
>
> I'm new to this list, but reasonably sure that this question hasn't been
> asked the last year or so.
>
> When opening a FITS file that includes a spectrum I would like to directly
> have access to the wavelength vector and store it in a variable, e.g.
>
> hdu=fits.open("test.fits",ext=2,wave=wave)
>
> where
>
> hdr=hdu[2].header
> wave=(np.arange(hdr['NAXISi'])+1-hdr['CRPIXi'])*hdr['CDELTi']+hdr['CRVALi']
>
> and
>
> i is chosen such that CTYPEi=="WAVE". The unit is given by CUNITi and
> could be converted by default to e.g. meters. In case of more than one WAVE
> axis or missing header information, a warning should be given and the
> routine could fall back to the usual behaviour without constructing the
> wavelength vector.
>
> Since this is a very generically used functionality, wouldn't it make
> sense to implement this into the core of the astropy package?
>
> Cheers,
> Leo
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150707/c6fcdcc0/attachment.html>

From crawford at saao.ac.za  Tue Jul  7 11:54:39 2015
From: crawford at saao.ac.za (Steve Crawford)
Date: Tue, 7 Jul 2015 17:54:39 +0200 (SAST)
Subject: [AstroPy] Extend io.fits class to support wavelength vector?
In-Reply-To: <559BF3E2.1020002@stsci.edu>
References: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
	<559BF3E2.1020002@stsci.edu>
Message-ID: <1739579117.1233849.1436284479875.JavaMail.zimbra@saao.ac.za>



Also you might want to check out the specutils affiliated package.  It already has a number of easy ways to read in 1D spectrum:
http://specutils.readthedocs.org/en/latest/

Cheers
Steve

----- Original Message -----
From: "Michael Droettboom" <mdroe at stsci.edu>
To: astropy at scipy.org
Sent: Tuesday, July 7, 2015 11:44:34 AM
Subject: Re: [AstroPy] Extend io.fits class to support wavelength vector?

I think you probably want to look at the `astropy.wcs` package which 
handles the conversion from raw values to physical values and back based 
on a FITS header.

Mike

On 07/07/2015 11:10 AM, Leonard Burtscher wrote:
> Hi,
>
> I'm new to this list, but reasonably sure that this question hasn't been asked the last year or so.
>
> When opening a FITS file that includes a spectrum I would like to directly have access to the wavelength vector and store it in a variable, e.g.
>
> hdu=fits.open("test.fits",ext=2,wave=wave)
>
> where
>
> hdr=hdu[2].header
> wave=(np.arange(hdr['NAXISi'])+1-hdr['CRPIXi'])*hdr['CDELTi']+hdr['CRVALi']
>
> and
>
> i is chosen such that CTYPEi=="WAVE". The unit is given by CUNITi and could be converted by default to e.g. meters. In case of more than one WAVE axis or missing header information, a warning should be given and the routine could fall back to the usual behaviour without constructing the wavelength vector.
>
> Since this is a very generically used functionality, wouldn't it make sense to implement this into the core of the astropy package?
>
> Cheers,
> Leo
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

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

!DSPAM:559bf5d765029651824641!



From embray at stsci.edu  Tue Jul  7 13:28:19 2015
From: embray at stsci.edu (Erik Bray)
Date: Tue, 7 Jul 2015 13:28:19 -0400
Subject: [AstroPy] Extend io.fits class to support wavelength vector?
In-Reply-To: <559BF3E2.1020002@stsci.edu>
References: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
	<559BF3E2.1020002@stsci.edu>
Message-ID: <559C0C33.40309@stsci.edu>

On 07/07/2015 11:44 AM, Michael Droettboom wrote:
> I think you probably want to look at the `astropy.wcs` package which
> handles the conversion from raw values to physical values and back based
> on a FITS header.

Although I have said for a long time that it would be nice if the FITS interface 
did handle FITS WCS more directly.  I'm not sure exactly what it would look 
like, but I've been poking about creating a FITSData class that contains several 
FITS-isms baked into it (it would be used for table columns as well as IMAGE 
arrays).  This class could also have WCS support built into it, so that it can 
return a copy itself with the WCS applied and the WCS axes labeled in some way. 
  I haven't really thought too deeply about it.  In any case this would still be 
a (relatively low level) interface specific to FITS WCS.

>
> On 07/07/2015 11:10 AM, Leonard Burtscher wrote:
>> Hi,
>>
>> I'm new to this list, but reasonably sure that this question hasn't been asked the last year or so.
>>
>> When opening a FITS file that includes a spectrum I would like to directly have access to the wavelength vector and store it in a variable, e.g.
>>
>> hdu=fits.open("test.fits",ext=2,wave=wave)
>>
>> where
>>
>> hdr=hdu[2].header
>> wave=(np.arange(hdr['NAXISi'])+1-hdr['CRPIXi'])*hdr['CDELTi']+hdr['CRVALi']
>>
>> and
>>
>> i is chosen such that CTYPEi=="WAVE". The unit is given by CUNITi and could be converted by default to e.g. meters. In case of more than one WAVE axis or missing header information, a warning should be given and the routine could fall back to the usual behaviour without constructing the wavelength vector.
>>
>> Since this is a very generically used functionality, wouldn't it make sense to implement this into the core of the astropy package?
>>
>> Cheers,
>> Leo
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From josevinicius at iecom.org.br  Tue Jul  7 13:28:24 2015
From: josevinicius at iecom.org.br (=?UTF-8?B?Sm9zw6kgVmluw61jaXVz?=)
Date: Tue, 7 Jul 2015 13:28:24 -0400
Subject: [AstroPy] Fit statistics in astropy.fitting
In-Reply-To: <559BE153.8040009@astro.su.se>
References: <559BE153.8040009@astro.su.se>
Message-ID: <CAA9_Grnpe9=ZNcnZwHoN8e-gsCZqUngTbPyir4PSkpnV_ogSLQ@mail.gmail.com>

Hey,

I'm not sure, but I think there exists an implementation for the covariance
matrix (in astropy.fitting), so that the diagonal of this matrix gives you
the variance of the estimator for each parameter that you are fitting.

Cheers.

Jose.



CVLattes: http://lattes.cnpq.br/3267230342393209

On Tue, Jul 7, 2015 at 10:25 AM, Th?ger Emil Rivera-Thorsen <
trive at astro.su.se> wrote:

> This may be me having missed something, but is it not possible to get
> fit statistics - goodmes-of-fit, confidence intervals etc. - from a
> fitter in astropy.fitting?
> I have usually been using LMFit for this kind of task, but
> Astropy.modelling and astropy.fitting seem much quicker and simpler to
> use - but I cannot seem to get fit statistics from the fitter anywhere.
>
> Am I missing something or is it simply not implemented?
>
>
> Emil Rivera-Thorsen
> Ph.D. candidate, Astronomy
> Stockholm University
> Sweden
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150707/a3c55f8e/attachment.html>

From embray at stsci.edu  Tue Jul  7 14:15:58 2015
From: embray at stsci.edu (Erik Bray)
Date: Tue, 7 Jul 2015 14:15:58 -0400
Subject: [AstroPy] Fit statistics in astropy.fitting
In-Reply-To: <CAA9_Grnpe9=ZNcnZwHoN8e-gsCZqUngTbPyir4PSkpnV_ogSLQ@mail.gmail.com>
References: <559BE153.8040009@astro.su.se>
	<CAA9_Grnpe9=ZNcnZwHoN8e-gsCZqUngTbPyir4PSkpnV_ogSLQ@mail.gmail.com>
Message-ID: <559C175E.5010800@stsci.edu>

On 07/07/2015 01:28 PM, Jos? Vin?cius wrote:
> Hey,
>
> I'm not sure, but I think there exists an implementation for the covariance
> matrix (in astropy.fitting), so that the diagonal of this matrix gives you the
> variance of the estimator for each parameter that you are fitting.

Some of the fitters do this.  For example, any fitter that uses 
scipy.optimize.leastsq (i.e. LevMarLSQFitter) has this since leastsq returns a
cov_x [1] array that can be converted to the covariances (which LevMarLSQFitter 
does and stores of in a 'param_cov' key in the fit_info dict.

As was discussed at the Python in Astronomy workshop later this year, a goal for 
the astropy.modeling fitting framework should be as a glue between different 
fitting / optimization packages.  It sort of already works this way, by 
providing wrappers around (some of) scipy.optimize, though there's no reason it 
can't wrap other code as well (we discussed what it would take to integrate 
Sherpa into the framework for example).

Part of this "glue" would include improving the handling of various fit 
statistics and provide a reasonably common (and less cryptic) interface between 
fitters.  So while scipy.optimize.leastsq makes it easy to return a covariance 
matrix for the fitted parameters, other optimizers might require more work (this 
has been discussed a little bit such as in this issue: [2])  But either way the 
user interface to getting the cov matrix (just as an example) should be the same 
between "fitters"  It would be great to see more progress on issues like that.

It would also be great to collect more concrete requirements on this.

Also following that meeting there has been a flurry of activity adding various 
statistical tests to the astropy.stats package [3] [4].  The next logical step 
with these is to integrate them more tightly into astropy.modeling.fitting.

Erik


[1] 
http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.optimize.leastsq.html

[2] https://github.com/astropy/astropy/issues/1055

[3] https://github.com/astropy/astropy/pulls?q=label%3Astats+is%3Apr+is%3Aopen

[4] https://github.com/astropy/astropy/issues?q=label%3Astats+is%3Aopen+is%3Aissue

>
> CVLattes: http://lattes.cnpq.br/3267230342393209
>
> On Tue, Jul 7, 2015 at 10:25 AM, Th?ger Emil Rivera-Thorsen <trive at astro.su.se
> <mailto:trive at astro.su.se>> wrote:
>
>     This may be me having missed something, but is it not possible to get
>     fit statistics - goodmes-of-fit, confidence intervals etc. - from a
>     fitter in astropy.fitting?
>     I have usually been using LMFit for this kind of task, but
>     Astropy.modelling and astropy.fitting seem much quicker and simpler to
>     use - but I cannot seem to get fit statistics from the fitter anywhere.
>
>     Am I missing something or is it simply not implemented?
>
>
>     Emil Rivera-Thorsen
>     Ph.D. candidate, Astronomy
>     Stockholm University
>     Sweden
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From burtscher at mpe.mpg.de  Tue Jul  7 15:09:43 2015
From: burtscher at mpe.mpg.de (Leonard Burtscher)
Date: Tue, 7 Jul 2015 21:09:43 +0200
Subject: [AstroPy] Extend io.fits class to support wavelength vector?
In-Reply-To: <559C0C33.40309@stsci.edu>
References: <0B0C2523-8CD8-4CE2-BA2F-89B5DA63EFEE@mpe.mpg.de>
	<559BF3E2.1020002@stsci.edu> <559C0C33.40309@stsci.edu>
Message-ID: <9F7BBACC-2E76-426F-975E-AC4DA7B32F13@mpe.mpg.de>

Thanks everyone for your quick responses! I'll look into the packages you mentioned.

Cheers,
Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2158 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20150707/1d015dd3/attachment.bin>

From trive at astro.su.se  Tue Jul  7 16:47:17 2015
From: trive at astro.su.se (=?UTF-8?B?VGjDuGdlciBFbWlsICBSaXZlcmEtVGhvcnNlbg==?=)
Date: Tue, 07 Jul 2015 22:47:17 +0200
Subject: [AstroPy] Fit statistics in astropy.fitting
In-Reply-To: <559C175E.5010800@stsci.edu>
References: <559BE153.8040009@astro.su.se>
	<CAA9_Grnpe9=ZNcnZwHoN8e-gsCZqUngTbPyir4PSkpnV_ogSLQ@mail.gmail.com>
	<559C175E.5010800@stsci.edu>
Message-ID: <559C3AD5.8040608@astro.su.se>

Thank you, folks!
Very useful answers.


On 07/07/2015 08:15 PM, Erik Bray wrote:
> On 07/07/2015 01:28 PM, Jos? Vin?cius wrote:
> > Hey,
> >
> > I'm not sure, but I think there exists an implementation for the covariance
> > matrix (in astropy.fitting), so that the diagonal of this matrix gives you the
> > variance of the estimator for each parameter that you are fitting.
>
> Some of the fitters do this.  For example, any fitter that uses
> scipy.optimize.leastsq (i.e. LevMarLSQFitter) has this since leastsq returns a
> cov_x [1] array that can be converted to the covariances (which LevMarLSQFitter
> does and stores of in a 'param_cov' key in the fit_info dict.
>
> As was discussed at the Python in Astronomy workshop later this year, a goal for
> the astropy.modeling fitting framework should be as a glue between different
> fitting / optimization packages.  It sort of already works this way, by
> providing wrappers around (some of) scipy.optimize, though there's no reason it
> can't wrap other code as well (we discussed what it would take to integrate
> Sherpa into the framework for example).
>
> Part of this "glue" would include improving the handling of various fit
> statistics and provide a reasonably common (and less cryptic) interface between
> fitters.  So while scipy.optimize.leastsq makes it easy to return a covariance
> matrix for the fitted parameters, other optimizers might require more work (this
> has been discussed a little bit such as in this issue: [2])  But either way the
> user interface to getting the cov matrix (just as an example) should be the same
> between "fitters"  It would be great to see more progress on issues like that.
>
> It would also be great to collect more concrete requirements on this.
>
> Also following that meeting there has been a flurry of activity adding various
> statistical tests to the astropy.stats package [3] [4].  The next logical step
> with these is to integrate them more tightly into astropy.modeling.fitting.
>
> Erik
>
>
> [1]
> http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.optimize.leastsq.html
>
> [2] https://github.com/astropy/astropy/issues/1055
>
> [3] https://github.com/astropy/astropy/pulls?q=label%3Astats+is%3Apr+is%3Aopen
>
> [4] https://github.com/astropy/astropy/issues?q=label%3Astats+is%3Aopen+is%3Aissue
>
> >
> > CVLattes: http://lattes.cnpq.br/3267230342393209
> >
> > On Tue, Jul 7, 2015 at 10:25 AM, Th?ger Emil Rivera-Thorsen <trive at astro.su.se
> > <mailto:trive at astro.su.se>> wrote:
> >
> >     This may be me having missed something, but is it not possible to get
> >     fit statistics - goodmes-of-fit, confidence intervals etc. - from a
> >     fitter in astropy.fitting?
> >     I have usually been using LMFit for this kind of task, but
> >     Astropy.modelling and astropy.fitting seem much quicker and simpler to
> >     use - but I cannot seem to get fit statistics from the fitter anywhere.
> >
> >     Am I missing something or is it simply not implemented?
> >
> >
> >     Emil Rivera-Thorsen
> >     Ph.D. candidate, Astronomy
> >     Stockholm University
> >     Sweden
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     http://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From teuben at astro.umd.edu  Wed Jul  8 08:39:36 2015
From: teuben at astro.umd.edu (Peter Teuben)
Date: Wed, 08 Jul 2015 08:39:36 -0400
Subject: [AstroPy] astroquery broken after update?
Message-ID: <559D1A08.1000400@astro.umd.edu>

This problem may be peculiar to my set up, but it's working on my laptop,
but on an anaconda based system where I simply did a "pip install
astroquery"
(which has worked for other things in this way), i can't import any
submodules
under astroquery anymore, viz.

    import astroquery.simbad

would result in the following error, and wondering if this can be fixed
in some
way or another....





ValueError: Input values did not match any of the formats where the
format keyword is optional [u'astropy_time', u'datetime', u'jyear_str',
u'iso', u'isot', u'yday', u'byear_str']

this came from:

/astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
in _get_time_fmt(self, val, val2, format, scale)
--> 281             raise ValueError('Input values did not match
{0}'.format(err_msg))


which came from

/astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
in _init_from_vals(self, val, val2, format, scale, copy)
--> 241         self._time = self._get_time_fmt(val, val2, format, scale)


/astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
in __init__(self, val, val2, format, scale, precision, in_subfmt,
out_subfmt, location, copy)
--> 199             self._init_from_vals(val, val2, format, scale, copy)

/astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/coordinates/earth_orientation.py
in <module>()
---> 19 jd1950 = Time('B1950', scale='tai').jd







From mr.alex.hagen at gmail.com  Tue Jul  7 22:18:25 2015
From: mr.alex.hagen at gmail.com (Alex Hagen)
Date: Wed, 8 Jul 2015 11:18:25 +0900
Subject: [AstroPy] Fit statistics in astropy.fitting
In-Reply-To: <559C175E.5010800@stsci.edu>
References: <559BE153.8040009@astro.su.se>
	<CAA9_Grnpe9=ZNcnZwHoN8e-gsCZqUngTbPyir4PSkpnV_ogSLQ@mail.gmail.com>
	<559C175E.5010800@stsci.edu>
Message-ID: <CANS2AxKEKqnBw64fQ_+1wzdBE_nXNfKSow1BfnhJLexrpQRkBQ@mail.gmail.com>

Emil,

Thanks for your email. This is a good point. As Erik said, there is work
being done on Astropy.stats to incorporate some of this. Perhaps open an
issue with what you'd like to see? I think there are some formula for going
from the covariance matrix to confidence intervals (with some assumptions),
and we should probably code this up in fitting or stats.

--alex

On Wed, Jul 8, 2015 at 3:15 AM, Erik Bray <embray at stsci.edu> wrote:

> On 07/07/2015 01:28 PM, Jos? Vin?cius wrote:
> > Hey,
> >
> > I'm not sure, but I think there exists an implementation for the
> covariance
> > matrix (in astropy.fitting), so that the diagonal of this matrix gives
> you the
> > variance of the estimator for each parameter that you are fitting.
>
> Some of the fitters do this.  For example, any fitter that uses
> scipy.optimize.leastsq (i.e. LevMarLSQFitter) has this since leastsq
> returns a
> cov_x [1] array that can be converted to the covariances (which
> LevMarLSQFitter
> does and stores of in a 'param_cov' key in the fit_info dict.
>
> As was discussed at the Python in Astronomy workshop later this year, a
> goal for
> the astropy.modeling fitting framework should be as a glue between
> different
> fitting / optimization packages.  It sort of already works this way, by
> providing wrappers around (some of) scipy.optimize, though there's no
> reason it
> can't wrap other code as well (we discussed what it would take to integrate
> Sherpa into the framework for example).
>
> Part of this "glue" would include improving the handling of various fit
> statistics and provide a reasonably common (and less cryptic) interface
> between
> fitters.  So while scipy.optimize.leastsq makes it easy to return a
> covariance
> matrix for the fitted parameters, other optimizers might require more work
> (this
> has been discussed a little bit such as in this issue: [2])  But either
> way the
> user interface to getting the cov matrix (just as an example) should be
> the same
> between "fitters"  It would be great to see more progress on issues like
> that.
>
> It would also be great to collect more concrete requirements on this.
>
> Also following that meeting there has been a flurry of activity adding
> various
> statistical tests to the astropy.stats package [3] [4].  The next logical
> step
> with these is to integrate them more tightly into astropy.modeling.fitting.
>
> Erik
>
>
> [1]
>
> http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.optimize.leastsq.html
>
> [2] https://github.com/astropy/astropy/issues/1055
>
> [3]
> https://github.com/astropy/astropy/pulls?q=label%3Astats+is%3Apr+is%3Aopen
>
> [4]
> https://github.com/astropy/astropy/issues?q=label%3Astats+is%3Aopen+is%3Aissue
>
> >
> > CVLattes: http://lattes.cnpq.br/3267230342393209
> >
> > On Tue, Jul 7, 2015 at 10:25 AM, Th?ger Emil Rivera-Thorsen <
> trive at astro.su.se
> > <mailto:trive at astro.su.se>> wrote:
> >
> >     This may be me having missed something, but is it not possible to get
> >     fit statistics - goodmes-of-fit, confidence intervals etc. - from a
> >     fitter in astropy.fitting?
> >     I have usually been using LMFit for this kind of task, but
> >     Astropy.modelling and astropy.fitting seem much quicker and simpler
> to
> >     use - but I cannot seem to get fit statistics from the fitter
> anywhere.
> >
> >     Am I missing something or is it simply not implemented?
> >
> >
> >     Emil Rivera-Thorsen
> >     Ph.D. candidate, Astronomy
> >     Stockholm University
> >     Sweden
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     http://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Alex Hagen
Ph.D Candidate
Dept. of Astronomy and Astrophysics
& the Institute for Gravitation and the Cosmos
The Pennsylvania State University

https://astronomeralex.github.io/

Mailing Address:
525 Davey Lab
University Park, PA 16802-6305

Office:
313 Davey Lab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150708/901425cb/attachment.html>

From adam.g.ginsburg at gmail.com  Wed Jul  8 09:29:55 2015
From: adam.g.ginsburg at gmail.com (Adam Ginsburg)
Date: Wed, 8 Jul 2015 15:29:55 +0200
Subject: [AstroPy] astroquery broken after update?
In-Reply-To: <559D1A08.1000400@astro.umd.edu>
References: <559D1A08.1000400@astro.umd.edu>
Message-ID: <CAEBNSwbHdoi-Ebmr6SQxePTaQtzbL3mu_VPxpzeYWBsB+hUMhA@mail.gmail.com>

It looks like this is happening just when you import astropy; can you
still import astropy.units and astropy.coordinates?  If not, the
problem lies there.  If this is really just in astroquery, I'm not
sure what's going on - does it happen for other astroquery submodules?

On Wed, Jul 8, 2015 at 2:39 PM, Peter Teuben <teuben at astro.umd.edu> wrote:
> This problem may be peculiar to my set up, but it's working on my laptop,
> but on an anaconda based system where I simply did a "pip install
> astroquery"
> (which has worked for other things in this way), i can't import any
> submodules
> under astroquery anymore, viz.
>
>     import astroquery.simbad
>
> would result in the following error, and wondering if this can be fixed
> in some
> way or another....
>
>
>
>
>
> ValueError: Input values did not match any of the formats where the
> format keyword is optional [u'astropy_time', u'datetime', u'jyear_str',
> u'iso', u'isot', u'yday', u'byear_str']
>
> this came from:
>
> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
> in _get_time_fmt(self, val, val2, format, scale)
> --> 281             raise ValueError('Input values did not match
> {0}'.format(err_msg))
>
>
> which came from
>
> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
> in _init_from_vals(self, val, val2, format, scale, copy)
> --> 241         self._time = self._get_time_fmt(val, val2, format, scale)
>
>
> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
> in __init__(self, val, val2, format, scale, precision, in_subfmt,
> out_subfmt, location, copy)
> --> 199             self._init_from_vals(val, val2, format, scale, copy)
>
> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/coordinates/earth_orientation.py
> in <module>()
> ---> 19 jd1950 = Time('B1950', scale='tai').jd
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Adam Ginsburg
Fellow, European Southern Observatory
http://www.adamgginsburg.com/


From teuben at astro.umd.edu  Wed Jul  8 12:21:14 2015
From: teuben at astro.umd.edu (Peter Teuben)
Date: Wed, 08 Jul 2015 12:21:14 -0400
Subject: [AstroPy] astroquery broken after update?
In-Reply-To: <CAEBNSwbHdoi-Ebmr6SQxePTaQtzbL3mu_VPxpzeYWBsB+hUMhA@mail.gmail.com>
References: <559D1A08.1000400@astro.umd.edu>
	<CAEBNSwbHdoi-Ebmr6SQxePTaQtzbL3mu_VPxpzeYWBsB+hUMhA@mail.gmail.com>
Message-ID: <559D4DFA.7030603@astro.umd.edu>

It was happening for most (all?) astroquery.<name> modules

Following your other suggestion, the astropy.units works,
but the astropy.coordinates does give exactly this error!!!

Just "import astropy"  works fine.




On 07/08/2015 09:29 AM, Adam Ginsburg wrote:
> It looks like this is happening just when you import astropy; can you
> still import astropy.units and astropy.coordinates?  If not, the
> problem lies there.  If this is really just in astroquery, I'm not
> sure what's going on - does it happen for other astroquery submodules?
>
> On Wed, Jul 8, 2015 at 2:39 PM, Peter Teuben <teuben at astro.umd.edu> wrote:
>> This problem may be peculiar to my set up, but it's working on my laptop,
>> but on an anaconda based system where I simply did a "pip install
>> astroquery"
>> (which has worked for other things in this way), i can't import any
>> submodules
>> under astroquery anymore, viz.
>>
>>     import astroquery.simbad
>>
>> would result in the following error, and wondering if this can be fixed
>> in some
>> way or another....
>>
>>
>>
>>
>>
>> ValueError: Input values did not match any of the formats where the
>> format keyword is optional [u'astropy_time', u'datetime', u'jyear_str',
>> u'iso', u'isot', u'yday', u'byear_str']
>>
>> this came from:
>>
>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>> in _get_time_fmt(self, val, val2, format, scale)
>> --> 281             raise ValueError('Input values did not match
>> {0}'.format(err_msg))
>>
>>
>> which came from
>>
>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>> in _init_from_vals(self, val, val2, format, scale, copy)
>> --> 241         self._time = self._get_time_fmt(val, val2, format, scale)
>>
>>
>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>> in __init__(self, val, val2, format, scale, precision, in_subfmt,
>> out_subfmt, location, copy)
>> --> 199             self._init_from_vals(val, val2, format, scale, copy)
>>
>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/coordinates/earth_orientation.py
>> in <module>()
>> ---> 19 jd1950 = Time('B1950', scale='tai').jd
>>
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>



From avillaum at ucsc.edu  Wed Jul  8 13:38:27 2015
From: avillaum at ucsc.edu (Alexa Villaume)
Date: Wed, 8 Jul 2015 10:38:27 -0700
Subject: [AstroPy] astroquery broken after update?
In-Reply-To: <559D4DFA.7030603@astro.umd.edu>
References: <559D1A08.1000400@astro.umd.edu>
	<CAEBNSwbHdoi-Ebmr6SQxePTaQtzbL3mu_VPxpzeYWBsB+hUMhA@mail.gmail.com>
	<559D4DFA.7030603@astro.umd.edu>
Message-ID: <6A9CBAA0-279C-4A6A-B574-7DA187106738@ucsc.edu>

Hi Peter,

I had the same problem where astroquery wasn?t importing on the anaconda based python package. I installed astroquery from the github repo and so my anaconda installation didn?t ?know? about astroquery. To fix this, I made a symlink to astroquery in my anaconda directory. In your anaconda directory you can try,

ln -s <path to astroquery> astroquery.

Alexa

On Jul 8, 2015, at 9:21 AM, Peter Teuben <teuben at astro.umd.edu> wrote:

> It was happening for most (all?) astroquery.<name> modules
> 
> Following your other suggestion, the astropy.units works,
> but the astropy.coordinates does give exactly this error!!!
> 
> Just "import astropy"  works fine.
> 
> 
> 
> 
> On 07/08/2015 09:29 AM, Adam Ginsburg wrote:
>> It looks like this is happening just when you import astropy; can you
>> still import astropy.units and astropy.coordinates?  If not, the
>> problem lies there.  If this is really just in astroquery, I'm not
>> sure what's going on - does it happen for other astroquery submodules?
>> 
>> On Wed, Jul 8, 2015 at 2:39 PM, Peter Teuben <teuben at astro.umd.edu> wrote:
>>> This problem may be peculiar to my set up, but it's working on my laptop,
>>> but on an anaconda based system where I simply did a "pip install
>>> astroquery"
>>> (which has worked for other things in this way), i can't import any
>>> submodules
>>> under astroquery anymore, viz.
>>> 
>>>    import astroquery.simbad
>>> 
>>> would result in the following error, and wondering if this can be fixed
>>> in some
>>> way or another....
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ValueError: Input values did not match any of the formats where the
>>> format keyword is optional [u'astropy_time', u'datetime', u'jyear_str',
>>> u'iso', u'isot', u'yday', u'byear_str']
>>> 
>>> this came from:
>>> 
>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>>> in _get_time_fmt(self, val, val2, format, scale)
>>> --> 281             raise ValueError('Input values did not match
>>> {0}'.format(err_msg))
>>> 
>>> 
>>> which came from
>>> 
>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>>> in _init_from_vals(self, val, val2, format, scale, copy)
>>> --> 241         self._time = self._get_time_fmt(val, val2, format, scale)
>>> 
>>> 
>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>>> in __init__(self, val, val2, format, scale, precision, in_subfmt,
>>> out_subfmt, location, copy)
>>> --> 199             self._init_from_vals(val, val2, format, scale, copy)
>>> 
>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/coordinates/earth_orientation.py
>>> in <module>()
>>> ---> 19 jd1950 = Time('B1950', scale='tai').jd
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From adam.g.ginsburg at gmail.com  Wed Jul  8 13:57:41 2015
From: adam.g.ginsburg at gmail.com (Adam Ginsburg)
Date: Wed, 8 Jul 2015 19:57:41 +0200
Subject: [AstroPy] astroquery broken after update?
In-Reply-To: <6A9CBAA0-279C-4A6A-B574-7DA187106738@ucsc.edu>
References: <559D1A08.1000400@astro.umd.edu>
	<CAEBNSwbHdoi-Ebmr6SQxePTaQtzbL3mu_VPxpzeYWBsB+hUMhA@mail.gmail.com>
	<559D4DFA.7030603@astro.umd.edu>
	<6A9CBAA0-279C-4A6A-B574-7DA187106738@ucsc.edu>
Message-ID: <CAEBNSwZtbFRAuOw24s9cqEPsjAKyVP9FyES3KdFScMcrEsoDeg@mail.gmail.com>

Hi Alexa & Peter,
     This is good to know - it may mean that astroquery isn't
specifying the correct version of astropy to depend on.  Is the 'pip'
you've used to install astroquery the pip from anaconda?

On Wed, Jul 8, 2015 at 7:38 PM, Alexa Villaume <avillaum at ucsc.edu> wrote:
> Hi Peter,
>
> I had the same problem where astroquery wasn?t importing on the anaconda based python package. I installed astroquery from the github repo and so my anaconda installation didn?t ?know? about astroquery. To fix this, I made a symlink to astroquery in my anaconda directory. In your anaconda directory you can try,
>
> ln -s <path to astroquery> astroquery.
>
> Alexa
>
> On Jul 8, 2015, at 9:21 AM, Peter Teuben <teuben at astro.umd.edu> wrote:
>
>> It was happening for most (all?) astroquery.<name> modules
>>
>> Following your other suggestion, the astropy.units works,
>> but the astropy.coordinates does give exactly this error!!!
>>
>> Just "import astropy"  works fine.
>>
>>
>>
>>
>> On 07/08/2015 09:29 AM, Adam Ginsburg wrote:
>>> It looks like this is happening just when you import astropy; can you
>>> still import astropy.units and astropy.coordinates?  If not, the
>>> problem lies there.  If this is really just in astroquery, I'm not
>>> sure what's going on - does it happen for other astroquery submodules?
>>>
>>> On Wed, Jul 8, 2015 at 2:39 PM, Peter Teuben <teuben at astro.umd.edu> wrote:
>>>> This problem may be peculiar to my set up, but it's working on my laptop,
>>>> but on an anaconda based system where I simply did a "pip install
>>>> astroquery"
>>>> (which has worked for other things in this way), i can't import any
>>>> submodules
>>>> under astroquery anymore, viz.
>>>>
>>>>    import astroquery.simbad
>>>>
>>>> would result in the following error, and wondering if this can be fixed
>>>> in some
>>>> way or another....
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ValueError: Input values did not match any of the formats where the
>>>> format keyword is optional [u'astropy_time', u'datetime', u'jyear_str',
>>>> u'iso', u'isot', u'yday', u'byear_str']
>>>>
>>>> this came from:
>>>>
>>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>>>> in _get_time_fmt(self, val, val2, format, scale)
>>>> --> 281             raise ValueError('Input values did not match
>>>> {0}'.format(err_msg))
>>>>
>>>>
>>>> which came from
>>>>
>>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>>>> in _init_from_vals(self, val, val2, format, scale, copy)
>>>> --> 241         self._time = self._get_time_fmt(val, val2, format, scale)
>>>>
>>>>
>>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/time/core.pyc
>>>> in __init__(self, val, val2, format, scale, precision, in_subfmt,
>>>> out_subfmt, location, copy)
>>>> --> 199             self._init_from_vals(val, val2, format, scale, copy)
>>>>
>>>> /astromake/opt/python/anaconda/lib/python2.7/site-packages/astropy/coordinates/earth_orientation.py
>>>> in <module>()
>>>> ---> 19 jd1950 = Time('B1950', scale='tai').jd
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Adam Ginsburg
Fellow, European Southern Observatory
http://www.adamgginsburg.com/


From brinkmann at mpia.de  Thu Jul  9 08:47:35 2015
From: brinkmann at mpia.de (Steffen Brinkmann)
Date: Thu, 09 Jul 2015 14:47:35 +0200
Subject: [AstroPy] ImportError: cannot import name _compiler
Message-ID: <559E6D67.60205@mpia.de>

Hello,

I just installed locally with

$ python setup.py install --user

Now when I import astropy, I get


>>>
In [1]: import astropy
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-d192094ef7da> in <module>()
----> 1 import astropy

/disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in <module>()
     323     log = _init_log()
     324
--> 325     _initialize_astropy()
     326
     327     from .utils.misc import find_api_page

/disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in 
_initialize_astropy()
     236
     237     try:
--> 238         from .utils import _compiler
     239     except ImportError:
     240         if is_astropy_source_dir:

ImportError: cannot import name _compiler

<<<

what did I miss?

Cheers, Steffen


From embray at stsci.edu  Thu Jul  9 10:50:03 2015
From: embray at stsci.edu (Erik Bray)
Date: Thu, 9 Jul 2015 10:50:03 -0400
Subject: [AstroPy] ImportError: cannot import name _compiler
In-Reply-To: <559E6D67.60205@mpia.de>
References: <559E6D67.60205@mpia.de>
Message-ID: <559E8A1B.4060202@stsci.edu>

It looks like you're still in the directory you unpacked the astropy source 
into.  Python adds the current working directory to your import path by default, 
so if you're still in the source tree it will try to import from there, rather 
than the version you installed. (Still odd since it should still work even then.)

Incidentally, unless you have a specific reason not to, you should use pip to 
install Python packages:

pip install --user astropy

Erik

On 07/09/2015 08:47 AM, Steffen Brinkmann wrote:
> Hello,
>
> I just installed locally with
>
> $ python setup.py install --user
>
> Now when I import astropy, I get
>
>
>>>>
> In [1]: import astropy
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call last)
> <ipython-input-1-d192094ef7da> in <module>()
> ----> 1 import astropy
>
> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in <module>()
>       323     log = _init_log()
>       324
> --> 325     _initialize_astropy()
>       326
>       327     from .utils.misc import find_api_page
>
> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in
> _initialize_astropy()
>       236
>       237     try:
> --> 238         from .utils import _compiler
>       239     except ImportError:
>       240         if is_astropy_source_dir:
>
> ImportError: cannot import name _compiler



From embray at stsci.edu  Thu Jul  9 10:57:50 2015
From: embray at stsci.edu (Erik Bray)
Date: Thu, 9 Jul 2015 10:57:50 -0400
Subject: [AstroPy] ImportError: cannot import name _compiler
In-Reply-To: <559E8A1B.4060202@stsci.edu>
References: <559E6D67.60205@mpia.de> <559E8A1B.4060202@stsci.edu>
Message-ID: <559E8BEE.2090303@stsci.edu>

On 07/09/2015 10:50 AM, Erik Bray wrote:
> It looks like you're still in the directory you unpacked the astropy source
> into.  Python adds the current working directory to your import path by default,
> so if you're still in the source tree it will try to import from there, rather
> than the version you installed. (Still odd since it should still work even then.)

Ah, I see now why it didn't work for you.  The mechanism that enables automatic 
in-place build for import from the source code only works in a git clone, but 
not from a source tarball.  That should probably be fixed.  (Still, just change 
directories out of the unpacked source and you should be fine.)

Erik

> Incidentally, unless you have a specific reason not to, you should use pip to
> install Python packages:
>
> pip install --user astropy
>
> Erik
>
> On 07/09/2015 08:47 AM, Steffen Brinkmann wrote:
>> Hello,
>>
>> I just installed locally with
>>
>> $ python setup.py install --user
>>
>> Now when I import astropy, I get
>>
>>
>>>>>
>> In [1]: import astropy
>> ---------------------------------------------------------------------------
>> ImportError                               Traceback (most recent call last)
>> <ipython-input-1-d192094ef7da> in <module>()
>> ----> 1 import astropy
>>
>> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in <module>()
>>        323     log = _init_log()
>>        324
>> --> 325     _initialize_astropy()
>>        326
>>        327     from .utils.misc import find_api_page
>>
>> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in
>> _initialize_astropy()
>>        236
>>        237     try:
>> --> 238         from .utils import _compiler
>>        239     except ImportError:
>>        240         if is_astropy_source_dir:
>>
>> ImportError: cannot import name _compiler
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From brinkmann at mpia.de  Thu Jul  9 12:07:45 2015
From: brinkmann at mpia.de (Steffen Brinkmann)
Date: Thu, 09 Jul 2015 18:07:45 +0200
Subject: [AstroPy] ImportError: cannot import name _compiler
In-Reply-To: <559E8BEE.2090303@stsci.edu>
References: <559E6D67.60205@mpia.de> <559E8A1B.4060202@stsci.edu>
	<559E8BEE.2090303@stsci.edu>
Message-ID: <559E9C51.7090100@mpia.de>

Hello Erik,

thank you, changing the directory did the trick.

Anyways, I would not have worked in the astrpy directory, but that's 
where you try if the installation worked, right?

Thanks a lot,

Steffen

On 09.07.2015 16:57, Erik Bray wrote:
> On 07/09/2015 10:50 AM, Erik Bray wrote:
>> It looks like you're still in the directory you unpacked the astropy source
>> into.  Python adds the current working directory to your import path by default,
>> so if you're still in the source tree it will try to import from there, rather
>> than the version you installed. (Still odd since it should still work even then.)
> Ah, I see now why it didn't work for you.  The mechanism that enables automatic
> in-place build for import from the source code only works in a git clone, but
> not from a source tarball.  That should probably be fixed.  (Still, just change
> directories out of the unpacked source and you should be fine.)
>
> Erik
>
>> Incidentally, unless you have a specific reason not to, you should use pip to
>> install Python packages:
>>
>> pip install --user astropy
>>
>> Erik
>>
>> On 07/09/2015 08:47 AM, Steffen Brinkmann wrote:
>>> Hello,
>>>
>>> I just installed locally with
>>>
>>> $ python setup.py install --user
>>>
>>> Now when I import astropy, I get
>>>
>>>
>>> In [1]: import astropy
>>> ---------------------------------------------------------------------------
>>> ImportError                               Traceback (most recent call last)
>>> <ipython-input-1-d192094ef7da>  in<module>()
>>> ---->  1 import astropy
>>>
>>> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in<module>()
>>>         323     log = _init_log()
>>>         324
>>> -->  325     _initialize_astropy()
>>>         326
>>>         327     from .utils.misc import find_api_page
>>>
>>> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in
>>> _initialize_astropy()
>>>         236
>>>         237     try:
>>> -->  238         from .utils import _compiler
>>>         239     except ImportError:
>>>         240         if is_astropy_source_dir:
>>>
>>> ImportError: cannot import name _compiler
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From deichaaron at gmail.com  Fri Jul 10 17:29:34 2015
From: deichaaron at gmail.com (Aaron Deich)
Date: Fri, 10 Jul 2015 14:29:34 -0700
Subject: [AstroPy] Question about astropy coordinate-matching behavior
Message-ID: <CAKeeFWNoB9hHr5mpYoXL1+-zhEwshqm6BHAAoEKrYdniD7nU7g@mail.gmail.com>

Hello,

I've been trying to match two sets of objects (each containing ~100,000) on
RA & DEC using astropy.coordinates.match_coordinates_sky(matchcoord,
catalogcoord)
<https://astropy.readthedocs.org/en/stable/coordinates/matchsep.html#astropy-coordinates-matching>.
Here I've arbitrarily set the first set to matchcoord and the second set to
catalogcoord as they're of nearly the same size.

At first glance, it's working pretty well; about 50% of objects in the
first set have correct, close matches with objects in the second set (my
criterion for "close matches" is just "less than 10 arcsec").

However, I know that for my datasets I *should* be getting around 80%
"close matches". On inspecting my match data, I find that
match_coordinates_sky() is for some reason creating many false negatives --
i.e. an object which is actually in both sets is linked incorrectly to some
distant object, tens of degrees away.

The way I've verified that the false negatives are in fact false negatives
is by passing them again through match_coordinates_sky(), but all alone,
instead of as part of the entire set of 100,000 objects. When passed alone,
the coordinate-matching works correctly and in both directions.

Any ideas about why this might be? Could the kdtree (scipy.spatial.cKDTree
<http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.spatial.cKDTree.html>
 (source
<https://github.com/scipy/scipy/blob/master/scipy/spatial/ckdtree/ckdtree.pyx>))
only allow 1 "closest match" pointer to each catalog object?

Perhaps I may have to resort to calling match_coordinates_sky 100,000 times
sequentially (once for each object in matchcoord)?



Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150710/db7c5fc1/attachment.html>

From shupe at ipac.caltech.edu  Fri Jul 10 19:36:22 2015
From: shupe at ipac.caltech.edu (David Shupe)
Date: Fri, 10 Jul 2015 16:36:22 -0700
Subject: [AstroPy] Question about astropy coordinate-matching behavior
In-Reply-To: <CAKeeFWNoB9hHr5mpYoXL1+-zhEwshqm6BHAAoEKrYdniD7nU7g@mail.gmail.com>
References: <CAKeeFWNoB9hHr5mpYoXL1+-zhEwshqm6BHAAoEKrYdniD7nU7g@mail.gmail.com>
Message-ID: <6604064C-1AF4-47BE-B0DA-1B0EFD1117BC@ipac.caltech.edu>

Aaron,

For this kind of catalog matching, I use catalogcoord.search_around_sky(matchcoord, 10*u.arcsec). 

I believe this does the matching that you want. I have mistakenly tried match_coordinates_sky first and tripped over the same sorts of issues that you encountered.

Regards,
David

> On Jul 10, 2015, at 2:29 PM, Aaron Deich <deichaaron at gmail.com> wrote:
> 
> Hello,
> 
> I've been trying to match two sets of objects (each containing ~100,000) on RA & DEC using astropy.coordinates.match_coo <http://astropy.coordinates.match_coo/>rdinates_sky(matchcoord, catalogcoord) <https://astropy.readthedocs.org/en/stable/coordinates/matchsep.html#astropy-coordinates-matching>. Here I've arbitrarily set the first set to matchcoord and the second set to catalogcoord as they're of nearly the same size.
> 
> At first glance, it's working pretty well; about 50% of objects in the first set have correct, close matches with objects in the second set (my criterion for "close matches" is just "less than 10 arcsec").  
> 
> However, I know that for my datasets I should be getting around 80% "close matches". On inspecting my match data, I find that match_coordinates_sky() is for some reason creating many false negatives -- i.e. an object which is actually in both sets is linked incorrectly to some distant object, tens of degrees away. 
> 
> The way I've verified that the false negatives are in fact false negatives is by passing them again through match_coordinates_sky(), but all alone, instead of as part of the entire set of 100,000 objects. When passed alone, the coordinate-matching works correctly and in both directions.
> 
> Any ideas about why this might be? Could the kdtree (scipy.spatial.cKDTree <http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.spatial.cKDTree.html> (source <https://github.com/scipy/scipy/blob/master/scipy/spatial/ckdtree/ckdtree.pyx>)) only allow 1 "closest match" pointer to each catalog object? 
> 
> Perhaps I may have to resort to calling match_coordinates_sky 100,000 times sequentially (once for each object in matchcoord)?
> 
> 
> 
> Thanks,
> Aaron
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

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

From embray at stsci.edu  Mon Jul 13 09:59:00 2015
From: embray at stsci.edu (Erik Bray)
Date: Mon, 13 Jul 2015 09:59:00 -0400
Subject: [AstroPy] ImportError: cannot import name _compiler
In-Reply-To: <559E9C51.7090100@mpia.de>
References: <559E6D67.60205@mpia.de>
	<559E8A1B.4060202@stsci.edu>	<559E8BEE.2090303@stsci.edu>
	<559E9C51.7090100@mpia.de>
Message-ID: <55A3C424.2020407@stsci.edu>

On 07/09/2015 12:07 PM, Steffen Brinkmann wrote:
> Hello Erik,
>
> thank you, changing the directory did the trick.
>
> Anyways, I would not have worked in the astrpy directory, but that's
> where you try if the installation worked, right?

Not so, considering the way most Python software distributions are laid out 
these days, which is:

project_name/
     |
     |- package_name/
     |
     |- etc...

such that when you unpack a source tarball and cd into the directory extracted 
from it, the Python package ("package_name/") above is immediately on your 
current working directory.  Since most Python installs are configured to import 
from your cwd, you will never import the package you actually installed if you 
do it from within the source tree.

Astropy *will* normally work if you do that, but you're technically not testing 
your installed copy.  Same goes for most other Python packages (Numpy won't even 
let you import from within the source tree, for example, to prevent confusion).

Erik

> On 09.07.2015 16:57, Erik Bray wrote:
>> On 07/09/2015 10:50 AM, Erik Bray wrote:
>>> It looks like you're still in the directory you unpacked the astropy source
>>> into.  Python adds the current working directory to your import path by default,
>>> so if you're still in the source tree it will try to import from there, rather
>>> than the version you installed. (Still odd since it should still work even then.)
>> Ah, I see now why it didn't work for you.  The mechanism that enables automatic
>> in-place build for import from the source code only works in a git clone, but
>> not from a source tarball.  That should probably be fixed.  (Still, just change
>> directories out of the unpacked source and you should be fine.)
>>
>> Erik
>>
>>> Incidentally, unless you have a specific reason not to, you should use pip to
>>> install Python packages:
>>>
>>> pip install --user astropy
>>>
>>> Erik
>>>
>>> On 07/09/2015 08:47 AM, Steffen Brinkmann wrote:
>>>> Hello,
>>>>
>>>> I just installed locally with
>>>>
>>>> $ python setup.py install --user
>>>>
>>>> Now when I import astropy, I get
>>>>
>>>>
>>>> In [1]: import astropy
>>>> ---------------------------------------------------------------------------
>>>> ImportError                               Traceback (most recent call last)
>>>> <ipython-input-1-d192094ef7da>  in<module>()
>>>> ---->  1 import astropy
>>>>
>>>> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in<module>()
>>>>          323     log = _init_log()
>>>>          324
>>>> -->  325     _initialize_astropy()
>>>>          326
>>>>          327     from .utils.misc import find_api_page
>>>>
>>>> /disk1/brinkmann/code/astropy-1.0.3/astropy/__init__.py in
>>>> _initialize_astropy()
>>>>          236
>>>>          237     try:
>>>> -->  238         from .utils import _compiler
>>>>          239     except ImportError:
>>>>          240         if is_astropy_source_dir:
>>>>
>>>> ImportError: cannot import name _compiler
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From thomas.robitaille at gmail.com  Wed Jul 15 09:20:25 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Wed, 15 Jul 2015 21:20:25 +0800
Subject: [AstroPy] Python in Astronomy 2015 proceedings
Message-ID: <CAGMHX_3kuqrEkeOkKKii+BijwhXzDf9+QcKbVMJ3GvrF1CDecw@mail.gmail.com>

Hi everyone,

Back in April, we held a workshop entitled 'Python in Astronomy' at
the Lorentz center in Leiden, and due to space constraints, a number
of people were not able to attend the workshop, but we promised that
we would make available as much as possible from the meeting.

We are now happy to announce the availability of the 'proceedings'
for the Python in Astronomy 2015 workshop, which you can find on the
following page:

http://python-in-astronomy.github.io

This includes a document summarizing all the unconference sessions,
videos of most of the talks, the slides for many of the talks, a
collection of links shared during the conference, links to blog posts,
photos, and a Twitter archive.

Note that the unproceedings document as well as the talk slides are
both citable, since they are available on Zenodo, so they have a DOI
(you can find BibTex entries on the Zenodo pages).

Let us know if you have any questions about any of the proceedings!

The organizing committee:

Pauline Barmby
Eric Jeschke
Sarah Kendrew
Stuart Mumford
Magnus Persson
Thomas Robitaille


From erik.tollerud at gmail.com  Wed Jul 15 14:46:45 2015
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 15 Jul 2015 14:46:45 -0400
Subject: [AstroPy] Fwd: [matplotlib-devel] Call for new style defaults
In-Reply-To: <CAA48SF-DNBz3G5F5YEYSEWhm+aZme3sg8W9BSkL24cCjsZsmsw@mail.gmail.com>
References: <CAA48SF-DNBz3G5F5YEYSEWhm+aZme3sg8W9BSkL24cCjsZsmsw@mail.gmail.com>
Message-ID: <CAARXUwUA7-Ode8S+vH6OtLL7d+LxWVVMxbxiNKiWw0m9g6u=JA@mail.gmail.com>

Hello all,

I thought the message below from the matplotlib mailing lists might be of
interest to those in our community with strong opinions about plotting
styles.  In the next few months there will be a 2.0 release of matplotlib,
which will primarily feature new defaults plotting styles (including a new
colormap).  The window for community input on these defaults is 1 month, so
if you want a say in the new defaults, now's the time, or forever hold your
peace (at least until 3.0).


---------- Forwarded message ----------
From: Thomas Caswell <tcaswell at gmail.com>
Date: Sun, Jul 12, 2015 at 12:11 PM
Subject: [matplotlib-devel] Call for new style defaults
To: "matplotlib-devel at lists.sourceforge.net" <
matplotlib-devel at lists.sourceforge.net>, "
matplotlib-announce at lists.sourceforge.net" <
matplotlib-announce at lists.sourceforge.net>, Matplotlib Users <
matplotlib-users at lists.sourceforge.net>


Hello all,

Following much discussion, we are changing the default color map and styles
in the upcoming 2.0 release!

The new default color map will be 'viridis' (aka option D).  I recommend
everyone watch Nathaniel Smith and Ste?fan van der Walt's talk from
SciPy2015 introducing the new color map and providing an introduction to
the math of color perception: https://www.youtube.com/watch?v=xAoljeRJ3lU

We are soliciting proposals to change any and all other visual defaults
(including adding new rcParams as needed).

If you have a proposal please create a PR or issue with the changes to
`rcsetup.py` and `matplotlibrc.template` implementing the changes by August
9, 2015 (1 month from now). Do not worry about updating any failing tests.

At the end, Micheal Droettboom and I will decide on the new defaults.

A 'classic' style will be provided so reverting to the current default
values will be a single line of python (`mpl.style.use('classic')`).

Please distribute this as widely as possible.  We only want to do this once
and want to get feedback from as many users as possible.

Thomas Caswell

PS jet is harmful to you and those around you

See https://github.com/matplotlib/matplotlib/pull/4622 for an example
proposal PR.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 
Erik T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150715/a089ab97/attachment.html>

From aldcroft at head.cfa.harvard.edu  Thu Jul 23 13:00:18 2015
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Thu, 23 Jul 2015 13:00:18 -0400
Subject: [AstroPy] New astropython.org site preview
Message-ID: <CAMtEP6weTcjeEHuWgo96Ry89cKOqE59hG+on0ikBjA35D5qPDA@mail.gmail.com>

This summer we have been fortunate to have a very talented Google Summer of
Code student, Aman Jhunjhunwala, working to create a brand new
astropython.org site from scratch.  In addition to writing all the code,
Aman has also brought a fresh design look and many cool ideas to the
project.

The primary driver is to make a modern site that would engage the community
and succeed in having a broad base of contributors to the site content.  To
that end the site allows contributions from anyone who authenticates via
Github, Google, or Facebook.  By default all such content will be moderated
before appearing on the live site, but there is also a category for trusted
users that can post directly.  During the preview phase moderation is
disabled, so you can post at will!

The preview version is available at:

http://amanjhunjhunwala.pythonanywhere.com/?

At this time we are opening the site for a preview in order to get feedback
from the AstroPython community regarding the site including:
Overall concept, in particular whether the site design will be conducive to
broad base of contributors.  Would you want to post?
Are the authentication options obvious and sufficient?
General site organization and ease of navigating
How easily can you find information?
Visual design and aesthetics
Other features, e.g. a Q&A forum?
Accessibility
Ease of posting
Bugs
Code review (https://github.com/x-calibre/astropython)
Security
We highly encourage you to post content in any / all of the categories.
You can either try to play nice and use things as we intended, or do stress
testing and try to break it.  All posts will show up immediately, so please
do act responsibly in terms of the actual content you post.

As you find issues or have comments, please first check the site github
repo to see if it is already known:

   https://github.com/x-calibre/astropython/issues

Ideally put your comments into github.  For most of the broad review
categories above I have already created a placeholder issue starting with
[DISCUSS].  Also, if you'd rather not use github then just send to me
directly at taldcroft at gmail.com.

Best regards,

  Tom Aldcroft,
  Aman Jhunjhunwala,
  Jean Connelly, and
  Tom Robitaille
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150723/7f924cac/attachment.html>

From jzuhone at gmail.com  Fri Jul 24 16:01:33 2015
From: jzuhone at gmail.com (John ZuHone)
Date: Fri, 24 Jul 2015 16:01:33 -0400
Subject: [AstroPy] ANN: yt-3.2 released
Message-ID: <2C4552F9-F7EB-4CC9-848C-0E6F2DCC60E1@gmail.com>

We are proud to announce the release of yt 3.2!

yt (http://yt-project.org <http://yt-project.org/>) is an open source, community-developed toolkit for analysis and visualization of volumetric data of all types, with a particular emphasis on astrophysical simulations and nuclear engineering simulations.

Major enhancements
Particle-Only Plots - a series of new plotting functions for visualizing particle data.  See here <http://yt-project.org/docs/dev/visualizing/plots.html#particle-plots> for more information.
Late-stage beta support for Python 3 - unit tests and answer tests pass for all the major frontends under python 3.4, and yt should now be mostly if not fully usable.  Because many of the yt developers are still on Python 2 at this point, this should be considered a ?late stage beta? as there may be remaining issues yet to be identified or worked out.
Now supporting Gadget Friend-of-Friends/Subfind catalogs - see here <http://yt-project.org/docs/dev/examining/loading_data.html#halo-catalog-data> to learn how to load halo catalogs as regular yt datasets.
Custom colormaps can now be easily defined and added - see here <http://yt-project.org/docs/dev/visualizing/colormaps/index.html> to learn how!
Now supporting Fargo3D data
Performance improvements throughout the code base for memory and speed

Minor enhancements
Various updates to the following frontends: ART, Athena, Castro, Chombo, Gadget, GDF, Maestro, Pluto, RAMSES, Rockstar, SDF, Tipsy
Numerous documentation updates
Generic hexahedral mesh pixelizer
Adding annotate_ray() callback for plots
AbsorptionSpectrum returned to full functionality and now using faster SciPy Voigt profile
Add a color_field argument to annotate_streamline
Smoothing lengths auto-calculated for Tipsy Datasets
Adding SimulationTimeSeries support for Gadget and OWLS.
Generalizing derived quantity outputs to all be YTArrays or lists of YTArrays as appropriate
Star analysis returned to full functionality
FITS image writing refactor
Adding gradient fields on the fly
Adding support for Gadget Nx4 metallicity fields
Updating value of solar metal mass fraction to be consistent with Cloudy.
Gadget raw binary snapshot handling & non-cosmological simulation units
Adding support for LightRay class to work with Gadget+Tipsy
Add support for subclasses of frontends
Dependencies updated
Serialization for projections using minimal representation
Adding Grid visitors in Cython
Improved semantics for derived field units
Add a yaw() method for the PerspectiveCamera + switch back to LHS
Adding annotate_clear() function to remove previous callbacks from a plot
Added documentation for hexahedral mesh on website
Speed up nearest neighbor evaluation
Add a convenience method to create deposited particle fields
UI and docs updates for 3D streamlines
Ensure particle fields are tested in the field unit tests
Allow a suffix to be specified to save()
Add profiling using airspeed velocity
Various plotting enhancements and bugfixes
Use hglib to update
Various minor updates to halo_analysis toolkit
Docker-based tests for install_script.sh
Adding support for single and non-cosmological datasets to LightRay
Adding the Pascal unit
Add weight_field to PPVCube
FITS reader: allow HDU in auxiliary
Fixing electromagnetic units
Specific Angular Momentum [xyz] computed relative to a normal vector

Bugfixes
Adding ability to create union fields from alias fields
Small fix to allow enzo AP datasets to load in parallel when no APs present
Use proper cell dimension in gradient function.
Minor memory optimization for smoothed particle fields
Fix thermal_energy for Enzo HydroMethod==6
Make sure annotate_particles handles unitful widths properly
Improvements for add_particle_filter and particle_filter
Specify registry in off_axis_projection's image finalization
Apply fix for particle momentum units to the boxlib frontend
Avoid traceback in "yt version" when python-hglib is not installed
Expose no_ghost from export_sketchfab down to _extract_isocontours_from_grid
Fix broken magnetic_unit attribute
Fixing an off-by-one error in the set x/y lim methods for profile plots
Providing better error messages to PlotWindow callbacks
Updating annotate_timestamp to avoid auto-override
Updating callbacks to consistently define coordinate system
Fixing species fields for OWLS and tipsy
Fix extrapolation for vertex-centered data
Fix periodicity check in FRBs
Rewrote project_to_plane() in PerspectiveCamera for draw_domain()
Fix intermittent failure in test_add_deposited_particle_field
Improve minorticks for a symlog plot with one-sided data
Fix smoothed covering grid cell computation
Absorption spectrum generator now 3.0 compliant
Fix off-by-one-or-more in particle smallest dx
Fix dimensionality mismatch error in covering grid
Fix curvature term in cosmology calculator
Fix geographic axes and pixelization
Ensure axes aspect ratios respect the user-selected plot aspect ratio
Avoid clobbering field_map when calling profile.add_fields
Fixing the arbitrary grid deposit code
Fix spherical plotting centering
Make the behavior of to_frb consistent with the docstring
Ensure projected units are initialized when there are no chunks.
Removing "field already exists" warnings from the Owls and Gadget frontends
Various photon simulator bugs
Fixed use of LaTeX math mode
Fix upload_image
Enforce plot width in CSS when displayed in a notebook
Fix cStringIO.StringIO -> cStringIO in png_writer
Add some input sanitizing and error checking to covering_grid initializer
Fix for geographic plotting
Use the correct filename template for single-file OWLS datasets.
Fix Enzo IO performance for 32 bit datasets
Adding a number density field for Enzo MultiSpecies=0 datasets.
Fix RAMSES block ordering
Fix ART star particle masses to correctly reflect current and initial mass
Updating ragged array tests for NumPy 1.9.1
Force returning lists for HDF5FileHandler

Coming Soon!

The next major release of yt will be version 3.3, which is slated to include an overhaul of the volume rendering system and support for analyzing and visualizing unstructured mesh data.

Standard Installation Methods

As with previous releases, you can install yt from source using one of the following methods.

1) From the install script (http://yt-project.org/#getyt <http://yt-project.org/#getyt> ):

Note, many of the dependencies have been updated since version 3.1.  If you previously installed yt from the install script, it is advised that you re-install yt from scratch.

# Installation

$ wget http://bitbucket.org/yt_analysis/yt/raw/stable/doc/install_script.sh <http://bitbucket.org/yt_analysis/yt/raw/stable/doc/install_script.sh>
$ bash install_script.sh

# Update

$ yt update

2) From pip (source or binary wheel, see below for more details):

# Installation

$ pip install yt

# Update

$ pip install -U yt

3) From the Anaconda Python Distribution (https://store.continuum.io/cshop/anaconda/ <https://store.continuum.io/cshop/anaconda/>):

# Installation

$ conda install yt

# Update

$ conda update yt

Note that it might take a day or two for the conda package to be updated.

If you are on the ?stable? branch, updating will bring you from yt 3.1 to 3.2, incorporating all
changes since 3.1, whereas if you are on the ?dev? or ?yt? branch, only the changes since
your last update should be incorporated.

Installing Binary Packages via pip

New to this release is the ability to install binary packages (?wheels?) using pip on Windows and Mac OS X (64-bit only for both). This has the advantage of not needing to install yt from source using a proper compiler setup, which has caused occasional problems on both of these platforms and prevented us from installing yt easily on other Python distributions.

We have so far been able to install and run the binary distribution via pip on the following platforms and Python stacks:

Note that it might take a day or two for the pip wheels to be updated.

Windows x86_64:

Enthought Canopy Python (https://www.enthought.com/products/canopy/ <https://www.enthought.com/products/canopy/>)
WinPython (http://winpython.sourceforge.net/ <http://winpython.sourceforge.net/>)

Mac OS X x86_64:

Enthought Canopy Python (https://www.enthought.com/products/canopy/ <https://www.enthought.com/products/canopy/>)
Homebrew Python (http://brew.sh/ <http://brew.sh/>)
Python.org <http://python.org/> Python
Mac OS X?s system Python
MacPorts Python (https://www.macports.org/ <https://www.macports.org/>)

This is somewhat experimental, so other distributions may work (or not), please submit bug reports or successes to the mailing list or to the Bitbucket issues page (http://bitbucket.org/yt_analysis/yt/issues <http://bitbucket.org/yt_analysis/yt/issues>).

All distributions are recommended to be Python v. 2.7, although with yt 3.2 there is late-stage beta support for Python 3.4. The requirements for installing yt via this method are the same as from source:

NumPy
h5py
HDF5
SymPy
Matplotlib
IPython (not required, but strongly recommended)

To install a new version of yt on one of these platforms, simply do

$ pip install yt

and you should get the binary distribution automatically. Also, if your python installation is system-wide (e.g., the Mac system Python) you might need to run pip with administrator privileges.

For more information, including more installation instructions, links to community resources, and information on contributing to yt?s development, please see the yt homepage at http://yt-project.org <http://yt-project.org/> and the documentation for yt-3.2 at http://yt-project.org/docs/3.2 <http://yt-project.org/docs/3.2>.

yt is the product of a large community of developers and users and we are extraordinarily grateful for and proud of their contributions. Please forward this announcement on to any interested parties.

As always, if you have any questions, concerns, or run into any trouble updating please don't hesitate to send a message to the mailing list or stop by our IRC channel.

All the best,
The yt development team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20150724/7b011fb6/attachment.html>

From arckest at gmail.com  Mon Jul 27 09:32:03 2015
From: arckest at gmail.com (Ilya Yakunin)
Date: Mon, 27 Jul 2015 16:32:03 +0300
Subject: [AstroPy] Visibility plot with the list of coords
Message-ID: <CAFk4aTQM7_J04yF_Me5dVtB9OF_hm7KuguLXobB_Rvb75JTXfA@mail.gmail.com>

Hi!

I'd like to plot observability curves for list of the objects of my
interest. Following this example
https://astropy.readthedocs.org/en/v1.0.3/coordinates/observing-example.html
I created coords list using SkyCoord:

>>>coords = SkyCoord(data[:,2], data[:,3], unit=(u.deg,u.deg))

which contains more than 300 objects.

And then, when I'm trying to transform equatorial coords to horizontal I get:

>>>from astropy.coordinates import get_sun
>>>delta_midnight = np.linspace(-12, 12, 1000)*u.hour
>>>times = midnight + delta_midnight
>>>altazframe = AltAz(obstime=times, location=bta_location)
>>>sunaltazs = get_sun(times).transform_to(altazframe)
>>>coordaltazs = coords.transform_to(altazframe)

Traceback (most recent call last):
  File "testing", line 38, in <module>
    corraaltazs = coords.transform_to(altazframe)
  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/sky_coordinate.py",
line 348, in transform_to
    new_coord = trans(self.frame, generic_frame)
  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/transformations.py",
line 920, in __call__
    curr_coord = t(curr_coord, curr_toframe)
  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/transformations.py",
line 708, in __call__
    res = self.func(fromcoord, toframe)
  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/builtin_frames/icrs_cirs_transforms.py",
line 41, in icrs_to_cirs
    cirs_ra, cirs_dec = erfa.atciq(i_ra, i_dec, 0, 0, px, 0, astrom)
  File "/usr/lib/python2.7/dist-packages/astropy/_erfa/core.py", line
22306, in atciq
    broadcast = numpy.broadcast(numpy.int32(0.0), numpy.int32(0.0),
rc_in, dc_in, pr_in, pd_in, px_in, rv_in, astrom_in)
ValueError: shape mismatch: objects cannot be broadcast to a single shape

But when I use a single string from coords list (say, coords[20] )
everything goes well.
Looks like transform_to() waits for a single SkyCoord object but I
have a list. Is there any way to convert and plot several objects on
one plot?

Thanks for the any help!

-- 
Cheers,
Ilya


From evert.rol at gmail.com  Mon Jul 27 16:16:31 2015
From: evert.rol at gmail.com (Evert Rol)
Date: Mon, 27 Jul 2015 21:16:31 +0100
Subject: [AstroPy] Visibility plot with the list of coords
In-Reply-To: <CAFk4aTQM7_J04yF_Me5dVtB9OF_hm7KuguLXobB_Rvb75JTXfA@mail.gmail.com>
References: <CAFk4aTQM7_J04yF_Me5dVtB9OF_hm7KuguLXobB_Rvb75JTXfA@mail.gmail.com>
Message-ID: <410AE948-5052-44B8-970E-2BD501ADBF87@gmail.com>

> I'd like to plot observability curves for list of the objects of my
> interest. Following this example
> https://astropy.readthedocs.org/en/v1.0.3/coordinates/observing-example.html
> I created coords list using SkyCoord:
> 
>>>> coords = SkyCoord(data[:,2], data[:,3], unit=(u.deg,u.deg))
> 
> which contains more than 300 objects.
> 
> And then, when I'm trying to transform equatorial coords to horizontal I get:
> 
>>>> from astropy.coordinates import get_sun
>>>> delta_midnight = np.linspace(-12, 12, 1000)*u.hour
>>>> times = midnight + delta_midnight
>>>> altazframe = AltAz(obstime=times, location=bta_location)
>>>> sunaltazs = get_sun(times).transform_to(altazframe)
>>>> coordaltazs = coords.transform_to(altazframe)
> 
> Traceback (most recent call last):
>  File "testing", line 38, in <module>
>    corraaltazs = coords.transform_to(altazframe)
>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/sky_coordinate.py",
> line 348, in transform_to
>    new_coord = trans(self.frame, generic_frame)
>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/transformations.py",
> line 920, in __call__
>    curr_coord = t(curr_coord, curr_toframe)
>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/transformations.py",
> line 708, in __call__
>    res = self.func(fromcoord, toframe)
>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/builtin_frames/icrs_cirs_transforms.py",
> line 41, in icrs_to_cirs
>    cirs_ra, cirs_dec = erfa.atciq(i_ra, i_dec, 0, 0, px, 0, astrom)
>  File "/usr/lib/python2.7/dist-packages/astropy/_erfa/core.py", line
> 22306, in atciq
>    broadcast = numpy.broadcast(numpy.int32(0.0), numpy.int32(0.0),
> rc_in, dc_in, pr_in, pd_in, px_in, rv_in, astrom_in)
> ValueError: shape mismatch: objects cannot be broadcast to a single shape

I guess this has more to do with the fact that both the times (and thus, in a way, the altazframe object) and the coords are both arrays; in the example in the docs, only times is an array. 
So you?ll need to work towards getting a 2D array as output for coordaltazs in this case. Perhaps this should be done under the hood, but possibly, this is not done/built-in out of the principle of least surprise (generally, using numpy, when 1D arrays are input, a 1D array is output, not a 2D array).
What seems to work for me is adding an extra dimension to the coords array:

    >>> coordaltazs = coords[:,np.newaxis].transform_to(altazframe)

which will give you 2D arrays for coordaltazs.alt and coordaltazs.az to be plotted
(depending on the plot you want to make, you may need to loop around pyplot.scatter).



> But when I use a single string from coords list (say, coords[20] )
> everything goes well.
> Looks like transform_to() waits for a single SkyCoord object but I
> have a list. Is there any way to convert and plot several objects on
> one plot?
> 
> Thanks for the any help!
> 
> -- 
> Cheers,
> Ilya
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From arckest at gmail.com  Tue Jul 28 08:45:15 2015
From: arckest at gmail.com (Ilya Yakunin)
Date: Tue, 28 Jul 2015 15:45:15 +0300
Subject: [AstroPy] Visibility plot with the list of coords
In-Reply-To: <410AE948-5052-44B8-970E-2BD501ADBF87@gmail.com>
References: <CAFk4aTQM7_J04yF_Me5dVtB9OF_hm7KuguLXobB_Rvb75JTXfA@mail.gmail.com>
	<410AE948-5052-44B8-970E-2BD501ADBF87@gmail.com>
Message-ID: <CAFk4aTRkixM3TWTOY6nSwsZmks1t-8TzftLhBr3qSdYUzkUO+g@mail.gmail.com>

Thanks for the clarification, Evert! Adding a new axis do the trick.



2015-07-27 23:16 GMT+03:00 Evert Rol <evert.rol at gmail.com>:
>> I'd like to plot observability curves for list of the objects of my
>> interest. Following this example
>> https://astropy.readthedocs.org/en/v1.0.3/coordinates/observing-example.html
>> I created coords list using SkyCoord:
>>
>>>>> coords = SkyCoord(data[:,2], data[:,3], unit=(u.deg,u.deg))
>>
>> which contains more than 300 objects.
>>
>> And then, when I'm trying to transform equatorial coords to horizontal I get:
>>
>>>>> from astropy.coordinates import get_sun
>>>>> delta_midnight = np.linspace(-12, 12, 1000)*u.hour
>>>>> times = midnight + delta_midnight
>>>>> altazframe = AltAz(obstime=times, location=bta_location)
>>>>> sunaltazs = get_sun(times).transform_to(altazframe)
>>>>> coordaltazs = coords.transform_to(altazframe)
>>
>> Traceback (most recent call last):
>>  File "testing", line 38, in <module>
>>    corraaltazs = coords.transform_to(altazframe)
>>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/sky_coordinate.py",
>> line 348, in transform_to
>>    new_coord = trans(self.frame, generic_frame)
>>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/transformations.py",
>> line 920, in __call__
>>    curr_coord = t(curr_coord, curr_toframe)
>>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/transformations.py",
>> line 708, in __call__
>>    res = self.func(fromcoord, toframe)
>>  File "/usr/lib/python2.7/dist-packages/astropy/coordinates/builtin_frames/icrs_cirs_transforms.py",
>> line 41, in icrs_to_cirs
>>    cirs_ra, cirs_dec = erfa.atciq(i_ra, i_dec, 0, 0, px, 0, astrom)
>>  File "/usr/lib/python2.7/dist-packages/astropy/_erfa/core.py", line
>> 22306, in atciq
>>    broadcast = numpy.broadcast(numpy.int32(0.0), numpy.int32(0.0),
>> rc_in, dc_in, pr_in, pd_in, px_in, rv_in, astrom_in)
>> ValueError: shape mismatch: objects cannot be broadcast to a single shape
>
> I guess this has more to do with the fact that both the times (and thus, in a way, the altazframe object) and the coords are both arrays; in the example in the docs, only times is an array.
> So you?ll need to work towards getting a 2D array as output for coordaltazs in this case. Perhaps this should be done under the hood, but possibly, this is not done/built-in out of the principle of least surprise (generally, using numpy, when 1D arrays are input, a 1D array is output, not a 2D array).
> What seems to work for me is adding an extra dimension to the coords array:
>
>     >>> coordaltazs = coords[:,np.newaxis].transform_to(altazframe)
>
> which will give you 2D arrays for coordaltazs.alt and coordaltazs.az to be plotted
> (depending on the plot you want to make, you may need to loop around pyplot.scatter).
>
>
>
>> But when I use a single string from coords list (say, coords[20] )
>> everything goes well.
>> Looks like transform_to() waits for a single SkyCoord object but I
>> have a list. Is there any way to convert and plot several objects on
>> one plot?
>>
>> Thanks for the any help!
>>
>> --
>> Cheers,
>> Ilya
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
?????,
            ????


From johnw at lyric.com  Wed Jul 29 01:23:59 2015
From: johnw at lyric.com (John Wainwright)
Date: Tue, 28 Jul 2015 22:23:59 -0700
Subject: [AstroPy] where are the binary installers?
Message-ID: <638B17F8-632A-4B59-88C6-EF547B1C21EF@lyric.com>

Hi there.  I'd like to run Astropy on a Windows machine connected to an imaging rig but cannot find the binary installers mentioned in several places as being on the PyPi page <https://pypi.python.org/pypi/astropy/> for Astropy.  Can someone point me at the binary installers?

Thanks very much!!

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

From embray at stsci.edu  Wed Jul 29 10:33:23 2015
From: embray at stsci.edu (Erik Bray)
Date: Wed, 29 Jul 2015 10:33:23 -0400
Subject: [AstroPy] where are the binary installers?
In-Reply-To: <638B17F8-632A-4B59-88C6-EF547B1C21EF@lyric.com>
References: <638B17F8-632A-4B59-88C6-EF547B1C21EF@lyric.com>
Message-ID: <55B8E433.8080007@stsci.edu>

On 07/29/2015 01:23 AM, John Wainwright wrote:
> Hi there.  I'd like to run Astropy on a Windows machine connected to an imaging
> rig but cannot find the binary installers mentioned in several places as being
> on the PyPi page <https://pypi.python.org/pypi/astropy/> for Astropy.  Can
> someone point me at the binary installers?
>
> Thanks very much!!

Hi John,

Due to low demand I haven't been building Windows installers for the last 
several releases.  We would suggest instead using a scientific Python 
distribution that includes Numpy, Scipy, and the like already than trying to 
roll your own from binaries (which are often tied to whatever Numpy versions 
they were built with and the like, so it's difficult to cobble together 
something that resolves all the dependencies appropriately).

Erik



From stuart at cadair.com  Fri Jul 31 16:35:44 2015
From: stuart at cadair.com (Stuart Mumford)
Date: Fri, 31 Jul 2015 21:35:44 +0100
Subject: [AstroPy] [ANN] SunPy 0.6 Released
Message-ID: <55BBDC20.8090403@cadair.com>

Hello all,

I am very happy to tell you that the long in the works 0.6.0 release of
the SunPy library has arrived. This release has been 'in the oven' for
well over a year, and is full of rather major changes.


The major changes in this release are:

* Most functions throughout the SunPy code base now expect Astropy
Quantity objects, and return Astropy Quantity objects.

* Python 2.6 support has ended, we do not expect this release to
work under Python 2.6.

* Sample data has been removed from SunPy but helpers for
downloading sample data have been added to sunpy.data.

* TimeRange has a new property based API, e.g. start and end are
now properties.

* SunPy colormaps are now registered with matplotlib, allowing
their use from imshow and similar functions after the import
of sunpy.cm.

* Solar rotation calculation functionality has been added, along
with functionality to de-rotate MapCubes.


While there have been lots of changes, it is the move to Astropy Units
throughout the code base that will require most users to update their
code, if you wish to learn more about Astropy Units see:
http://docs.astropy.org/en/latest/units/


You can install this release using either pip or conda. If you have a
scientific python environment already configured, run:

pip install sunpy

or:

pip install --upgrade sunpy

if you have anaconda you need to add the sunpy and astropy channels to
your conda config:

conda config --add channels sunpy --add channels astropy

and then run:

conda install sunpy


for more information about installing sunpy see our installation
documentation: http://docs.sunpy.org/en/stable/guide/installation/index.html


This release consists of 1,341 commits from 29 different people and
13 new contributors!

The people who have contributed to this release are:


    Stuart Mumford
    Daniel Ryan
    Steven Christe
    Jack Ireland
    Brigitta Sipocz *
    Asish Panda
    Andrew Inglis
    Albert Y. Shih
    Rishabh Sharma
    David Perez-Suarez
    Rajul Srivastava
    Andrew Leonard
    Ruben De Visscher *
    Dumindu Buddhika *
    Goran Cetusic *
    Jongyeob Park *
    Chlo?? Guennou *
    Ishtyaq Habib *
    Nabil Freij
    Simon Liedtke
    Abigail Stevens *
    Alex Hamilton *
    Ambar Mehrotra *
    Erik M. Bray *
    Jaylen Wimbish *
    Juan Camilo Buitrago-Casas *
    Larry Manley
    Norbert Gyenge
    Rishabh Mishra *



Happy Pythoning,
Stuart Mumford

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xE6276769.asc
Type: application/pgp-keys
Size: 3104 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20150731/95b3e729/attachment.key>