pysat / pysatmissions

Mission planning instrument tools for pysat

pysat: Python Satellite Data Analysis Toolkit

The Python Satellite Data Analysis Toolkit (pysat) provides a simple and flexible interface for robust data analysis from beginning to end - including downloading, loading, cleaning, managing, processing, and analyzing data. Pysat's plug-in design allows analysis support for any data, including user provided data sets. The pysat team provides a variety of plug-ins to support public scientific data sets in packages such as pysatNASA, pysatMadrigal, and more, available as part of the general pysat ecosystem.

Full Documentation

JGR-Space Physics Publication

Pysat Ecosystem Publication

Citation Info

Come join us on Slack! An invitation to the pysat workspace is available in the 'About' section of the pysat GitHub Repository. Development meetings are generally held fortnightly.

Main Features

• Instrument independent analysis routines.
• Instrument object providing an interface for downloading and analyzing a wide variety of science data sets.
  • Uses pandas or xarray for the underlying data structure; capable of handling the many forms scientific measurements take in a consistent manner.
  • Standard scientific data handling tasks (e.g., identifying, downloading, and loading files and cleaning and modifying data) are built into the Instrument object.
  • Supports metadata consistent with the netCDF CF-1.6 standard. Each variable has a name, long name, and units. Note units are informational only.
• Simplifies data management
  • Iterator support for loading data by day/file/orbit, independent of data storage details.
  • Orbits are calculated on the fly from loaded data and span day breaks.
  • Iterate over custom seasons
• Supports rigorous time-series calculations that require spin up/down time across day, orbit, and file breaks.
• Includes helper functions to reduce the barrier in adding new science instruments to pysat

Installation

The following instructions provide a guide for installing pysat and give some examples on how to use the routines.

Prerequisites

pysat uses common Python modules, as well as modules developed by and for the Space Physics community. This module officially supports Python 3.X+.

Common modules	Community modules
dask	netCDF4
numpy >= 1.12
pandas
portalocker
pytest
scipy
toolz
xarray

PyPi Installation

pip install pysat

GitHub Installation

git clone https://github.com/pysat/pysat.git

Change directories into the repository folder and run the pyproject.toml or setup.py file. For a local install use the "--user" flag after "install".

cd pysat/
python -m build .
pip install .

Using pysat

• The first time pysat is run, you will need to specify a directory to store the data. In Python, run:

pysat.params['data_dirs'] = 'path/to/directory/that/may/or/may/not/exist'

• Nominal organization of data is top_dir/platform/name/tag/inst_id/files

Detailed examples and tutorials for using pysat are available in the documentation.

pysatmissions's Issues

ENH: Conjunction tool

Is your feature request related to a problem? Please describe.
Part of mission planning involves planning for conjunctions with ground-based stations or other spacecraft.

Describe the solution you'd like
Implementing a tool that would allow a user to check when predicted orbits intersect within a given range of a spacecraft or ground station, either spatially or on geomagnetic field lines connected to the target.

Describe alternatives you've considered
One possible implementation could be an interface to the SSCWeb online tool. This is limited to existing spacecraft (I think), but could be a good first step.

STY: vector calculations

Is your feature request related to a problem? Please describe.
Currently, the vector functions treat each component individually. This leads to an excess of variables in functions when each could be treated as a time-series vector within pandas.

Describe the solution you'd like
Replace syntax such as

inst['sc_xhat_ecef_x'], inst['sc_xhat_ecef_y'], inst['sc_xhat_ecef_z'] = ...

with

inst[['sc_xhat_ecef_x', 'sc_xhat_ecef_y', 'sc_xhat_ecef_z']] = ...

This would reduce variables and keep each vector grouped together. It would also eliminate the np.vstack commands needed in the calculations elsewhere.

Describe alternatives you've considered
Leave things as they are. Pandas are fickle. 🐼

Additional context
Discussion in RC 0.3.2

BUG: Issue with orbit and sgp4 defaults

Describe the bug
If a user attempts to iterate by orbit using sgp4, with added quasi-dipole coordinates, to get orbits by local time, then things get wonky with default values.

The issue is pysat's filtering of orbit breaks. The sgp4 values and additional coordinates look ok.

To Reproduce
Steps to reproduce the behavior:
1.

# Define on-the-fly orbit breakdown input. Note that `mlt` variable will be added by custom function.
orbit_info = {"kind": "lt", "index": "mlt"}
# Instantiate satellite propagator. Note that `inclination` and `alt_periapsis` are keywords defined by
# `missions_sgp4` module, not pysat itself.
inst = pysat.Instrument("missions", "sgp4", orbit_info=orbit_info)
inst.custom_attach(
    pysatMissions.methods.magcoord.add_quasi_dipole_coordinates,
    kwargs={
        "glat_label": "geod_latitude",
        "glong_label": "geod_longitude",
        "alt_label": "geod_altitude",
    },
)
inst.load(2019, 2, use_header=True)
 
inst.orbits.next()

5. Orbit breakdown is all weird and wrong.

Expected behavior
Normal orbit iteration.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: MacOS
• Version Python 3.9
• Other details about your setup that could be relevant

Additional context
I think the gradient in mlt is too low compared to pysat orbit defaults. We need to expose those parameters, and have optional and consistent orbit filtering across orbit types. This is really a pysat problem that is exposed via pysatMissions.

BUG: `freq` keyword not passing through

Describe the bug
The orbital propagators have a frequency keyword specified in the load routines. However, this keyword does not pass through the system as expected.

To Reproduce

import pysat
from pysatMissions.instruments import pysat_sgp4
sgp4 = pysat.Instrument(inst_module=pysat_sgp4, num_samples=3600, freq='1s')

produces

ValueError                                Traceback (most recent call last)
<ipython-input-9-664778b01808> in <module>
----> 1 sgp4 = pysat.Instrument(inst_module=pysat_sgp4, num_samples=3600, freq='1s')

~/code/core/pysat/pysat/_instrument.py in __init__(self, platform, name, tag, inst_id, clean_level, update_files, pad, orbit_info, inst_module, directory_format, file_format, temporary_file_list, strict_time_flag, ignore_empty_files, labels, custom, **kwargs)
    394 
    395         if len(missing_keys) > 0:
--> 396             raise ValueError('unknown keyword{:s} supplied: {:}'.format(
    397                 '' if len(missing_keys) == 1 else 's', missing_keys))
    398 

ValueError: unknown keyword supplied: ['freq']

Additional context
May require a fix in the main package. tagging @rstoneback

ENH: Generalize project_ecef_vector_onto_sc

Is your feature request related to a problem? Please describe.
The code works for projecting any ecef vector onto the s/c but the documentation specifies a particular one.

Further, the labels used to access some variables are hard coded in the method. Allowing users to provide labels makes this a very general function.

Describe the solution you'd like
Add more user input labels, and modify docstring.

Describe alternatives you've considered
We could leave as is but it is unnecessarily restrictive.

Additional context
Add any other context or screenshots about the feature request here.

MAINT: update apexpy install

Is your feature request related to a problem? Please describe.
Apexpy is moving to meson for the build.

Describe the solution you'd like
Update to install latest version. May need custom install from github.

Describe alternatives you've considered
Ignore and rely on local tests? Optional install already implemented.

Additional context
aburrell/apexpy#103

BUG: update default value for `num_samples`

Is your feature request related to a problem? Please describe.
Currently num_samples defaults to 86400 to give a full day of data for missions_sgp4, assuming that cadence is 1 s. If cadence is adjusted, default expected behaviour is not maintained.

Describe the solution you'd like
Should calculate to adjust total points in case user adjusts the cadence to maintain 1 day of data as the default.

Describe alternatives you've considered
May consider a cap. When generating high-res data, this can quickly become time consuming.

Additional context
n/a

ENH: expanded data range

Is your feature request related to a problem? Please describe.
The current data range of available orbits is three years based on inheritance from pysat.

Describe the solution you'd like
Tie to the start and stop dates to 1957 to 2056, the operational range of TLEs.

Describe alternatives you've considered
The runtime does increase when carrying around a longer list of files. As a test, changing from a three-year range to a hundred-year range increases the run time about 40% (from 0.47s to 0.64s per orbit on average, running >100 orbits randomly). In theory we could also pass through file_date_range as an optional argument for a quicker version of this, but may still run into an overhead issue.

Additional context
The list of fake files is required by pysat, ie, a file must exist before it can be loaded.

See #66 for more discussion.

ENH: Store orbital elements as a dict

Is your feature request related to a problem? Please describe.
missions_sgp4 has a lot of kwargs, some of which are mutually exclusive.

Describe the solution you'd like
We could expand the element checks in the orbital methods to store these as a single dict for input, similar to how pysat treats "orbit_info". Could reduce duplication if new instruments are added down the line.

Describe alternatives you've considered
Rely on the docstrings in the instrument to sort it our.

Additional context
thoughts from codeclimate review (too many kwargs in load)

MAINT: warning evaluation

Replace the custom. eval_deprecation function in test_deprecation.py with the pysat.utils.testing.eval_warnings function once pysat 3.0.2 is released.

ENH: Logo

Is your feature request related to a problem? Please describe.
pysatMissions needs a logo.

Describe the solution you'd like
Not quite sure what this should look like.

Describe alternatives you've considered
I like the idea of incorporating a slide rule, but likely beyond my art skills.

Check standard docs for pysatMissions

There is now a central repository for templates at https://github.com/pysat/pysatEcosystem_Template

• Make sure current issues / actions / etc are up to standard
• Make sure any extra bits here are captured in the templates

BUG: Instrument registration does not work

Describe the bug
If I try to register the instruments in pysat, the registry is updated accordingly. However, pysat will search in the main package for the instruments rather than loading them from the registry.

To Reproduce

import pysat
import pysatMissions
pysat.utils.registry.register_by_module(pysatMissions.instruments)
sgp4 = pysat.Instrument('pysat', 'sgp4')

produces

ModuleNotFoundError: No module named 'pysat.instruments.pysat_sgp4'

Presumably this is because the platform name is pysat.

Expected behavior
Should load from pysatMissions.

Additional context
This could be solved here by renaming the platform or in the main package by adjusting how the code works. Tagging @rstoneback.

ENH: update vector calculations

Is your feature request related to a problem? Please describe.
Using OMMBV is overkill for the cross-products and other vector calculations. Since this is becoming an optional install, an alternative should be incorporated.

Describe the solution you'd like
Update using numpy.linalg: https://numpy.org/doc/stable/reference/routines.linalg.html

Describe alternatives you've considered
A sub-module for vectors here, or perhaps other math packages.

Additional context
See #88 for more discussion.

ENH: Move empirical models used by pysat_sgp4 into separate methods files

Migrating from pysat/pysat#205.

Right now, sgp4 accesses pyglow to add simulated data from iri, msis, etc to the simulated instrument. These methods would be useful for to compare to measured data.

Proposal:

• Add a pyglow_methods.py file to contain the pyglow functions currently incorporated in pysat_sgp4
• Add an apexpy methods file for similar reasons
• Add an aacgmv2 methods file, etc.
• Add a brief tutorial on how to apply these functions to spacecraft data to the documentation section

ENH: Add tag option to `pysat_ephem` to turn off models.

Is your feature request related to a problem? Please describe.
It's not always desired to generate the full complement of empirical models. In particular, some use cases may involve other geophysical models through pysatModels to test specific events such as geomagnetic storms or plasma irregularities.

Describe the solution you'd like
Ideally, pysat_ephem should include a tag option to turn off all or some of the models. At a minimum, this can be an all or nothing case. Or perhaps some additional tags to specify 'msis_only', etc.

Describe alternatives you've considered
As an alternative to (or in conjunction with) the tags, booleans may be assigned to turn each model or model component on or off. This may be overkill compared to the benefits (developer time, code speed and resources, etc). See pysat/pysat#292 for further discussion.

Additional context
To some extent, the amount of speed / memory gained may drive the final granularity of this tag option.

Potential orbit supporting package (`satmad`)

Is your feature request related to a problem? Please describe.
Stumbled upon satmad while in review. https://satmad.readthedocs.io/en/stable/about.html
It may be useful.

Describe the solution you'd like
Possible the package has features we could use. Has a satellite propagation module with 'full forces'

a) Numerical Propagation with full force model: Geopotentials, solar radiation pressure, 3rd body interactions, atmospheric drag b) Analytical Propagation: Two-Body

We may want to check it out.

Describe alternatives you've considered
Ignore potential supporting modules.

Additional context
Add any other context or screenshots about the feature request here.

BUG: poweredbypysat logo in main directory

Description

Figures and logos belong in the doc directory.

To Reproduce this bug:

Steps to reproduce the behavior:

1. Go to main directory
2. See error

Test configuration

Irrelevant

Additional context

Repository format should mirror the pysatEcosystemPackage when it makes sense to do so.

ENH: Update pysatMagVect to OMMBV

Is your feature request related to a problem? Please describe.
The spacecraft methods are a mix of types. Likewise, pysatMagVect functions are scattered throughout.

Describe the solution you'd like
Some of the spacecraft functions could be regrouped under pysatMagVect.

Additional context
See #9 for further context.

DOC: tutorials for orbit generation

Is your feature request related to a problem? Please describe.
The documentation is bare bones. Creating new spacecraft can be inferred from the docstrings, but this is not the most user-friendly version.

Describe the solution you'd like
Needs a tutorial that specifies what is inferred from docstrings.

Describe alternatives you've considered
😿

Additional context
n/a

MAINT: pyephem no longer updated

Is your feature request related to a problem? Please describe.
pyephem will continue to receive bug updates, but the creators suggest that skyfield is preferred.
see https://rhodesmill.org/pyephem/

Describe the solution you'd like
With the proper enhancements to the sgp4 instrument (#56), this could be dropped.

Describe alternatives you've considered
Update to skyfield? It's more for astronomical objects, not satellites.

Additional context
Originally this was employed to retrieve lat lon alt info. This can be updated via #56

BUG/TST: pyglow fails in travis build

Describe the bug

make: *** pyglow/models/dl_models/hwm07: No such file or directory.  Stop.
error: Command "/usr/bin/gfortran -Wall -g -ffixed-form -fno-second-underscore -fPIC -O3 -funroll-loops -Ibuild/src.linux-x86_64-3.6/build/src.linux-x86_64-3.6/src/pyglow/models/dl_models/iri16 -I/home/travis/miniconda/envs/test-environment/lib/python3.6/site-packages/numpy/core/include -I/home/travis/miniconda/envs/test-environment/include/python3.6m -c -c src/pyglow/models/dl_models/iri16/irifun.for -o build/temp.linux-x86_64-3.6/src/pyglow/models/dl_models/iri16/irifun.o -std=legacy -w -O2 -fbacktrace -fno-automatic -fPIC" failed with exit status 1

Possible Solutions

• Turn off pyglow if not installed. This is partially set up for local usage, but the tests need a bypass as well.
• Remove pyglow for the time being, potentially replace with other projects
• Update pyglow make files and make a pull request

ENH: custom WGS model import

Is your feature request related to a problem? Please describe.
WGS model is hardwired for instrument

Describe the solution you'd like
Add custom kwarg to allow users to select WGS84 or WGS72.

Describe alternatives you've considered
pain and confusion

Additional context
Need to deprecate default for missions_sgp4, new default will be WGS84.

MAINT: add file headers similar to pysat 3.2.0

Description

😼

ENH: cartopy support

Is your feature request related to a problem? Please describe.
Need to add support for cartopy in the plot routine. This has two major obstacles:

• Need to adjust projection to match plot size
• Need to make travis environment compatible with cartopy requirements

Describe the solution you'd like
The travis setup could you the solution descrbed here: https://laszukdawid.com/2017/06/04/installing-cartopy-on-ubuntu-14-04-or-travis-ci/

Describe alternatives you've considered
Alternatively (or additionally), a soft import of cartopy may be employed since this increases the requirements significantly.

Additional context
Cartopy requires proj, which exists on conda environments but does not exist on pip as there is an unrelated project with the same name. Soft import may be the way to go since the setup may not be universal.

TST: check on vector projection calculations in tests

Is your feature request related to a problem? Please describe.
Several unit tests in test_methods_spacecraft need to validated separately. The input and output of these routines was generated from the function, so the tests validate the function has not changed.

Describe the solution you'd like
Work through the math for the following:

• test_add_ram_pointing_sc_attitude_vectors
• test_project_ecef_vector_onto_sc

Describe alternatives you've considered
😕

Additional context
legacy issue from comments in code

STY: Use pysat core code to reduce duplication of code for instruments

Is your feature request related to a problem? Please describe.
From a coding perspective, the orbit propagators here and the test instruments in pysat share a number of similarities, such as the 'filename' generation and other pysat standard functions. These instruments should import functions from pysat rather than duplicate the code over here.

Describe the solution you'd like
As the testing methods in pysat get sorted out, rewrite the instruments here to import from there to improve maintainability.

Describe alternatives you've considered
n/a

Additional context
Requires a number of changes to pysat to be developed.

STY: update metadata for instruments

Is your feature request related to a problem? Please describe.
Usage is inconsistent.

Describe the solution you'd like

• Add more meta data labels to all instruments. name at a minimum, but check for consistency with sami2py, etc.
• Evaluate the usage of meta.copy()

Describe alternatives you've considered
😕

Additional context
See discussion in #54

ENH: TLE generator

Is your feature request related to a problem? Please describe.
Often for mission planning, the TLE is needed. Need something that can generate TLEs from user-supplied keywords and vice-versa. Keywords should be physical quantities such as inclination, eccentricity, etc.

Describe the solution you'd like
Code should include an orbit dictionary with these keywords. Require functions to translate dictionary into TLEs, and read TLEs into user-friendly ouput.

TST: NEP 29 compliance

Is your feature request related to a problem? Please describe.
Automated testing currently does not work with numpy <= 1.19 due to issues with installing other codes. This is related to f2py construction of required releases.

Describe the solution you'd like
Once required numpy 1.19 support is dropped in July 2022, we can implement NEP29 protocols at that time. A 1.0.0 release before then is unlikely.

Describe alternatives you've considered
Update install procedures in apexpy, OMMBV, and potentially others. Those codes are working using their local tests, but not when installed via pip for some reason when using older versions of numpy.

Additional context
See #44 for more info.

STY/TST: Update package and testing to new pysat standards

• Move metadata to setup.cfg
• Incorporate docs testing
• Use requirements.txt -- (proper implementation requires release of pysat 3.0)
• Use num_samples keyword instead of numeric string for inst_id (see #16)

ENH: Common metadata checks

Is your feature request related to a problem? Please describe.
Maintainability could be improved by defining metadata in a single location. This could be imported across multiple instruments.

Describe the solution you'd like
A single metadata check somewhere. Either add as part of functions (eg, geospacepy methods) or have a single database that checks variable names.

Describe alternatives you've considered
Keep things as they are.

Additional context
Pings from codeclimate about file length and repeated code statements. missions_ephem is deprecated and will be removed, but new instrument modules may take its place.

TST: End-to-end test of instrument

An end-to-end test of the instrument similar to test_instruments.py in pysat needs to be incorporated. The code can be adapted and customized from that code, but needs to be made pytest compatible. Since there is currently one instrument, and it does not rely on downloads, much of the code can be customized for this particular use. Future instruments in this class would likely use a similar method.

To close:

• Incorporate test_instruments class into testing
• Make pytest-compatible (remove init function in class and restructure)
• Streamline download checks

ENH: Usage of list_files

Is your feature request related to a problem? Please describe.
pysat currently requires a file to exist before it is loaded. This presents an issue for pysatMissions, as data is created on the fly, and should be interoperable for any given year. The pysat test instruments solve this by generating a list of daily files for a period of three years. pysatMissions currently imports those routines, which presents a problem for defining missions outside that three-year period.

Describe the solution you'd like
This should be opened up so that plans for missions in the future and past can be generated from TLEs. A simple way is to define the span of dates to encompass a wide range of dates. This requires an update to the core package, but could be time-consuming if I literally have to generate thousands of fake files in a list.

Describe alternatives you've considered

• Rework the load routine here to add requested file to the file list.
• Use the cadence features to define yearly files for the instruments, cutting down on the list size
• a bypass feature for this package

Additional context
Add any other context or screenshots about the feature request here.

BUG: accuracy of sgp4 orbits

Describe the bug
When generating an orbit with sgp4, the expected altitude may be off by up to 10s of km for LEO orbits.

To Reproduce

import pysat
sat = pysat.Instrument('missions', 'sgp4', inclination=5, alt_periapsis=400)
sat.load(2019, 1)

Expected behavior
The expected orbit is circular at 400 km altitude. The mean altitude and geodetic altitude are low.

Screenshots

Desktop (please complete the following information):

• OS: Mac OS X 11.6.5
• Version: python 3.8.11
• pysatMissions rc 0.3.0

Additional context
Potential sources

• mismatch of gravity / earth mass constants in pysatMissions, sgp4, geospacepy
• mismatch of earth radius assumptions in packages
• keplerian orbit calculations do not consider an ellipsoidal earth
• usage of WGS72

TST/BUG: OMMBV requires manual install on GitHub Actions

Describe the bug
OMMBV does not install from pip. Some sort of numpy conflict.

To Reproduce
See logs here
https://github.com/pysat/pysatMissions/actions/runs/1099735603

Currently using --no-binary flag to install separately, likely needs updates at main package. Documented there at CosmicStudioSoftware/OMMBV#50

STY: check for tags in `list_files`

Trouble Exporting to netcdf

Describe the bug
After creating an sgp4 instrument with missions I have tried to save to netcdf.
When I use the to_netcdf function I get the error

AttributeError: NetCDF: Not a valid data type or _FillValue type mismatch

I tried saving a cnofs ivm instrument with to_netcdf and got a different error, but I was still unable to save it.

I'm wondering if this is because I'm not setting the kwargs correctly.

To Reproduce

Python 3.9.13 (main, Aug 25 2022, 18:29:29) 
Type 'copyright', 'credits' or 'license' for more information
IPython 8.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import pysat

In [2]: sat1 = pysat.Instrument('missions', 'sgp4')

In [3]: sat1.load(2018,1)
<ipython-input-3-46da04f1f5b8>:1: DeprecationWarning: Meta now contains a class for global metadata (MetaHeader). Default attachment of global attributes to Instrument will be Deprecated in pysat 3.2.0+. Set `use_header=True` in this load call or on Instrument instantiation to remove this warning.
  sat1.load(2018,1)

In [4]: sat1.to_netcdf4('/Users/jmsmit37/sat1_30_degrees.nc')
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In [4], line 1
----> 1 sat1.to_netcdf4('/Users/jmsmit37/sat1_30_degrees.nc')

File ~/anaconda3/envs/missions/lib/python3.9/site-packages/pysat/_instrument.py:3618, in Instrument.to_netcdf4(self, fname, base_instrument, epoch_name, zlib, complevel, shuffle, preserve_meta_case, export_nan, unlimited_time, modify)
   3615 inst = self if modify else self.copy()
   3617 # Write the output file
-> 3618 pysat.utils.io.inst_to_netcdf(inst, fname=fname,
   3619                               base_instrument=base_instrument,
   3620                               epoch_name=epoch_name, zlib=zlib,
   3621                               complevel=complevel, shuffle=shuffle,
   3622                               preserve_meta_case=preserve_meta_case,
   3623                               export_nan=export_nan,
   3624                               unlimited_time=unlimited_time)
   3626 return

File ~/anaconda3/envs/missions/lib/python3.9/site-packages/pysat/utils/io.py:1816, in inst_to_netcdf(inst, fname, base_instrument, epoch_name, mode, zlib, complevel, shuffle, preserve_meta_case, check_type, export_nan, unlimited_time, meta_translation, meta_processor)
   1809 cdfkey = out_data.createVariable(epoch_name, 'i8',
   1810                                  dimensions=(epoch_name),
   1811                                  zlib=zlib,
   1812                                  complevel=complevel,
   1813                                  shuffle=shuffle)
   1815 # Attach epoch metadata
-> 1816 cdfkey.setncatts(export_meta[epoch_name])
   1818 # Attach the time index to the data
   1819 cdfkey[:] = (inst.index.values.astype(np.int64)
   1820              * 1.0E-6).astype(np.int64)

File src/netCDF4/_netCDF4.pyx:4408, in netCDF4._netCDF4.Variable.setncatts()

File src/netCDF4/_netCDF4.pyx:1694, in netCDF4._netCDF4._set_att()

File src/netCDF4/_netCDF4.pyx:1965, in netCDF4._netCDF4._ensure_nc_success()

AttributeError: NetCDF: Not a valid data type or _FillValue type mismatch

Expected behavior
netcdf file is produced from the instrument

Desktop (please complete the following information):

• OS: Mac OS Monterey
• Version 12.5
• python version 3.9.13
• pysat version 3.0.4
• pysatMissions version 0.3.3
• netCDF4 version 1.6.0

Additional context
All the dependencies for pysatMissions were installed from the git repo using
pip install -r requirements.txt

apexpy and aacgmv2 were installed with pip

ENH: Add sampling options to `inst_id` for instruments

Is your feature request related to a problem? Please describe.
It is not always desired to generate a full day of data. Options to allow a subset of of data, including a single orbit, can be added to the instruments to help optimize certain use cases.

Describe the solution you'd like
The sat_id tag in the pysat_testing instruments provides a template for the solution here. Allowing a numeric value in a string to represent the number of seconds desired provides a straightforward solution.

Additionally, provide a inst_id='orbit' option to calculate the number of points needed for a single orbit from the TLE info (see #8).

• sat_id = numeric string
• sat_id = 'orbit'

DOC: scrub documentation and docstrings

• Make sure all examples can be run
• Add references and acknowledgements to instruments
• Scrub docstrings for pysat 3.0.0 style

ENH: Automated TLE acquisition for existing solution

Is your feature request related to a problem? Please describe.
It would be useful if TLEs could be acquired for existing spacecraft. Is this a solved problem in a package we can import?

ENH: error checking in conversion routines

Is your feature request related to a problem? Please describe.
The spacecraft conversion routines assume that certain data values exist (e.g., sc_xhat_ecef_y).

Describe the solution you'd like
Check through these functions to ensure any error messages that are raised are sufficient to debug. Add a check for parameters if necessary

Describe alternatives you've considered
Wait until a problem arises.

Additional context
legacy issue from comments in code

ENH: apply to other planets?

Is your feature request related to a problem? Please describe.
Current software assumes Earth as the default planet for orbital calculations. This could be expanded to other planets.

Describe the solution you'd like
Add other mass / radius info for potential planets. May need to update output since geospacepy assumes earth.

Describe alternatives you've considered
hard-wire to earth. It's possible that we can only get to ECI-like coords from the system, which may not be as useful.

Additional context
from review of 0.3.0 release candidate.

Remove `data_path` from `list_files` in pysatMissions

BUG: epoch in sgp4 instrument should be consistent

Describe the bug
TLEs have a built-in epoch. When calling multiple days from the same instrument, the data should be continuous. The current setup for the Keplerian inputs resets the input for each day loaded, resulting in discontinuities across day breaks.

To Reproduce

import pysat

tle_sat = pysat.Instrument('missions', 'sgp4')
tle_sat.load(2018, 1)
tle_sat.data[-10:]
tle_sat.load(2018, 2)
tle_sat.data[:10]

kepler_sat = pysat.Instrument('missions', 'sgp4', inclination=20, alt_periapsis=400)
kepler_sat.load(2018, 1)
kepler_sat.data[-10:]
kepler_sat.load(2018, 2)
kepler_sat.data[:10]

For tle_sat, the ECI position values are more or less continuous. For kepler_sat, there is a large discontinuity in position.

Expected behavior
Behaviour should be similar for long term runs.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Mac OS X 10.15.7
• Version python 3.8.11

Additional context

pysatMissions/pysatMissions/instruments/missions_sgp4.py

Lines 163 to 164 in a6121b4

	# Calculate epoch for orbital propagator
	epoch = (dates[0] - dt.datetime(1949, 12, 31)).days

Options for moving forward:

• Include an epoch keyword for the instrument to mirror TLE input when using Keplerians
• Tie epoch to nominal start date for "files"
• Both, with the second option as the default

Installation error

Executing pip install pysatMissions results in the errors depicted below. Kamodo (CCMC), pysat, and pysatNASA are already installed in the same environment. Attempting to import pysatMissions errors.

ENH: Direct Input of Keplerian elements, other parameters

Is your feature request related to a problem? Please describe.
Newer versions of sgp4 allow for the direct input of Keplerian elements to describe an orbit rather than TLEs (eccentricity, inclination, argument of periapsis, right ascension of the ascending node, mean anomaly, mean motion).

Describe the solution you'd like
It would be easier to allow these as direct inputs to the instrument rather than generate a fake TLE (#8). The new syntax also allows for creating an array of timestamps rather than looping through the code.

Describe alternatives you've considered
From a design perspective, it may be easier for some to envision periapsis and apoapsis altitudes rather than eccentricity and mean motion (inverse of orbital period). Conversion routines should be added, which are either run by the user or directly run by the pysat instrument.

Additional context
preliminary tests of this workflow in #60. May replace #8 and #13

TST: add github actions tests for mac and NEP29

Is your feature request related to a problem? Please describe.
Update workflows for main and pysat_rc to include mac tests and NEP29 compliance

Describe the solution you'd like
Follow the templates elsewhere. May need specialty routines for compliance with fortran, etc.

Describe alternatives you've considered
Less testing, more bugs.

Additional context
discussion in #101

BUG: basemap has been deprecated

Describe the bug
Basemap has been deprecated and cannot be run in python 3.7. This needs to be replaced with cartopy or removed.

ENH: conversions for sgp4

Is your feature request related to a problem? Please describe.
The sgp4 instrument currently only outputs ECI coords. These need to be converted into lat / long / alt.

Describe the solution you'd like
Conversions should be available in astropy

Describe alternatives you've considered
other conversion packages may be available

Additional context