Add retrieval function for BSRN data

[AdamRJensen]

• I am familiar with the contributing guidelines
• Tests added
• Updates entries to docs/sphinx/source/api.rst for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

Add a retrieval function for BSRN data pvlib.iotools.get_bsrn. Data is obtained from the BSRN's FTP server.

[AdamRJensen]

@kanderso-nrel This is my initial idea for the get_bsrn function.

The read_bsrn function needs to be updated to take a file buffer or a parse_bsrn function needs to be created.

[wholmgren]

@AdamRJensen our solarforecastarbiter-core adaptation of the BSRN code that you contributed to pvlib includes a change to make a parse_bsrn function that only takes a file buffer. Maybe that would be helpful to copy back over here.

[AdamRJensen]

@kanderso-nrel Any idea of why the Linux versions fail, but the others pass?

The log states that the test test_get_bsrn_no_files is failing on Linux due to "Failed: DID NOT WARN. No warnings of type (<class 'UserWarning'>,) was emitted."

My knowledge of Linux is too limited to understand why it would fail on Linux and not the others.. any ideas?

[kandersolar]

@kanderso-nrel Any idea of why the Linux versions fail, but the others pass?

I don't think it's actually a linux-specific issue, it's just that only the conda_linux versions are configured to run the remote_data tests. I can recreate the CI failure on a local ubuntu VM. The problem is that it actually does find a file for the bogus date -- I get back data for the month of 2000-06. I guess the issue is that files are named with the format f"{station}%m%y.dat.gz", so year 1800 gets formatted as year 00 and interpreted as year 2000. Changing the start and end from 1800 to 1899 gets the test to pass for me.

[AdamRJensen]

@cwhanse Any opinion on adding "gri" (ground-reflected irradiance) to the pvlib list of variables? Or perhaps there are better alternatives for the naming of upward short-wave reflected irradiance?

[kandersolar]

This looks great @AdamRJensen! Comments below, mostly very nitpicky...

[AdamRJensen]

Thanks for the review @kanderso-nrel! Do we need a second review on this?

[kandersolar]

Do we need a second review on this?

My answer to that question is always yes :) https://en.wikipedia.org/wiki/Linus%27s_law

[kandersolar]

LGTM, @pvlib/pvlib-maintainer anyone else want to review this?

[cwhanse]

LGTM, @pvlib/pvlib-maintainer anyone else want to review this?

I don't see how I will make time for it. I vote merge and improve later, if needed.

[wholmgren]

Looks good to me. I confirmed the parse function works with data I obtained from the NASA Langley site using requests.

The lines that are not covered are either expected due to the test configuration or are ok to skip for iotools.

Thanks @AdamRJensen! I expect this will be useful to many people.