-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add guidance about temperature modeling to User Guide #2591
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
base: main
Are you sure you want to change the base?
Conversation
|
One thing that could be added is the parameter conversion from one model to another. Please leave this open for a few weeks as I'd like to comment more. |
Co-authored-by: Cliff Hansen <[email protected]>
|
Could consider listing |
Co-authored-by: RDaxini <[email protected]>
…r/pvlib-python into userguide-temperature
|
This PR has been open for a few weeks now. I suggest we merge it on Monday the 7th if there are no objections. |
| Temperature models predict one of two quantities: | ||
|
|
||
| - *module temperature*: the temperature as measured at the back surface | ||
| of a PV module. Easy to measure, but usually less |
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.
| of a PV module. Easy to measure, but usually less | |
| of a PV module. Easy to measure, but usually marginally less |
| irradiance, ambient temperature, and wind speed. Each model also takes | ||
| a set of parameter values that represent how a PV module responds to | ||
| those inputs. Parameter values generally depend on both the PV | ||
| module technologies and the mounting conditions of the module. |
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.
| module technologies and the mounting conditions of the module. | |
| module technologies, the mounting conditions of the module | |
| and on any weather parameters that are not included in the model. |
| those inputs. Parameter values generally depend on both the PV | ||
| module technologies and the mounting conditions of the module. | ||
|
|
||
| Another way to classify temperature models is whether they account for |
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.
| Another way to classify temperature models is whether they account for | |
| Another aspect of temperature models is whether they account for |
| - :py:func:`~pvlib.temperature.generic_linear`: a generic linear model form, | ||
| equivalent to several conventional temperature models. | ||
|
|
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 think this one could go in the table.
| and several additional sets of temperature model parameter values are | ||
| available in :py:data:`pvlib.temperature.TEMPERATURE_MODEL_PARAMETERS`. | ||
| However, these generic values may not be suitable for all modules and mounting | ||
| configurations. |
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.
| configurations. | |
| configurations. It should be noted that using the default parameter values for each | |
| model generally leads to different modules temperature predictions. This alone | |
| does not mean one model is better than another; it's just evidence that the measurements | |
| used to derive the default parameter values were taken on different PV systems in different | |
| locations under different conditions. | |
| configurations. | ||
|
|
||
| Module-specific values can be obtained via testing, for example following | ||
| the IEC 61853-2 standard. |
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 IEC 61853-2 standard. | |
| the IEC 61853-2 standard for the Faiman model; however, such values still do not capture | |
| the dependency of temperature on system design and other variables. |
| Parameter values for one model (e.g. ``u0``, ``u1`` for :py:func:`~pvlib.temperature.faiman`) | ||
| can be converted to another model (e.g. ``u_c``, ``u_v`` for :py:func:`~pvlib.temperature.pvsyst_cell`) | ||
| using :py:class:`~pvlib.temperature.GenericLinearModel`. |
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 would move this to before the preceding paragraph
| can be converted to another model (e.g. ``u_c``, ``u_v`` for :py:func:`~pvlib.temperature.pvsyst_cell`) | ||
| using :py:class:`~pvlib.temperature.GenericLinearModel`. | ||
|
|
||
| Currently, pvlib provides no functionality for fitting parameter values |
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.
You could consider including references to:
- The sandia data set for temperature model fitting, and it's accompanying notebook
- My paper on model fitting from last years PVSEC.
[ ] 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--2591.org.readthedocs.build/en/2591/user_guide/modeling_topics/temperature.html