Merge pull request #322 from mkelley/release-v0.3

Release v0.3

CHANGES.rst

@@ -0,0 +1,163 @@
+0.3.0 (2022-04-28)
+==================
+
+New Features
+------------
+
+sbpy.activity
+^^^^^^^^^^^^^
+
+- New ``VectorialModel`` to implement the Festou (1981) model of the same name.
+  The code reproduces tests based on the literature within 20%, but the causes
+  of the differences are unknown.  Help testing this new feature is appreciated.
+  [#278, #305]
+
+sbpy.data
+^^^^^^^^^
+
+- ``DataClass`` fields are now checked for physically consistent units (e.g.,
+  heliocentric distance in units of length), or that they are ``Time`` objects,
+  as appropriate. [#275]
+
+sbpy.photometry
+^^^^^^^^^^^^^^^
+
+- Add ATLAS c and o bandpasses to ``bandpass``. [#258]
+
+sbpy.spectroscopy
+^^^^^^^^^^^^^^^^^
+
+- Add the ability to redden ``SpectralSource`` (such as the ``Sun`` model in
+  ``sbpy.calib``) with a new ``.redden()`` method. [#289]
+
+
+Bug Fixes
+---------
+
+sbpy.activity
+^^^^^^^^^^^^^
+
+- Allow apertures to be astropy ``Quantity`` objects in ``GasComa`` models,
+  e.g., ``Haser``.  [#306]
+
+sbpy.data
+^^^^^^^^^
+- Corrected ``Orbit.oo_propagate`` units on angles from degrees to radians.
+  [#262]
+- Corrected ``Orbit`` fields from openorb to use ``'Tp'`` for perihelion date
+  epochs as astropy ``Time`` objects, instead of ``'Tp_jd'``. [#262]
+- Corrected ``Name.from_packed`` which could not unpack strings including "j".
+  [#271]
+- Remove hard-coded URL for JPL Horizons and astroquery's ``Horizons`` objects.
+  [#295]
+- NaNs no longer crash ``Phys.from_sbdb``. [#297]
+- When units are not included in the ``Phys.from_sbdb`` results returned from
+  NASA JPL, return unit-less values (and any description of the units, such as
+  ``'density_sig'``) to the user. [#297]
+- ``Names.parse_comet`` now correctly parses Pan-STARRS if included in a comet
+  name string, and corrected the label for fragment names in C/ objects:
+  ``'fragm'`` --> ``'fragment'`` . [#279]
+- Preserve the order of the user's requested epochs in ``Ephem.from_horizons``.
+  [#318]
+
+sbpy.photometry
+^^^^^^^^^^^^^^^
+
+- Corrected PS1 filter wavelength units in ``bandpass`` from Å to nm. [#258]
+- Fix ``HG1G2`` to respect the units on phase angle ``ph`` or else assume
+  radians. [#288]
+
+API Changes
+-----------
+
+sbpy.data
+^^^^^^^^^
+
+- ``DataClass.field_names`` now returns a list of field names rather than a list
+  of internal column names. [#275]
+
+Other Changes and Additions
+---------------------------
+
+- Improved compatibility with Python 3.8 [#259]
+- Added support for astropy 4.0, drop support for astropy 3. [#260, #322]
+- Infrastructure updated to use contemporary astropy project standards. [#284]
+- Tests may be run in parallel with pytest, e.g., using ``-n auto``. [#297]
+
+
+0.2.2 (2020-04-27)
+==================
+
+New Features
+------------
+None
+
+
+Bug Fixes
+---------
+
+
+sbpy.activity
+^^^^^^^^^^^^^
+
+- Fix exception from ``Haser`` when ``CircularAperture`` in linear units is
+  used. [#240]
+
+
+sbpy.data
+^^^^^^^^^
+
+- ``DataClass.__getitem__`` now always returns a new object of the same
+  class, unless a single field name is provided in which case an
+  astropy.Table.Column (no units provided) or astropy.units.Quantity
+  (units provided) is returned. [#238]
+
+- Fixed ``Ephem.from_horizons`` to skip adding units to the ``'siderealtime'``
+  field if it is missing.  Now, the only required field is ``'epoch'``. [#242]
+
+- ``Ephem.from_horizons`` no longer modifies the ``epochs`` parameter in-place.
+  [#247]
+
+
+sbpy.photometry
+^^^^^^^^^^^^^^^
+
+- Fixed ``HG12_Pen16`` calculations, which were using the 2010 G1 and G2
+  definitions. [#233]
+
+- Use "Partner" under NASA logo. [#249]
+
+
+API Changes
+-----------
+None
+
+
+Other Changes and Additions
+---------------------------
+
+sbpy.activity
+^^^^^^^^^^^^^
+
+- Test ``Haser.column_density`` output for angular apertures << lengthscale.
+  [#243]
+
+
+website
+-------
+
+- Use HTTPS everywhere. [#244]
+
+
+0.2.1
+=====
+This version was not released.
+
+
+Notes
+=====
+
+This changelog tracks changes to sbpy starting with version v0.2.  Recommended
+subsection titles: New Features, Bug Fixes, API Changes, and Other Changes and
+Additions.  Recommended sub-sub-section titles: sbpy submodules, in alphabetical
+order.

LICENSE.rst

@@ -1,4 +1,4 @@
-Copyright (c) 2017-2021, sbpy team
+Copyright (c) 2017-2022, sbpy team
 All rights reserved.
 
 sbpy uses a 3-Clause BSD License:

README.rst

@@ -56,7 +56,7 @@ The official `documentation and API reference <https://sbpy.readthedocs.io/en/la
 Status
 ------
 
-sbpy is still under development, which will be finished in 2022. For an overview on the status of individual features see the `Status Page <https://sbpy.readthedocs.io/en/latest/status.html>`_.
+sbpy is still under development, with v1.0 scheduled for delivery in 2024. For an overview on the status of individual features see the `Status Page <https://sbpy.readthedocs.io/en/latest/status.html>`_.
 
 
 Acknowledgements

docs/about.rst

@@ -1,21 +1,20 @@
-.. doctest-skip-all
-
 About sbpy
 ==========
 
 What is sbpy?
 -------------
 
 
-`sbpy` is an `Astropy`_ affiliated package for small-body planetary
+`sbpy` is an `~astropy` affiliated package for small-body planetary
 astronomy. It is meant to supplement functionality provided by
-`Astropy`_ with functions and methods that are frequently used in the
+`~astropy` with functions and methods that are frequently used in the
 context of planetary astronomy with a clear focus on asteroids and
 comets.
 
-As such, `sbpy` is open source and freely available to everyone. The
-development of `sbpy` is funded through NASA PDART Grant
-No. 80NSSC18K0987, but contributions are welcome by everyone!
+As such, `sbpy` is open source and freely available to everyone. The development
+of `sbpy` is funded through NASA Planetary Data Archiving, Restoration, and
+Tools (PDART) Grant Numbers 80NSSC18K0987 and 80NSSC22K0143, but contributions
+are welcome from everyone!
 
 
 Why sbpy?
@@ -30,7 +29,7 @@ well-documented methods to planetary astronomers in order to boost
 productivity and reproducibility. Python has been chosen as the
 language of choice as it is highly popular especially among
 early-career researchers and it enables the integration of `sbpy` into
-the `Astropy`_ ecosystem.
+the `~astropy` ecosystem.
 
 
 What is implemented in sbpy?
@@ -51,7 +50,7 @@ has been completed:
 * access tools for various databases for orbital and physical data, as
   well as ephemerides services
 
-The development is expected to be completed in 2021. For an overview
+The development is expected to be completed in 2024. For an overview
 of the progress of development, please have a look at the :ref:`status
 page`.
 
@@ -77,7 +76,7 @@ sketch.
    functionality. Colored symbols match the colors and symbols of
    classes and modules they are using.
 
-The functionality of version 1.0, which will be finalized in 2021, is
+The functionality of version 1.0, which will be finalized in 2024, is
 detailed below. Please refer to the :ref:`status page` to inquire the
 current status of each module.
 
@@ -142,7 +141,8 @@ reflectance (I/F) models of particulate surfaces, and phase functions
 of dust grains in cometary comae. The disk-integrated phase function
 models of asteroids include the IAU adopted (H, G1 , G2) system
 (Muinonen et al. 2010), the simplified (H, G12) system (Muinonen et
-al. 2010), as well as the classic IAU (H, G) system. The
+al. 2010) and the revised (H, G12) system (Penttila et al. 2016), as
+well as the classic IAU (H, G) system. The
 disk-resolved bidirectional reflectance model includes a number of
 models that have been widely used in the small bodies community, such
 as the Lommel-Seeliger model, Lambert model, Lunar-Lambert model,
@@ -299,16 +299,16 @@ define a `~sbpy.data.Phys` object with a diameter for asteroid Ceres:
     >>> from sbpy.data import Phys
     >>> ceres = Phys.from_dict({'targetname': 'Ceres',
     ...                         'diameter': 945})
+    Traceback (most recent call last):
+      ...
+    sbpy.data.core.FieldError: Field diameter is not an instance of <class 'astropy.units.quantity.Quantity'>
 
-Of course, everybody knows that Ceres' diameter is 945 km. But this is
-not clear from this definition:
-
-    >>> ceres['diameter']
-    945
-
-Any functionality in `sbpy` thus has to presume that diameters are
-always given in km. This makes sense for large objects - but what
-about meter-sized objects like Near-Earth asteroids?
+`Phys.from_dict` raised an exception (`FieldError`) on 'diameter' because it was
+not an `astropy.units.Quantity` object, i.e., it did not have units of length.
+Of course, we know that Ceres' diameter is 945 km, but it was not clear from our
+definition.  Any functionality in `sbpy` would have to presume that diameters
+are always given in km. This makes sense for large objects - but what about
+meter-sized objects like near-Earth asteroids?
 
 Following the
 `Zen of Python <https://www.python.org/dev/peps/pep-0020/>`_ (explicit
@@ -321,19 +321,17 @@ defined:
     >>> ceres
     <QTable length=1>
     targetname diameter
-		          km   
+                  km   
        str5    float64 
     ---------- --------
-	 Ceres      945.0
+         Ceres    945.0
 
-This way, units and dimensions are always available where they make
-sense and we can easily convert between different units:
+This way, units and dimensions are always available where they make sense and we
+can easily convert between different units:
 
-    >>> ceres['diameter'].to('m')
+    >>> print(ceres['diameter'].to('m'))
     [945000.] m
 
-
-
 Epochs must be Time objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -353,27 +351,27 @@ defined as `~astropy.time.Time` objects, which resolve this confusion:
     >>> obs = Obs.from_dict({'epoch': Time(['2018-01-12', '2018-01-13']),
     ...                      'mag': [12.3, 12.6]*u.mag})
     >>> obs['epoch']
-    ['2018-01-12 00:00:00.000' '2018-01-13 00:00:00.000']
+    <Time object: scale='utc' format='iso' value=['2018-01-12 00:00:00.000' '2018-01-13 00:00:00.000']>
 
 `~astropy.time.Time` objects can be readily converted into other formats:
 
     >>> obs['epoch'].jd
-    [2458130.5 2458131.5]
+    array([2458130.5, 2458131.5])
     >>> obs['epoch'].mjd
-    [58130. 58131.]
+    array([58130., 58131.])
     >>> obs['epoch'].decimalyear
-    [2018.03013699 2018.03287671]
+    array([2018.03013699, 2018.03287671])
     >>> obs['epoch'].iso
-    ['2018-01-12 00:00:00.000' '2018-01-13 00:00:00.000']
+    array(['2018-01-12 00:00:00.000', '2018-01-13 00:00:00.000'], dtype='<U23')
 
-... as well as other time scales:
+as well as other time scales:
 
     >>> obs['epoch'].utc.iso
-    ['2018-01-12 00:00:00.000' '2018-01-13 00:00:00.000']
+    array(['2018-01-12 00:00:00.000', '2018-01-13 00:00:00.000'], dtype='<U23')
     >>> obs['epoch'].tdb.iso
-    ['2018-01-12 00:01:09.184' '2018-01-13 00:01:09.184']
+    array(['2018-01-12 00:01:09.184', '2018-01-13 00:01:09.184'], dtype='<U23')
     >>> obs['epoch'].tai.iso
-    ['2018-01-12 00:00:37.000' '2018-01-13 00:00:37.000']
+    array(['2018-01-12 00:00:37.000', '2018-01-13 00:00:37.000'], dtype='<U23')
 
 See :ref:`epochs` and `~astropy.time.Time` for additional information.
 

docs/conf.py

@@ -68,7 +68,15 @@
 """
 
 extensions += ['sphinx.ext.intersphinx',
-               'sphinx_automodapi.smart_resolver']
+               'sphinx_automodapi.smart_resolver',
+               'sphinx.ext.autosectionlabel']
+
+# For example, index:Introduction for a section called Introduction that
+# appears in document index.rst.
+autosectionlabel_prefix_document = True
+
+# Chooses the sections for labeling by its depth
+autosectionlabel_maxdepth = 2
 
 # -- Project information ------------------------------------------------------
 
@@ -184,5 +192,5 @@
 intersphinx_mapping['astroquery'] = (
     'https://astroquery.readthedocs.io/en/latest/', None)
 
-intersphinx_mapping['syphot'] = (
+intersphinx_mapping['synphot'] = (
     'https://synphot.readthedocs.io/en/latest/', None)