Astropy not working...

[wpeter11]

So I can’t get astropy to work on pythonista... Whenever I run a script requiring astropy it spits out the error ‘Astropy requires NumPy version 1.13.0 or later’ yet the version of NumPy I have is 1.16.0, which I assume was later? How could I fix this?

[JonB]

What version of pythonista are you running?

3.1.1 came with numpy version 1.8.0
You cannot update numpy (if you tried to use pip to update numpy, you did not succeed)

[JonB]

You might try using an older version of astropy or else just hope the later numpy version issues don't affect the features you are using, and just override the version check.

Looks like astropy version 1.3.3 supported numpy 1.7

[wpeter11]

I’m running Pythonista 3.2 right now. I think I might just try the override... How might I go about that? I’m not terribly familiar with pythonista or really python in general...

[JonB]

import numpy
numpy.__version__

says 1.8

the astropy numpy version check happens in astropy/__init__. but you will have better luck using the older versions of astropy, if that does what you need.

[wpeter11]

Thanks so much for your replies! They help more than you know. Now, final question (I think), how would I get a specific (older) version of astropy rather than the newest? Can that be done through some pip command?

[JonB]

I'm not sure if the pythonista pip supports specific version .. try

pip install astropy==1.3.3

Alternatively, you can download from GitHub.

https://github.com/astropy/astropy/archive/7c675249.zip

Looking a little closer at astropy, it appears to require some c extension modules, which are not pythonista compatible.

So this might not work at all. You might consider running your own sagemath server on your desktop.

[Matteo]

@wpeter11 Hi, if you want to test some scripts that require astropy (or other not pure modules, but you should try to install them because I'm not sure the following procedure works for all not-pure python libraries) you can use sagemathcell, as @JonB said (but you don't need your own sagemath server on your pc), with Pythonista (sagemathcell is an online python interpreter with strong features...it is free and maintained by Andrey Novoseltsev and some other people, with machines and electricity power from some places around the world). Remember sagemathcell runs python 2.7.xx (I can't remember, but you can query the version).

Try to Execute the following code in the webbrowser, or save it as a script in Pythonista by following procedure here or by using JonB wrench version of sage_interface.

## first you need to install the lib because it is not a built-in lib in sagemathcell
!sage -pip install "--target=astropy" astropy
sys.path.append(os.getcwd() + "/astropy")


## then you can test any example: you will have an error after some calculations, I don't know why but probably it is due to python 2.7 incompatibility with last version of astropy, I'm not sure, you should do some experiments. the error is "Coordinate frame got unexpected keywords: ['pm_Beta', 'pm_Lambda_cosBeta']". Try to solve it by yourself, sorry.

##### Example from "http://docs.astropy.org/en/stable/generated/examples/coordinates/plot_sgr-coordinate-frame.html#sphx-glr-generated-examples-coordinates-plot-sgr-coordinate-frame-py"

# -*- coding: utf-8 -*-
"""
==========================================================
Create a new coordinate class (for the Sagittarius stream)
==========================================================

This document describes in detail how to subclass and define a custom spherical
coordinate frame, as discussed in :ref:`astropy-coordinates-design` and the
docstring for `~astropy.coordinates.BaseCoordinateFrame`. In this example, we
will define a coordinate system defined by the plane of orbit of the Sagittarius
Dwarf Galaxy (hereafter Sgr; as defined in Majewski et al. 2003).  The Sgr
coordinate system is often referred to in terms of two angular coordinates,
:math:`\Lambda,B`.

To do this, wee need to define a subclass of
`~astropy.coordinates.BaseCoordinateFrame` that knows the names and units of the
coordinate system angles in each of the supported representations.  In this case
we support `~astropy.coordinates.SphericalRepresentation` with "Lambda" and
"Beta". Then we have to define the transformation from this coordinate system to
some other built-in system. Here we will use Galactic coordinates, represented
by the `~astropy.coordinates.Galactic` class.

See Also
--------

* The `gala package <http://gala.adrian.pw/>`_, which defines a number of
  Astropy coordinate frames for stellar stream coordinate systems.
* Majewski et al. 2003, "A Two Micron All Sky Survey View of the Sagittarius
  Dwarf Galaxy. I. Morphology of the Sagittarius Core and Tidal Arms",
  https://arxiv.org/abs/astro-ph/0304198
* Law & Majewski 2010, "The Sagittarius Dwarf Galaxy: A Model for Evolution in a
  Triaxial Milky Way Halo", https://arxiv.org/abs/1003.1132
* David Law's Sgr info page http://www.stsci.edu/~dlaw/Sgr/

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

*By: Adrian Price-Whelan, Erik Tollerud*

*License: BSD*

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

"""

##############################################################################
# Make `print` work the same in all versions of Python, set up numpy,
# matplotlib, and use a nicer set of plot parameters:

import numpy as np
import matplotlib.pyplot as plt
from astropy.visualization import astropy_mpl_style
plt.style.use(astropy_mpl_style)


##############################################################################
# Import the packages necessary for coordinates

from astropy.coordinates import frame_transform_graph
from astropy.coordinates.matrix_utilities import rotation_matrix, matrix_product, matrix_transpose
import astropy.coordinates as coord
import astropy.units as u

##############################################################################
# The first step is to create a new class, which we'll call
# ``Sagittarius`` and make it a subclass of
# `~astropy.coordinates.BaseCoordinateFrame`:

class Sagittarius(coord.BaseCoordinateFrame):
    """
    A Heliocentric spherical coordinate system defined by the orbit
    of the Sagittarius dwarf galaxy, as described in
        http://adsabs.harvard.edu/abs/2003ApJ...599.1082M
    and further explained in
        http://www.stsci.edu/~dlaw/Sgr/.

    Parameters
    ----------
    representation : `BaseRepresentation` or None
        A representation object or None to have no data (or use the other keywords)
    Lambda : `Angle`, optional, must be keyword
        The longitude-like angle corresponding to Sagittarius' orbit.
    Beta : `Angle`, optional, must be keyword
        The latitude-like angle corresponding to Sagittarius' orbit.
    distance : `Quantity`, optional, must be keyword
        The Distance for this object along the line-of-sight.
    pm_Lambda_cosBeta : :class:`~astropy.units.Quantity`, optional, must be keyword
        The proper motion along the stream in ``Lambda`` (including the
        ``cos(Beta)`` factor) for this object (``pm_Beta`` must also be given).
    pm_Beta : :class:`~astropy.units.Quantity`, optional, must be keyword
        The proper motion in Declination for this object (``pm_ra_cosdec`` must
        also be given).
    radial_velocity : :class:`~astropy.units.Quantity`, optional, must be keyword
        The radial velocity of this object.

    """

    default_representation = coord.SphericalRepresentation
    default_differential = coord.SphericalCosLatDifferential

    frame_specific_representation_info = {
        coord.SphericalRepresentation: [
            coord.RepresentationMapping('lon', 'Lambda'),
            coord.RepresentationMapping('lat', 'Beta'),
            coord.RepresentationMapping('distance', 'distance')]
    }

##############################################################################
# Breaking this down line-by-line, we define the class as a subclass of
# `~astropy.coordinates.BaseCoordinateFrame`. Then we include a descriptive
# docstring.  The final lines are class-level attributes that specify the
# default representation for the data, default differential for the velocity
# information, and mappings from the attribute names used by representation
# objects to the names that are to be used by the ``Sagittarius`` frame. In this
# case we override the names in the spherical representations but don't do
# anything with other representations like cartesian or cylindrical.
#
# Next we have to define the transformation from this coordinate system to some
# other built-in coordinate system; we will use Galactic coordinates. We can do
# this by defining functions that return transformation matrices, or by simply
# defining a function that accepts a coordinate and returns a new coordinate in
# the new system. Because the transformation to the Sagittarius coordinate
# system is just a spherical rotation from Galactic coordinates, we'll just
# define a function that returns this matrix. We'll start by constructing the
# transformation matrix using pre-deteremined Euler angles and the
# ``rotation_matrix`` helper function:

SGR_PHI = (180 + 3.75) * u.degree # Euler angles (from Law & Majewski 2010)
SGR_THETA = (90 - 13.46) * u.degree
SGR_PSI = (180 + 14.111534) * u.degree

# Generate the rotation matrix using the x-convention (see Goldstein)
D = rotation_matrix(SGR_PHI, "z")
C = rotation_matrix(SGR_THETA, "x")
B = rotation_matrix(SGR_PSI, "z")
A = np.diag([1.,1.,-1.])
SGR_MATRIX = matrix_product(A, B, C, D)

##############################################################################
# Since we already constructed the transformation (rotation) matrix above, and
# the inverse of a rotation matrix is just its transpose, the required
# transformation functions are very simple:

@frame_transform_graph.transform(coord.StaticMatrixTransform, coord.Galactic, Sagittarius)
def galactic_to_sgr():
    """ Compute the transformation matrix from Galactic spherical to
        heliocentric Sgr coordinates.
    """
    return SGR_MATRIX

##############################################################################
# The decorator ``@frame_transform_graph.transform(coord.StaticMatrixTransform,
# coord.Galactic, Sagittarius)``  registers this function on the
# ``frame_transform_graph`` as a coordinate transformation. Inside the function,
# we simply return the previously defined rotation matrix.
#
# We then register the inverse transformation by using the transpose of the
# rotation matrix (which is faster to compute than the inverse):

@frame_transform_graph.transform(coord.StaticMatrixTransform, Sagittarius, coord.Galactic)
def sgr_to_galactic():
    """ Compute the transformation matrix from heliocentric Sgr coordinates to
        spherical Galactic.
    """
    return matrix_transpose(SGR_MATRIX)

##############################################################################
# Now that we've registered these transformations between ``Sagittarius`` and
# `~astropy.coordinates.Galactic`, we can transform between *any* coordinate
# system and ``Sagittarius`` (as long as the other system has a path to
# transform to `~astropy.coordinates.Galactic`). For example, to transform from
# ICRS coordinates to ``Sagittarius``, we would do:

icrs = coord.ICRS(280.161732*u.degree, 11.91934*u.degree)
sgr = icrs.transform_to(Sagittarius)
print(sgr)

##############################################################################
# Or, to transform from the ``Sagittarius`` frame to ICRS coordinates (in this
# case, a line along the ``Sagittarius`` x-y plane):

sgr = Sagittarius(Lambda=np.linspace(0, 2*np.pi, 128)*u.radian,
                  Beta=np.zeros(128)*u.radian)
icrs = sgr.transform_to(coord.ICRS)
print(icrs)

##############################################################################
# As an example, we'll now plot the points in both coordinate systems:

fig, axes = plt.subplots(2, 1, figsize=(8, 10),
                         subplot_kw={'projection': 'aitoff'})

axes[0].set_title("Sagittarius")
axes[0].plot(sgr.Lambda.wrap_at(180*u.deg).radian, sgr.Beta.radian,
             linestyle='none', marker='.')

axes[1].set_title("ICRS")
axes[1].plot(icrs.ra.wrap_at(180*u.deg).radian, icrs.dec.radian,
             linestyle='none', marker='.')

plt.show()

##############################################################################
# This particular transformation is just a spherical rotation, which is a
# special case of an Affine transformation with no vector offset. The
# transformation of velocity components is therefore natively supported as
# well:

sgr = Sagittarius(Lambda=np.linspace(0, 2*np.pi, 128)*u.radian,Beta=np.zeros(128)*u.radian,pm_Lambda_cosBeta=np.random.uniform(-5, 5, 128)*u.mas/u.yr,pm_Beta=np.zeros(128)*u.mas/u.yr)
icrs = sgr.transform_to(coord.ICRS)
print(icrs)

fig, axes = plt.subplots(3, 1, figsize=(8, 10), sharex=True)

axes[0].set_title("Sagittarius")
axes[0].plot(sgr.Lambda.degree,
             sgr.pm_Lambda_cosBeta.value,
             linestyle='none', marker='.')
axes[0].set_xlabel(r"$\Lambda$ [deg]")
axes[0].set_ylabel(r"$\mu_\Lambda \, \cos B$ [{0}]"
                   .format(sgr.pm_Lambda_cosBeta.unit.to_string('latex_inline')))

axes[1].set_title("ICRS")
axes[1].plot(icrs.ra.degree, icrs.pm_ra_cosdec.value,
             linestyle='none', marker='.')
axes[1].set_ylabel(r"$\mu_\alpha \, \cos\delta$ [{0}]"
                   .format(icrs.pm_ra_cosdec.unit.to_string('latex_inline')))

axes[2].set_title("ICRS")
axes[2].plot(icrs.ra.degree, icrs.pm_dec.value,
             linestyle='none', marker='.')
axes[2].set_xlabel("RA [deg]")
axes[2].set_ylabel(r"$\mu_\delta$ [{0}]"
                   .format(icrs.pm_dec.unit.to_string('latex_inline')))

plt.show()

Bye

[wpeter11]

You all are fantastic! At this point, sagemathcell looks to be the best workaround for now. Thanks for all the help!

[JonB]

Thanks @Matteo -- I didn't realize sagemath let's you use pip!

[Matteo]

@wpeter11 Hi, I'm happy to know it helps you, if you want it would be a good thing to write a "thank you" mail to Andrey, that works continuously on SageMathCell (William A. Stein is the founder of SageMath). A lot of people work on it.

Obviously it is not so convenient to compile (yes sagemathcell allows you to compile and run C and Fortran codes and to use common Linux shell commands like ls with !ls, for example) every time a python lib, but you can do it the first time, create a zip folder with all compiled (for Linux) libraries, download the zip to upload it in your preferred cloud service (dropbox, github, ....), and create a python script that, when you need it, allows you to download in a math session of sagemathcell your zipped compiled library (with dependencies), extract it and use it. If you have limit about length of your code, you can save it in a file, copy the file in cloud service, download it when you need and open it to read content in sage server (without sending the full code to server by inserting the text in the cell).

I don't know if with python script sage_interface user can do several calculations maintaining the same temporary/sandboxed folder created by sagemathcell. I think it is possible but some tests are required. For now every time you run a script sent to the server, sage_interface creates each time a new cell (that is: a new different temp folder in the server machines, and that folder is visible only by you, in theory). This means that you should download or compile every time what you want, also for simple tests.

@JonB Hi, yes it is a nice thing, I discovered it a short time ago when I was doing tests on file creation in sagemathcell temp folders. It is possibile to use pip and it seems to call automatically gcc/fortran compiler if needed (gcc available as a built-in package). Only for Linux. It is like to have in Pythonista a free Linux virtual machine available online.

Regards