astro py:docs

- Index
- Modules

### Navigation

- next »
- « previous |
- Astropy v5.2.1 »
- Known Issues

# Known Issues

While most bugs and issues are managed using the astropy issue tracker, this document lists issues that are too difficult to fix, may require some intervention from the user to work around, or are caused by bugs in other projects or packages.

Issues listed on this page are grouped into two categories: The first is known issues and shortcomings in actual algorithms and interfaces that currently do not have fixes or workarounds, and that users should be aware of when writing code that uses `astropy`. Some of those issues are still platform-specific, while others are very general. The second category is of common issues that come up when configuring, building, or installing `astropy`. This also includes cases where the test suite can report false negatives depending on the context/ platform on which it was run.

## Known Deficiencies

### Quantities Lose Their Units with Some Operations

Quantities are subclassed from `numpy`’s `ndarray` and while we have ensured that `numpy` functions will work well with them, they do not always work in functions from `scipy` or other packages that use `numpy` internally, but ignore the subclass. Furthermore, at a few places in `numpy` itself we cannot control the behaviour. For instance, care must be taken when setting array slices using Quantities:

    >>> import astropy.units as u
    >>> import numpy as np
    >>> a = np.ones(4)
    >>> a[2:3] = 2*u.kg
    >>> a
    array([1., 1., 2., 1.])

    >>> a = np.ones(4)
    >>> a[2:3] = 1*u.cm/u.m
    >>> a
    array([1., 1., 1., 1.])

Either set single array entries or use lists of Quantities:

    >>> a = np.ones(4)
    >>> a[2] = 1*u.cm/u.m
    >>> a
    array([1.  , 1.  , 0.01, 1.  ])

    >>> a = np.ones(4)
    >>> a[2:3] = [1*u.cm/u.m]
    >>> a
    array([1.  , 1.  , 0.01, 1.  ])

Both will throw an exception if units do not cancel, e.g.:

    >>> a = np.ones(4)
    >>> a[2] = 1*u.cm
    Traceback (most recent call last):
    ...
    TypeError: only dimensionless scalar quantities can be converted to Python scalars

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

### Numpy array creation functions cannot be used to initialize Quantity

Trying the following example will ignore the unit:

    >>> np.full(10, 1 * u.m)
    array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1.])

A workaround for this at the moment would be to do:

    >>> np.full(10, 1) << u.m
    <Quantity [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.] m>

As well as with `full` one cannot do `zeros`, `ones`, and `empty`.

The `arange` function does not work either:

    >>> np.arange(0 * u.m, 10 * u.m, 1 * u.m)
    Traceback (most recent call last):
    ...
    TypeError: only dimensionless scalar quantities can be converted to Python scalars

Workarounds include moving the units outside of the call to `arange`:

    >>> np.arange(0, 10, 1) * u.m
    <Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>

Also, `linspace` does work:

    >>> np.linspace(0 * u.m, 9 * u.m, 10)
    <Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>

### Quantities Lose Their Units When Broadcasted

When broadcasting Quantities, it is necessary to pass `subok=True` to `broadcast_to`, or else a bare `ndarray` will be returned:

    >>> q = u.Quantity(np.arange(10.), u.m)
    >>> b = np.broadcast_to(q, (2, len(q)))
    >>> b
    array([[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.],
           [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]])
    >>> b2 = np.broadcast_to(q, (2, len(q)), subok=True)
    >>> b2
    <Quantity [[0., 1., 2., 3., 4., 5., 6., 7., 8., 9.],
               [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]] m>

This is analogous to the case of passing a Quantity to `array`:

    >>> a = np.array(q)
    >>> a
    array([0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])
    >>> a2 = np.array(q, subok=True)
    >>> a2
    <Quantity [0., 1., 2., 3., 4., 5., 6., 7., 8., 9.] m>

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

### mmap Support for `astropy.io.fits` on GNU Hurd

On Hurd and possibly other platforms, `flush()` on memory-mapped files are not implemented, so writing changes to a mmap’d FITS file may not be reliable and is thus disabled. Attempting to open a FITS file in writeable mode with mmap will result in a warning (and mmap will be disabled on the file automatically).

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

### Color Printing on Windows

Colored printing of log messages and other colored text does work in Windows, but only when running in the IPython console. Colors are not currently supported in the basic Python command-line interpreter on Windows.

### `numpy.int64` does not decompose input `Quantity` objects

Python’s `int()` goes through `__index__` while `numpy.int64` or `numpy.int_` do not go through `__index__`. This means that an upstream fix in NumPy is required in order for `astropy.units` to control decomposing the input in these functions:

    >>> np.int64((15 * u.km) / (15 * u.imperial.foot))
    1
    >>> np.int_((15 * u.km) / (15 * u.imperial.foot))
    1
    >>> int((15 * u.km) / (15 * u.imperial.foot))
    3280

To convert a dimensionless `Quantity` to an integer, it is therefore recommended to use `int(...)`.

### Inconsistent behavior when converting complex numbers to floats

Attempting to use `float` or NumPy’s `numpy.float` on a standard complex number (e.g., `5 + 6j`) results in a `TypeError`. In contrast, using `float` or `numpy.float` on a complex number from NumPy (e.g., `numpy.complex128`) drops the imaginary component and issues a `numpy.ComplexWarning`. This inconsistency persists between `Quantity` instances based on standard and NumPy complex numbers. To get the real part of a complex number, it is recommended to use `numpy.real`.

### Structured units deserialization segfaults in big-endian

Structured units deserialization with `pickle` may cause segmentation fault in big-endian machine with `numpy<1.21.1`.

## Build/Installation/Test Issues

### Anaconda Users Should Upgrade with `conda`, Not `pip`

Upgrading `astropy` in the Anaconda Python distribution using `pip` can result in a corrupted install with a mix of files from the old version and the new version. Anaconda users should update with `conda update astropy`. There may be a brief delay between the release of `astropy` on PyPI and its release via the `conda` package manager; users can check the availability of new versions with `conda search astropy`.

### Locale Errors in MacOS X and Linux

On MacOS X, you may see the following error when running `pip`:

    ...
    ValueError: unknown locale: UTF-8

This is due to the `LC_CTYPE` environment variable being incorrectly set to `UTF-8` by default, which is not a valid locale setting.

On MacOS X or Linux (or other platforms) you may also encounter the following error:

    ...
      stderr = stderr.decode(stdio_encoding)
    TypeError: decode() argument 1 must be str, not None

This also indicates that your locale is not set correctly.

To fix either of these issues, set this environment variable, as well as the `LANG` and `LC_ALL` environment variables to e.g. `en_US.UTF-8` using, in the case of `bash`:

    export LANG="en_US.UTF-8"
    export LC_ALL="en_US.UTF-8"
    export LC_CTYPE="en_US.UTF-8"

To avoid any issues in future, you should add this line to your e.g. `~/.bash_profile` or `.bashrc` file.

To test these changes, open a new terminal and type `locale`, and you should see something like:

    $ locale
    LANG="en_US.UTF-8"
    LC_COLLATE="en_US.UTF-8"
    LC_CTYPE="en_US.UTF-8"
    LC_MESSAGES="en_US.UTF-8"
    LC_MONETARY="en_US.UTF-8"
    LC_NUMERIC="en_US.UTF-8"
    LC_TIME="en_US.UTF-8"
    LC_ALL="en_US.UTF-8"

If so, you can go ahead and try running `pip` again (in the new terminal).

### Failing Logging Tests When Running the Tests in IPython

When running the Astropy tests using `astropy.test()` in an IPython interpreter, some of the tests in the `astropy/tests/test_logger.py` might fail depending on the version of IPython or other factors. This is due to mutually incompatible behaviors in IPython and pytest, and is not due to a problem with the test itself or the feature being tested.

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