Add guidance about IAM to User Guide#2683
Conversation
RDaxini
left a comment
RDaxini
left a comment
There was a problem hiding this comment.
Nice job @kandersolar , this is great. Thank you for putting this together! I left some comments on a few relatively minor things, but besides those few points this LGTM
| +-------------------------------------------+---------+-------------------------------------------+ | ||
| | :py:func:`~pvlib.iam.physical` | direct | Physics-based; optional AR coating | | ||
| +-------------------------------------------+---------+-------------------------------------------+ | ||
| | :py:func:`~pvlib.iam.sapm` | direct | Can exhibit "wiggles" in the curve | |
There was a problem hiding this comment.
I think some clarification on what this "wiggles" comment means exactly might be helpful
| Types of models | ||
| --------------- | ||
|
|
||
| IAM is sometimes applied only to the beam component of in-plane irradiance, as |
There was a problem hiding this comment.
For the target audience of this guide, it might not be obvious that "direct" (seen in the table under "type") is the same as "beam" (written here in the description). Let's equate the two somewhere/somehow, or just the same word.
| where :math:`T(\theta)` represents the transmitted light fraction at AOI :math:`\theta`. | ||
| IAM equals (by definition) 1.0 when AOI is zero and typically approaches zero | ||
| as AOI approaches 90 degrees. The shape of the IAM profile at intermediate AOI |
There was a problem hiding this comment.
| as AOI approaches 90 degrees. The shape of the IAM profile at intermediate AOI | |
| as AOI approaches 90°. The shape of the IAM profile at intermediate AOI |
If you get double spaces, then I get to say use the symbol with a number.
(I don't actually mind the double spaces, rumor is I actually like it, but you know I like teasing you for it regardless :D)
| Module-specific values can be obtained via testing. For example, IEC 61853-2 | ||
| testing produces measured IAM values across the range of AOI and a corresponding | ||
| parameter value for the Martin-Ruiz model. Parameter values for other models can | ||
| be determined using :py:func:`pvlib.iam.fit`. Parameter values can also be (approximately) |
There was a problem hiding this comment.
| be determined using :py:func:`pvlib.iam.fit`. Parameter values can also be (approximately) | |
| be determined using :py:func:`pvlib.iam.fit`. Parameter values can also be approximately |
Small thing but I'd vote to lose the parentheses... no room for grammatical nuances and soft qualifications in pvlib—let's be direct ;)
disclaimer: I won't die on that hill, leave them in if you prefer
|
I'm glad to see pvlib incorporating these guides. I'm sure it will be very useful at many knowledge stages. My two cents are:
Thanks @kandersolar for hauling this initiative. |
Good point. Reminder to add other missing aspects of these IAM models too:
|
| :term:`aoi`) and the optical properties of the module. | ||
|
|
||
| Some reduction occurs at all angles of incidence, even normal incidence. | ||
| However, because PV module testing is performed at normal incidence, |
There was a problem hiding this comment.
| However, because PV module testing is performed at normal incidence, | |
| However, because PV modules are rated with irradiance at normal incidence, |
There are test protocols for measuring the IAM that steer modules away from normal to the solar vector.
| Therefore, only the extra reduction at non-normal incidence should be modeled. | ||
|
|
||
| This is done using incidence angle modififer (:term:`IAM`) models. IAM is | ||
| the fraction of incident light that is transmitted to the PV cell, normalized |
There was a problem hiding this comment.
I'm going to object here to the general statement "IAM is the fraction of incident light" without some qualification. It is either the incident direct or diffuse light, but (to my knowledge) never the combined, plane-of-array irradiance. Except for the physical IAM, every IAM model appears to have been developed and/or validated using either direct or diffuse irradiance. For example, the Martin-Ruize model was developed (I think, they don't say) by approximating a physics-based equation (akin to the physical IAM model) and was validated (this is clear) by using approximately collimated light.
The table below indicates a model "type" as either direct or diffuse, presumably, to inform a user how the model should be applied.
Would "Conceptually, IAM is the fraction of incident direct or diffuse light" be acceptable? That alleviates my concern. I'm adding "Conceptually" because some models may not have developed using transmittance values, but using Isc or some surrogate instead.
There was a problem hiding this comment.
Would "Conceptually, IAM is the fraction of incident direct or diffuse light" be acceptable?
I like it. I will make the edit.
| +-------------------------------------------+---------+-------------------------------------------+ | ||
| | :py:func:`~pvlib.iam.physical` | direct | Physics-based; optional AR coating | | ||
| +-------------------------------------------+---------+-------------------------------------------+ | ||
| | :py:func:`~pvlib.iam.sapm` | direct | Can exhibit "wiggles" in the curve | |
4 participants
[ ] Closes #xxxx[ ] Tests added[ ] Updates entries indocs/sphinx/source/referencefor API changes.docs/sphinx/source/whatsnewfor 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.remote-data) and Milestone are assigned to the Pull Request and linked Issue.Continuing in a broader thrust of developing our user guide section. Previously:
See also:
Docs build: https://pvlib-python--2683.org.readthedocs.build/en/2683/user_guide/modeling_topics/iam.html