Description

The historic F10.7 data base will raise a JSON error if you ask for a time when they don't have data.

To Reproduce this bug:

Steps to reproduce the behavior:

import pysat
from pysatSpaceWeather.instruments import sw_f107

f107_hist = pysat.Instrument(inst_module=sw_f107, tag='historic')
f107_hist.download(start=f107_hist.lasp_stime, stop=f107_hist.today(), freq='MS')

Test configuration

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

Possible solutions

1. Consider this a feature, since it's clear nothing has been downloaded
2. And an end date attribute to the Instrument (similar to the lasp_stime attribute)
3. Something else?

Description

pysat has a bug in the load routine (see pysat/pysat#1112) where loading an empty instrument and requesting a pad will result in a TypeError in current versions of the code (likely an update in pandas). I added a try/except statement to instruments.methods.kp_ap.filter_geomag to get around this issue until a pysat version cap is added.

Potential impact

• Is the feature related to an existing problem? yes
• How critical is this feature to your workflow? high
• How wide of an impact to you anticipate this enhancement having? wide
• Would this break any existing functionality? no

Additional context

We don't want to carry around try/except(pass) statements around unless absolutely necessary.

Description

Add the new storm indices Hp30 and Hp60: https://kp.gfz-potsdam.de/en/hp30-hp60

Potential impact

• Is the feature related to an existing problem? Kp is capped and has a low resolution
• How critical is this feature to your workflow? Not critical
• How wide of an impact to you anticipate this enhancement having? Important for storm studies
• Would this break any existing functionality? No

Potential solution(s)

A new, single instrument for Hp30 and Hp60:

• platform: 'gfz'
• name: 'hpo'
• tag: '30', '60'

Also add a method to convert from Hpo to apo (log to linear).

Alternatives

Not include this data set

Additional context

https://kp.gfz-potsdam.de/en/hp30-hp60

Description

The NOAA Dst repository is no longer being kept up-to-date. The actual source of Dst is in Kyoto, and is up-to-date with historic, preliminary, and quick-look results. http://wdc.kugi.kyoto-u.ac.jp/wdc/Sec3.html

Potential impact

• Is the feature related to an existing problem? We cannot get Dst past 2012
• How critical is this feature to your workflow? Essential
• How wide of an impact to you anticipate this enhancement having? Vital for most storm studies, some model runs
• Would this break any existing functionality? No

Potential solution(s)

Add another source of Dst and change the NOAA Dst to have a flag indicating its source.

Alternatives

1. Replace the NOAA source with the Kyoto source, but some people may want the NOAA data specifically.
2. Leave things as they are and hope NOAA starts archiving data again
3. Add the Kyoto source and leave the NOAA source as ''. This would be a bit disingenuous, as most people would assume the NOAA source is the best source.
4. Replace the NOAA source with the Kyoto source.

Description

Downloads of Kp data on TravisCI only work sometimes. I think the issue is when UTC date and local system date aren't the same.

To Reproduce this bug:

Steps to reproduce the behavior:

1. Run tests on pysat branch pysat_params, pysat/pysat#637, when TravisCI and UTC date are different, with Kp downloads uncommented
2. Tests will fail on downloads

         # Data by 30-days, recent Kp
1438        self.insts.append(pysat.Instrument('sw', 'kp', tag='recent'))
1439        test_dates = pysatSpaceWeather.instruments.sw_kp._test_dates
1440        self.insts_dates.append([test_dates['']['recent']] * 2)
1441        self.insts_kwargs.append({})
1442    
1443        # Data by 3-day, forecast Kp
1444        self.insts.append(pysat.Instrument('sw', 'kp', tag='forecast'))
1445        test_dates = pysatSpaceWeather.instruments.sw_kp._test_dates
1446        self.insts_dates.append([test_dates['']['forecast']] * 2)
1447        self.insts_kwargs.append({})
1448    
1449        # Download data for all instruments
1450        for inst, dates, kwargs in zip(self.insts, self.insts_dates,
1451                                       self.insts_kwargs):
1452            ostr = ' '.join(('Downloading data for', inst.platform,
1453                             inst.name, inst.tag, inst.inst_id))
1454            print(ostr)
1455>           inst.download(start=dates[0], stop=dates[1], **kwargs)
1456
1457pysat/tests/test_utils_files.py:119: 
1458_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
1459pysat/_instrument.py:3042: in download
1460    self._download_rtn(date_array, **kwargs)
1461../../../miniconda/envs/test-environment/lib/python3.8/site-packages/pysatSpaceWeather/instruments/sw_kp.py:453: in download
1462    data = pds.DataFrame({'mid_lat_Kp': sub_kps[0],
1463../../../miniconda/envs/test-environment/lib/python3.8/site-packages/pandas/core/frame.py:529: in __init__
1464    mgr = init_dict(data, index, columns, dtype=dtype)
1465../../../miniconda/envs/test-environment/lib/python3.8/site-packages/pandas/core/internals/construction.py:287: in init_dict
1466    return arrays_to_mgr(arrays, data_names, index, columns, dtype=dtype)
1467../../../miniconda/envs/test-environment/lib/python3.8/site-packages/pandas/core/internals/construction.py:95: in arrays_to_mgr
1468    return create_block_manager_from_arrays(arrays, arr_names, axes)
1469_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
1470
1471arrays = [array([ 0,  0,  1,  0,  1,  2,  2,  1,  0,  0,  0,  0,  0, -1, -1, -1,  0,
1472        0,  0,  0,  1,  1,  0,  0,  0,  0,...0,  0,  0,  1,  2,  2,  0,  0,  1,  2,  2,
1473        2,  4,  4,  4,  3,  4,  3,  2,  2, -1, -1, -1, -1, -1, -1, -1, -1])]
1474names = Index(['mid_lat_Kp', 'high_lat_Kp', 'Kp'], dtype='object')
1475axes = [Index(['mid_lat_Kp', 'high_lat_Kp', 'Kp'], dtype='object'), DatetimeIndex(['2021-01-01 00:00:00', '2021-01-01 03:00:0...           '2021-01-30 18:00:00', '2021-01-30 21:00:00'],
1476              dtype='datetime64[ns]', length=240, freq='3H')]
1477
1478    def create_block_manager_from_arrays(
1479        arrays, names: Index, axes: List[Index]
1480    ) -> BlockManager:
1481        assert isinstance(names, Index)
1482        assert isinstance(axes, list)
1483        assert all(isinstance(x, Index) for x in axes)
1484    
1485        # ensure we dont have any PandasArrays when we call get_block_type
1486        # Note: just calling extract_array breaks tests that patch PandasArray._typ.
1487        arrays = [x if not isinstance(x, ABCPandasArray) else x.to_numpy() for x in arrays]
1488        try:
1489            blocks = _form_blocks(arrays, names, axes)
1490            mgr = BlockManager(blocks, axes)
1491            mgr._consolidate_inplace()
1492            return mgr
1493        except ValueError as e:
1494>           raise construction_error(len(arrays), arrays[0].shape, axes, e)
1495E           ValueError: Shape of passed values is (272, 3), indices imply (240, 3)
1496

Test configuration

• OS: Linux - TravisCI
• Version: Python 3+
• Different outcomes on local system vs TravisCI

Additional context

Add any other context about the problem here.

Description

UserWarning: Metadata with type <class 'str'> does not match expected type <class 'float'>. Dropping input for 'goes_bgd_flux' with key 'fill'

To Reproduce this bug:

Steps to reproduce the behavior:

1. Load F10.7 data for the 'prelim' tag.

Test configuration

• OS: OS X big sur
• Version: Python 3.9
• Other details about your setup that could be relevant: develop branch of pysat.

Additional context

This user warning shouldn't occur because the Instrument should handle meta better.

Decription

This module needs a logo

Potential impact

• Is the feature related to an existing problem? There is no logo :(
• How critical is this feature to your workflow? I am working on the documents, which require a logo.
• How wide of an impact to you anticipate this enhancement having? Making our project look cool.
• Would this break any existing functionality? No.

Potential solution(s)

I would like a nicely rendered image like the one shown below.

Alternatives

Not have a logo.

Additional context

All pysat packages will eventually have logos.

Description

Add a note or warning to top-level docstring for space weather indices that do not have a cleaning method so that it looks nicely formatted and attention grabbing in documentation. In packages like pysatNASA there is a warning for instruments without cleaning. An index is a more processed dataset than an instrument thus a warning may not be appropriate. Nevertheless, users need guidance somewhere that there is no cleaning.

Potential impact

• Provides clarity for the user

Potential solution(s)

Add a note or warning to top-level docstring for space weather indices that do not have a cleaning method

Alternatives

• Leave as is.
• Add a warning like with pysatNASA. In the log, every load call will have an entry.

Additional context

Description

I was surprised to find that the 'prelim' data loads by year. I didn't see a note about that in the docstrings. I issued a blank .load() which took longer than expected and complained about monotonic times. Feels like 'prelim' should be adjusted as well to load a single day at a time and then all data is available from .load().

To Reproduce this bug:

Steps to reproduce the behavior:

In [37]: f107_prelim = pysat.Instrument('sw', 'f107', 'prelim')                                                                                                                                                             

In [38]: f107_prelim.load(2009, 1)                                                                                                                                                                                          

In [39]: f107_prelim.data                                                                                                                                                                                                   
Out[39]: 
            f107  ssn  ss_area  new_reg  smf goes_bgd_flux  c_flare  m_flare  x_flare  o1_flare  o2_flare  o3_flare
2009-01-01    69    0        0        0 -999          A0.0        0        0        0         0         0         0
2009-01-02    70    0        0        0 -999          A0.0        0        0        0         0         0         0
2009-01-03    70    0        0        0 -999          A0.0        0        0        0         0         0         0
2009-01-04    69    0        0        0 -999          A0.0        0        0        0         0         0         0
2009-01-05    69    0        0        0 -999          A0.0        0        0        0         0         0         0
...          ...  ...      ...      ...  ...           ...      ...      ...      ...       ...       ...       ...
2009-12-27    77   17      100        0 -999          A2.0        0        0        0         0         0         0
2009-12-28    76   17       90        0 -999          A1.4        0        0        0         0         0         0
2009-12-29    75   17       80        0 -999          A1.2        0        0        0         0         0         0
2009-12-30    77   15       50        0 -999          A1.4        0        0        0         0         0         0
2009-12-31    80   16      120        0 -999          A8.5        0        0        0         0         0         0

Test configuration

• OS: [e.g. Hal]
• Version [e.g. Python 3.47]
• Other details about your setup that could be relevant

Additional context

Add any other context about the problem here.

Description

Kp data has moved location to: https://kp.gfz-potsdam.de/en/

To Reproduce this bug:

Not sure if anything is broken yet, but it probably will be in the future.

Test configuration

N/A

Additional context

Found from CEDAR announcement.

Description

I developed a way to address Issue #1 that involves breaking up remote files with multiple data sets into local files that only contain the desired data for each Instrument. However, this is a breaking change for several Kp and F10.7 data sets.

Potential impact

• Is the feature related to an existing problem? Yes, data is currently lost or hidden in unexpected places
• How critical is this feature to your workflow? Critical, current real-time operations use the affected data sets
• How wide of an impact to you anticipate this enhancement having? Package-wide and downstream
• Would this break any existing functionality? Yes

Potential solution(s)

Plan a v0.0.9 release with deprecation warnings for the affected data sets

Alternatives

Changing things without telling people.

Additional context

This will break current operational workflows, and so needs a period of warning.

Description

Add CI testing for documentation

Potential impact

• Is the feature related to an existing problem? There is currently no testing.
• How critical is this feature to your workflow? This has been shown to be useful in evaluating new docstrings and keeping links and examples up-to-date.
• How wide of an impact to you anticipate this enhancement having? A large, long-term impact
• Would this break any existing functionality? No.

Potential solution(s)

Use pysat example and add testing to the travis yaml

Description

Issuing a .load() with tag='all' goes on a runaway memory event. The 'all' tag loads all data for any supplied data, and invoking the .load() supplies the load routine for all dates. My guess is the module is trying to load all the data for each day in the data, resulting in days*2 copies of F10.7. If that is so, modifying 'all' to only respond to a single file, instead of all, will solve the issue.

Given pysat's added .load() feature, the current behavior of loading all data when supplied a single data may also want to be revisited.

To Reproduce this bug:

Steps to reproduce the behavior:

In [1]: import pysat                                                                                                                                                                                                        
im
In [2]: import pysatSpaceWeather                                                                                                                                                                                            

In [3]: f107 = pysat.Instrument('sw', 'f107', 'all')                                                                                                                                                                               

In [4]: f107.load()                                                                                                                                                                                                         

Encountered in review of #31

Test configuration

• OS: [e.g. Hal]
• Version [e.g. Python 3.47]
• Other details about your setup that could be relevant

Additional context

Add any other context about the problem here.

Description

GFZ changed their database, and the old format of files are not available any longer. The new dataset is of higher quality, and so we will remove support for the old dataset in version 0.2.0+ of pysatSpaceWeather.

Description

Running the historic noaa flux past the limit no longer yields a dict with the expected key.

To Reproduce this bug:

After running unit tests, we see

FAILED pysatSpaceWeather/tests/test_instruments.py::TestSWInstrumentLogging::test_historic_download_past_limit - KeyError: 'noaa_radio_flux'

This appears in the main branch on github actions as well as develop when running locally

Test configuration

• OS: Monterrey
• Version python 3.10.9
• pysat develop

Additional context

Running code manually, req.txt yields '{"": {\n}}\n'

On November 14, SWPC added precision to the planetary Kp values, as can be seen here:

https://services.swpc.noaa.gov/text/scn/fy22-kp/10-102_DGD_sample.txt

and broadcasted in this note:

https://www.weather.gov/media/notification/pdf2/scn22-101_kp9m.pdf

This breaks the parsing in pysatSpaceWeather/instruments/sw_kp.py around lines 480, since it is expecting integers where there are now doubles.

Description

Several instruments fail when running against new tests in pysat develop. These include:

• sw_ap, tag='recent'
• sw_f107, tag='daily'
• sw_flare, tag='daily'
• sw_kp, tag='recent'
• sw_polarcap, tag='prediction'
• sw_sbfield, tag='daily'
• sw_ssn, tag='daily'

To Reproduce this bug:

run pytest with pysat develop

Test configuration

• OS: Monterrey
• Version python 3.10.9
• pysat develop

Additional context

polarcap has an AssertionError -- returned data is empty

All other returning a KeyError from deep within pandas

• README
• Code of Conduct
• Contributing
• License
• Issue Templates
• PR Templates

Description

FutureWarning: pad is deprecated and will be removed in a future version. Use ffill instead.

To Reproduce this bug:

This occurs in the F10.7 instrument methods.

Test configuration

• OS: Red Hat
• Version: 3.9
• Other details about your setup that could be relevant: main version of pysat

Additional context

Found during operations

We should add a page to the documentation describing the space weather methods for accessing / comparing indices, as well as one for the model_utils tools.

Description

## GitHub Installatioon header has a double o.

To Reproduce this bug:

Read the README

Expected behavior
The tests for TestSwKpCombine and TestSF107Combine file point to a directory of archived test data, since some of these depend on FTP access for the latest tests. The test date should grab the archive date (3-18-209) rather than the latest date for forecasted data.

Actual behavior
The test is searching for the latest data.

E   FileNotFoundError: [Errno 2] No such file or directory: '/Users/jklenzin/code/core/pysatSpaceWeather/pysatSpaceWeather/tests/test_data/sw/f107/all/f107_1947_to_2020-09-30.txt'

Description

The Dst instrument loads all data requested (internally) and then drops a bunch of it.

To Reproduce this bug:

Steps to reproduce the behavior:

start_date = dt.datetime(2001, 1, 1)
end_date = dt.datetime(2001, 12, 31)
dst = pysat.Instrument('sw', 'dst')
dst.load(date=start_date, end_date=end_date)
dst['dst'].plot(title=dst.meta['dst', dst.meta.labels.name], 
                ylabel=dst.meta['dst', dst.meta.labels.units])

Note the full year is not present.

Test configuration

• OS: Mac OS 10.15.4
• Version: Python 3.8.3

Additional context

Add any other context about the problem here.

See group project here, https://github.com/orgs/pysat/projects/4/views/1
with a root here: pysat/pysat#949

The forecast files for F10.7 contain a lot of other forecasted indices. We need to figure out a way to make this data accessible without downloading the file into multiple directories.

Description

The description header is misspelled in the feature/enhancement template

To Reproduce this bug:

Steps to reproduce the behavior:

1. Run a spell checker on the template

Test configuration

• OS: OS X Mojave
• Version Python 3.7
• Other details about your setup that could be relevant

Additional context

Emacs doesn't have a spellchecker :P

At some point after the sw_ace branch was merged into develop, the sw_ace instrument was deleted. Not sure how to fix this.

Description

Coveralls reveals there are several lines that aren't covered and should be.

Potential impact

• Is the feature related to an existing problem? Ensuring the robustness of the codebase
• How critical is this feature to your workflow? I am still uncovering bugs, so this could help identify them before I need the code to work operationally
• How wide of an impact to you anticipate this enhancement having? This will impact everyone who uses the package
• Would this break any existing functionality? No, it will only fix things.

Potential solution(s)

Closer to 100% coverage!

Alternatives

Leaving gaps in the code coverage.

Additional context

These data products will be used in an operational context and need to work under a variety of realtime conditions.

Description

I am currently working on adding a feature for one of the other issues - F30 index. Due to the structure of the files from NoRP, I am thinking of just adding a NoRP instrument. It would be able to gather either calibrated data and/or fits data that spans over all frequencies available. Luckily, provided on the NoRP site is a Python library that contains reading routines and a summary plotter.

The question - how should I go about adding the reading routines to my fork with proper acknowledgement? I don't see a readily available license on the code or the site.

Example code (optional)

There are some functions such as

norp_fits.norp_rd_1GHzI(fname)
norp_fits.norp_rd_1GHzCalD(fname)
norp_fits.norp_plot_summary(fname)

that are able to parse the binary files for raw data, calibrated data, and create summary plots from the day file.

Configuration

• OS : MacOS 12.0.1
• Versions:
  • Python 3.9.0
  • pysat 3.1.0

Description

FutureWarning: The series.append method is deprecated and will be removed from pandas in a future version. Use pandas.concat instead.

To Reproduce this bug:

This is used in the sw_kp.py load routine.

Test configuration

• OS: Red Hat
• Version: Python 3.9
• Other details about your setup that could be relevant: operational code, main version of pysat

Description

The routines in methods.sw should be broken up by instrument. The current structure is a holdover from pysat 2.X. This would be a breaking change, and so should be done as soon as possible.

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

Description

After pysat 3.2.0 is the latest supported version of pysat, the label Instrument kwarg will no longer need to be supported.

Potential impact

• Is the feature related to an existing problem? Some support methods use the label kwarg, which has been deprecated
• How critical is this feature to your workflow? Important for maintanability
• How wide of an impact to you anticipate this enhancement having? Important for developers
• Would this break any existing functionality? No

Potential solution(s)

Identify places in the code where a pysat Instrument is called using labels and replace with meta_kwargs.

Alternatives

Continue to support kwargs of no-longer-supported pysat versions

Description

Currently, the README and docs tell the users to get this package from git, but there is a pypi distribution available.

Potential impact

• Is the feature related to an existing problem? likely related to the current unavailability of pysat 3.0
• How critical is this feature to your workflow? not at all
• How wide of an impact to you anticipate this enhancement having? wide, most people use pip
• Would this break any existing functionality? I don't think so

Potential solution(s)

Add a badge and update the installation guide.

Alternatives

Leaving it alone

https://pypi.org/project/pysatSpaceWeather/

Logging needs to be updated. I'm not getting any messages from the Dst download method despite the logging.info call. Perhaps these need to be hooked into pysat's logger? Alternately, logging needs to be activated within this package.

Description

There are poorly defined zenodo keys in the .zenodo.json file that don't need to be there.

To Reproduce this bug:

See pysat/pysat#617

Suggested fix

Remove keys that are providing info that github does a good job specifying.

Description

A Dst index predicted from ACE data is available from LASP here: http://lasp.colorado.edu/space_weather/dsttemerin/dst_last_96_hrs.txt

Potential impact

• Is the feature related to an existing problem? Not having current/future Dst values
• How critical is this feature to your workflow? Not currently vital, but with clear future use
• How wide of an impact to you anticipate this enhancement having? Helping ionospheric/magnetospheric model predictions
• Would this break any existing functionality? No.

Potential solution(s)

Add this source to the Dst instrument

Alternatives

Ignore this relevant data source

Description

After pysat 3.2.0 is the latest supported version of pysat, the use_header kwarg will no longer be needed.

Potential impact

• Is the feature related to an existing problem? This kwarg is currently used in some methods/utilities and in the unit tests
• How critical is this feature to your workflow? This will raise unnecessary warnings that may alarm the user
• How wide of an impact to you anticipate this enhancement having? Important for maintance
• Would this break any existing functionality? No

Potential solution(s)

• Update usage with a version check
• Remove entirely after pysat 3.2.0 is the lowest supported version of pysat.

Alternatives

Allow annoying warnings

Additional context

This was a temporary kwarg needed to ease users into a new Instrument and Meta data structure.

Description

Update the mock download parameterization to use the appropriate key after pysat issue pysat/pysat#1158 is implemented.

Potential impact

• Is the feature related to an existing problem? Cannot fully test TestMockDownloads on CI
• How critical is this feature to your workflow? Necessary
• How wide of an impact to you anticipate this enhancement having? Allow potential errors to be caught
• Would this break any existing functionality? No

Potential solution(s)

Update test suite once a new pysat key is available

Alternatives

Find a way to re-create the inst_dict locally.

Additional context

See: #133

Description

pysatSpaceWeather is used in operational environments, so we need to know when things break. CI tests should be run at regular intervals and report to someone who can fix things when there are problems.

Potential impact

• Is the feature related to an existing problem? Remote databases can change file formats and database structures
• How critical is this feature to your workflow? Will break operational systems
• How wide of an impact to you anticipate this enhancement having? Prevent unknown system failures
• Would this break any existing functionality? No

Potential solution(s)

Implementation of regular CI tests

Alternatives

Manually run CI at regular intervals

For the tests of sw.combine_kp, blank values are returned as NaNs, but the test is searching for -1.

Description

LASP provides many useful space weather data sets that we don't currently support. These may be found here: https://lasp.colorado.edu/home/spaceweather/

Potential impact

• Is the feature related to an existing problem? Our goal is to provide useful space weather data, so we should support all of these
• How critical is this feature to your workflow? Not critical to my workflow
• How wide of an impact to you anticipate this enhancement having? Large, this could be a good hook into LASP
• Would this break any existing functionality? No

Potential solution(s)

Add instruments for each of the LASP data sets

• LISIRD Solar Irradiance data (https://lasp.colorado.edu/lisird/)
• Predicted AL (https://lasp.colorado.edu/space_weather/dsttemerin/dsttemerin.html)
• Predicted AU (https://lasp.colorado.edu/space_weather/dsttemerin/dsttemerin.html)
• Predicted AE (https://lasp.colorado.edu/space_weather/dsttemerin/dsttemerin.html)
• Energetic electrons at geosynchronous orbit (https://lasp.colorado.edu/space_weather/xlf3/xlf4.html)

Alternatives

Not providing these data sets

Description

The ACE platform is wrong. Instead of sw it should be swpc because it retrieves the space weather prediction center ACE data.

To Reproduce this bug

Go read the sw_ace.py docstring

Additional context

chose sw initially, because I couldn't figure out an appropriate platform name.

Description

People can discover new packages at zenodo if keywords are supplied.

Potential impact

• Is the feature related to an existing problem? Discoverability
• How critical is this feature to your workflow? Minor
• How wide of an impact to you anticipate this enhancement having? Minor
• Would this break any existing functionality? No

Potential solution(s)

Add keywords to the .zenodo.json file. OCBpy, AACGMV2, and apexpy all do this.

Alternatives

Leaving things alone.

The current setup.py file is too basic and needs to be streamlined. This (and related work) includes:

• including comments saying that name, version, license, etc are in setup.cfg
• using requirements.txt file
• updating .travis.yml accordingly
• adding a .zenodo.json file

Description

No matter how you try and download historic F10.7 data, you get a deprecation warning.

To Reproduce this bug:

Steps to reproduce the behavior:

f107_hist.download(start=f107_hist.lasp_stime, stop=f107_hist.today(), freq='MS') and pysat raises a deprecation warning for using freq. f107_hist.download(start=f107_hist.lasp_stime, stop=f107_hist.today()) and pysatSpaceWeather raises a deprecation warning for not using freq.

Test configuration

• OS: OS X Big Sur
• Version: Python 3.9
• Other details about your setup that could be relevant: develop branch of pysat, up to date with last release.

Additional context

Add any other context about the problem here.

Description

kp_ap.py:217: FutureWarning: backfill is deprecated and will be removed in a future version. Use bfill instead.

To Reproduce this bug:

Check out the kp_ap methods.

Test configuration

• OS: Red Hat
• Version: Python 3.9
• Other details about your setup that could be relevant: main version of pysat

Additional context

Found during operations

Description

F30 is a solar index that has been show to correlate well to solar cycle changes in foF2. The F30 is the Solar Flux measured by the Nobeyama Radio Observatory, which performs daily measurements of the 30 cm radio flux on an operational 7/365 basis. However, the Nobeyama Radio Observatory is no longer operational. There may be other sources of this index, but a historical data set is available.

Potential impact

• Is the feature related to an existing problem? No
• How critical is this feature to your workflow? Not critical
• How wide of an impact to you anticipate this enhancement having? Improving solar irradiance studies
• Would this break any existing functionality? No

Potential solution(s)

Add data from: https://solar.nro.nao.ac.jp/norp/index.html

Alternatives

Identify other sources of the index

Additional context

Learned about this during EGU 2023.

https://www.swsc-journal.org/articles/swsc/pdf/2017/01/swsc160042.pdf
https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2022SW003359

Description

The CVS file loading method in pysatSpaceWeather.instruments.methods.ace will be available in pysat after the 3.0.1 release. pysat/pysat#768

Potential impact

This function can be removed in future releases.

Potential solution(s)

1. Add a deprecation warning after the 3.0.1 release
2. Remove after thee 3.1.0 release and update the pysat minimum version

Alternatives

Have the function in both places forever

Additional context

This function was developed for the ACE file loading and identified as a useful general function in #48. Because it could easily apply to other instruments, the same function was added to pysat in pysat/pysat#768.

Description

JRO is developing South American based geomagnetic indices that should be available on their website by the end of the year

Potential impact

• Is the feature related to an existing problem? Most K indices have a northern hemisphere bias
• How critical is this feature to your workflow? Not essential, but potentially important
• How wide of an impact to you anticipate this enhancement having? Improve hemispheric handling of indices
• Would this break any existing functionality? No

Potential solution(s)

Add a new instrument once available.