-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add function for estimating PVsyst SDM parameters from IEC 61853-1 data #2429
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
Conversation
@kandersolar Did you ever get a clear description of how PVsyst implements/calibrates its irradiance-dependent shunt resistance? |
Is there any question of the model itself? The exponential equation is described in their 2010 publication and again in 2023. For determining parameter values for a given module, I don't have anything to offer other beyond this page: https://www.pvsyst.com/help-pvsyst7/pvmodule_rserie_rshunt_determ.htm |
pvlib/ivtools/sdm/pvsyst.py
Outdated
is_g_stc = effective_irradiance == 1000 | ||
is_t_stc = temp_cell == 25 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an idea: could this logical be True for values close to, but not exactly equal to the integer 1000 (or 25)? For lab data, it is common to see floats in the data, and for values such as 1002.1 W/m2 considered equivalent to 1000 W/m2. If we don't want to set an acceptance tolerance here, maybe we change effective_irradiance
to specify a set of integer labels. Or build in the labels, and change the descriptions of the electrical inputs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had similar thoughts when writing the code. Adding irradiance_tolerance
and temperature_tolerance
values, and changing these ==
to interval memberships, seems like an easy and effective option. Would these windows make sense?
- +/- 2% irradiance: IEC 61853-1 section 8.5.1 specifies a simulator of class BBB or better, which IEC 60904-9 requires to have short-term irradiance instability below 2% (I am not sure short-term irradiance instability is the relevant concept here)
- +/- 1 degree temperature: the allowed variation of module temperature during the test, per section 8.5.9 of IEC 61853-1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intervals specified in 61853 make sense to me.
I think I would put the data alignment code in its own function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pythonic way is to use numpy.isclose()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that the IEC 61853-1 results tables use “exact” reporting conditions, which means that the measurement lab has applied any needed I-V corrections TO the (exact) reported temperature and effective irradiance pairs. This correction does indeed add “correction uncertainty” to the corrected I-V values themselves (in addition to their more direct measurement uncertainty), but in effect removes any uncertainty from the reporting conditions.
This was an issue I raised when I was at NREL’s cal lab about their reporting at STC, in which they corrected to an exact irradiance reporting conditions, but did not do this for temperature (IIRC because the temperature correction was too uncertain). Unfortunately, this made interpreting their reports a bit delicate for the customer (for example, to quantify uncertainty of fits like this), because the uncertainty interpretation was different w.r.t. irradiance as opposed to temperature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To put a finer point on this based on my experience developing PVfit, I think it is potentially better to use the “raw” I-V data that have not been “corrected” to exact reporting conditions, because they arguably introduce less uncertainty. This is where standardized measurement reporting systems trade off against striving for the lowest possible uncertainty fits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have also seen the "exact" (i.e., target) G/T conditions in IEC 61853-1 reports, although some additionally report the achieved conditions as well. I did not find this practice to be mandated by the standard, but perhaps I missed it. Regardless, the tolerance parameters may be useful to some users, so I've added them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this in the IEC 61852-1 ed. 1 standard:
Measurements need not be taken at exactly the irradiances and temperatures specified.
Translation of I-V curves from the actual irradiance and/or temperature values to the values
prescribed by the tables can be performed in accordance with IEC 60891. Such interpolation
should be over no more than 100 W⋅m –2 . All such interpolations shall be noted in the test
report and their impact on uncertainly shall be included in the uncertainly analysis.
Nevertheless, measurements shall be taken at or beyond the extremes of irradiance specified
in Table 2 within the measurement accuracy of the instrumentation and the constraints of
section 8.3.2.
So, they seem to leave it up in the air by using the word "can" and never saying that some method (perhaps not necessarily IEC 60891) should be used to translate to and report at exact conditions.
@kandersolar Given limited bandwidth, I refer back to my original discovered issue that motivated #1094. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I haven't run the code, just read it.
Thanks everyone for the reviews! Such feedback is invaluable to pvlib and its community. |
docs/sphinx/source/reference
for API changes.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`
).remote-data
) and Milestone are assigned to the Pull Request and linked Issue.The method is a sequence of regressions, each estimating one of the PVsyst SDM parameters. The steps are not very complicated, but it's a lot of parameters, so the full method needs a nontrivial amount of code (~300 lines, including docs). We tested it on a range of PV technologies and found good results:
For details, please see our open-access JPV article describing the method (currently in early access): https://doi.org/10.1109/JPHOTOV.2025.3554338
This PR builds on two recent SDM PRs:
pvlib.ivtools.sdm
into a subpackage organized by SDM #2256calcparams_pvsyst
#2428