Spectral response of other materials

[echedey-ls]

Is your feature request related to a problem? Please describe.
To further analyse spectral effect on PV systems, add spectral responses of other materials. Pretty much like pvlib.spectrum.get_example_spectral_response

Describe the solution you'd like
Another function with a similar API, presumably with the spectral responses linked by this @adriesse comment.

Each spectral response could be the mean of the same-tech modules (monosi, polysi and hit).

Describe alternatives you've considered
Add EQE too or all modules' SRs.

Additional context
What should be done with pvlib.spectrum.get_example_spectral_response?

At first I think of a new function so there are no breaking changes, but reusing that API also looks juicy.

This issue is also discussed in #1963 .

[adriesse]

I advise against grouping and averaging the spectral responses like this because other technology details that are very relevant for SR are being blurred, and the available samples are not necessarily representative.

W.r.t programmatic use of the available SR's, can you open and use the netcdf file on Duramat without first manually downloading it?

[echedey-ls]

I see. I will drop the averaging and just bundle each module SR.

W.r.t programmatic use of the available SR's, can you open and use the netcdf file on Duramat without first manually downloading it?

I don't think it really is a burden to do so, but if I understand you correctly, I would expect that downloading the data file each time the function is called would take some significant time. At that point then we can include some caching, but which one? I prefer to have some persistent caching between interpreter runs rather than session-only-caching, since it uses more RAM and would download the data each time.

Programming persistent caching into PVLIB may be a bit overwhelming to maintain in the long term, so I'd consider some package like Pooch. I did propose that in some draft GSoC application, but that's gonna require some deep reviewing and integration in the dev ecosystem.

Expanding further on Pooch, it requires Python>=3.7 (yay!) and is already being used by some popular packages.

Maybe you only requested changes on the dirty code I uploaded in PR #2038 body? I don't have an issue regarding that.

[AdamRJensen]

Negative on maintaining caching

[adriesse]

Perhaps we can define the feature a bit better before getting distracted by implementation options. Maybe there are even two features?

1. Define a small number of SR's representative of certain technologies. I'm not against that feature, but think it requires some research to establish truly representative curves.
2. Provide easy access functions for resources on Duramat (with examples). Could fall under iotools.

[echedey-ls]

Define a small number of SR's representative of certain technologies. I'm not against that feature, but think it requires some research to establish truly representative curves.

I don't dislike your proposal. What do you think would make some good representative curves? Other source of data? Or another way of (not)grouping it? E.g., selecting by the module instead of the mean of the modules by type.

Provide easy access functions for resources on Duramat (with examples). Could fall under iotools.

I don't think this fits pvlib. I've been looking at CKAN's documentation and played a bit with Duramat's database, and it's not intuitive at all. It can be used as a remote data endpoint internally given the constant URIs are used (thou I agree on not caching remote data, at least for now). I don't see any way an user would benefit from looking at a bunch of json responses, or, in a best-case scenario, opening the file by themselves.

Some sample code

import requests
DURAMAT_API_ACTION_LINK = "https://datahub.duramat.org/api/3/action/"
PACKAGE_LIST_ENDPOINT = DURAMAT_API_ACTION_LINK + "package_list"
PACKAGE_SHOW_ENDPOINT = DURAMAT_API_ACTION_LINK + "package_show"


def get_package_list():
    resp = requests.get(PACKAGE_LIST_ENDPOINT)
    return resp.json()["result"]


def get_adriesse_nc_file_from_package_response():
    package_adriesse = "module-sr-library"
    resp = requests.get(PACKAGE_SHOW_ENDPOINT, [("id", package_adriesse)])
    files = resp.json()["result"]["resources"]
    netcfd_file_uri = files[0]["url"]
    netcfd_file_response = requests.get(netcfd_file_uri)
    netcfd_file = netcfd_file_response.content
    return netcfd_file


def get_adriesse_nc_file_directly():
    netcfd_file_uri = "https://datahub.duramat.org/dataset/09af523e-689a-44cc-a658-dfc0888034d0/resource/1004264a-d8d6-4eaf-a0de-4efff68d2fc6/download/sr_library.nc"
    netcfd_file_response = requests.get(netcfd_file_uri)
    netcfd_file = netcfd_file_response.content
    return netcfd_file

I still haven't had luck with the datasets endpoint, but it seems to me like there it's there only to create, modify, delete and search datasets, likely for people creating the data, not layman users like ours would be.

[echedey-ls]

Since there is no conversation here from few weeks ago, I will open the PR as a definitive proposal. Nevertheless feel free to continue suggesting, both here and there.

[AdamRJensen]

See reason for closing in #2038

[echedey-ls]

Agreed. I would be happy to hear alternatives to include in my GSoC.