-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spectral mismatch calculation #1523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
aha, I have wanted to do this for a long time, but we will need either spectral response or EQE. @shirubana had sent me or posted some a while back. I was going to copy this "spectral mismatch" gist over to the example gallery which has an cSi EQE from SunPower. A function in pvlib using EQE and AM1.5 as inputs would be even better tho! Some things to consider:
anyway I <3 this idea and I have wanted it for a long time. thanks! |
Another possible source of QE curves is to ask Geoffrey Kinsey for the curves he's been using for spectral mismatch evaluation (most recently here). I looked at the mPERT curves a while back and I think I remember being disappointed for some reason -- only a few curves, or maybe not very many points per curve? I forget. +1 to a general function |
I've been using ASTM G-173 from NREL |
Always great to get such spontaneous reactions! As part of my work with Sandia I will prepare around a dozen SR as open data. They'll be put up on Duramat (see link above) as well as the PVPMC website. There is a notebook on the Duramat website already which will give you some idea on the the direction I'm heading: I advocate standardizing on 5nm wavelength intervals for both SR and spectral irradiance data sets. That way resampling can be done once at the source by the people who best understand the source equipment and characteristics. (Someone with suitable permissions could assign this issue to me actually.) |
To some specific points:
Broadband for now. Worst case someone can calculate separately for module and sensor and combine.
Some are coming on Duramat and PVPMC websites.
I will work mostly with SR since that's what is actually measured and that's also what we need. Conversion could be two more utility functions.
Definitely user spectra!
I think it should be included in pvlib in some form. I also include it in the spectral irradiance data sets for convenience. |
I'm not in favor of having pvlib act as a data provider. From what little I know of this topic, spectral response is specific to cell type and module material stack, so I don't think it makes sense to look for generic response curves. I can see the need to have a few spectra and EQE/response curves for function testing. |
We're aiming for DuraMAT datahub and PVPMC website. Incidentally, the platform used by DuraMAT has the capability to provide programmatic access to metadata and data via an API, but I don't know whether that feature is enabled. In case anyone finds this interesting and want to dig into it... |
I need to review this discussion further, but here is my open source implementation of this: |
Here are a couple relevant articles regarding spectral corrections, and my code aimed to accommodate both traditional and newer use cases for spectral corrections. My colleague Behrang Hamadani at NIST can provide "alternative" standard spectra. Also, there used to be some subtle differences between the standard global spectrum from IEC and ASTM, but I think they tried to reconcile. Happy to reinvestigate and discuss further. Temperature-Dependent Spectral Mismatch Corrections - https://ieeexplore.ieee.org/ielx7/5503869/7300475/07210143.pdf Photovoltaic Characterization Under Artificial Low Irradiance Conditions Using Reference Solar Cells - https://ieeexplore.ieee.org/document/9103553/ |
Glad you joined the discussion @markcampanelli. The target here is to cover the most important use case for outdoor performance while offering some useful flexibility as well. Hopefully the PR succeeds at that. You make an interesting point about the integration of the SR-spectrum product. The trapezoid rule that is used here and probably by the majority of people who do mismatch calculations may be technically incorrect, but only if you assume that linear interpolation of the SR and spectrum are correct. Since the latter are only approximations, your alternate integration technique will not necessarily produce a value that is closer to the "truth". Anyway, there's plenty of room in pvlib for alternate implementations! |
The two standards are based on the same simulated spectrum, but the IEC tabulated numbers are scaled down slightly. Fortunately scaling does not affect the mismatch calculation. |
IIRC, the issue between the IEC and ASTM standards had to due with the "tail" of the spectral irradiance past 4 microns. In IEC, the tail function was not provided, but it's integral was (i.e., the energy in the tail of the distribution). In ASTM, the tail function and energy were both left essentially undefined. This typically led to a discrepancy when using broadband cavity radiometers for primary reference cell calibrations. For most spectral mismatch calculations the tail indeed did not matter, as you point out. In any case, I'm 99% sure that ASTM addressed the discrepancy after I discovered it at NREL :). In addition to issues of extrapolation below 280 nm and above 4 micron, another issue that I have with the standards is that they do NOT define an interpolation scheme between points, so essentially the spectra are not fully defined, which raises all sorts of inter-comparison questions. For an arbitrary standard spectrum with a reasonably dense partition, I see no harm in the standard DEFINING the curve to be piecewise-linear (or using a PCHIP if they want more smoothness and to respect the extrema in the data points). In addition, they should defined the low wavelength (in the UV) where the spectrum becomes zero and stays zero, and I have already mentioned above the problem of defining the full spectrum out to very large wavelengths. Of course, the measured quantum efficiencies are certainly NOT piecewise-linear in reality, and we cannot simply define them to be that. In my code, I made the assumption that QE measurements are typically sufficiently dense so that the piecewise-linear interpolation is sufficiently accurate, which has a beneficial numerical advantage of producing an analytic and fast-to-compute summation formula for the common refinement of the partitions of the two functions being multiplied and integrated. I realistically cannot take a look at the PR until next week, but I would be happy to do so! I am very interested in running inter-comparison calculations for the benefit of validating both methods. It was also on my roadmap for PVfit to accommodate additional interpolation schemes, although that was low priority, |
Looking forward to your review @markcampanelli ! |
And others' reviews too of course... |
FYI cool educative video on calculating M https://www.youtube.com/watch?v=398v4irJsKw&t=4s |
@mikofski would you be available to do a review since you are familiar with the subject? |
@adriesse I’ll definitely take a look, when it quiets down, thanks! |
Not to get too off topic, but this poster has a section on programmatic access to the DataHub: https://energy.sandia.gov/download/55130/ |
Is your feature request related to a problem? Please describe.
Currently the only function in pvlib that uses spectral irradiance is
spectrl2
.Describe the solution you'd like
This feature will provide a function to calculate the spectral mismatch for a given spectral response and spectral irradiance in relation to the reference spectrum. Its intended application is to estimate module performance gains or losses due spectral irradiance in the field differing from the reference spectrum used in the lab for module power rating.
Additional context
Efforts are ongoing to assemble and publish both spectral irradiance and spectral response data, such as:
https://datahub.duramat.org/project/about/spectral-irradiance-data-and-resources
The new feature will make it easier to make use of those spectral resources.
The text was updated successfully, but these errors were encountered: