Add guidance about temperature modeling to User Guide #2591
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 <cwhanse@sandia.gov>
|
Could consider listing |
Co-authored-by: RDaxini <143435106+RDaxini@users.noreply.github.com>
…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. |
| 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.
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.
There was a problem hiding this comment.
I'm not sure pointing to external functionality makes sense for these pages. Let's save that for a potential follow-up.
There was a problem hiding this comment.
What kind of "sense" are we looking for? Pointing to solutions takes the edge off the foregoing limitation a bit. I think the new spectrum section has similar pointers. But I leave the decision to you.
Co-authored-by: Anton Driesse <anton.driesse@pvperformancelabs.com>
Co-Authored-By: Ioannis Sifnaios <88548539+IoannisSifnaios@users.noreply.github.com>
| 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.
What kind of "sense" are we looking for? Pointing to solutions takes the edge off the foregoing limitation a bit. I think the new spectrum section has similar pointers. But I leave the decision to you.
| +----------------------------------------------+--------+------------+----------------+---------------------+------------+-----------------------+ | ||
| | :py:func:`~pvlib.temperature.fuentes` | either | ✓ | ✓ | ✓ | ✓ | | | ||
| +----------------------------------------------+--------+------------+----------------+---------------------+------------+-----------------------+ | ||
| | :py:func:`~pvlib.temperature.generic_linear` | cell | | ✓ | ✓ | ✓ | | |
There was a problem hiding this comment.
I see the doc string says cell temperature, but the model is really agnostic as in principle all the others are too. I recommend putting "either" here possibly flag the docstring to be changed. In the class description module temperature is used.
echedey-ls
left a comment
echedey-ls
left a comment
There was a problem hiding this comment.
Very informative. LGTM. I don't feel like I would have any questions after reading it, within scope of these docs.
| Temperature models estimate these quantities using inputs like incident | ||
| 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, the mounting configuration of the module, | ||
| and on any weather parameters that are not included in the model. | ||
| Note that, despite models conventionally being associated with either | ||
| cell or module temperature, it is actually the parameter values that determine | ||
| which of the two temperatures are predicted, as they will produce the same | ||
| type of temperature from which they were originally derived. |
There was a problem hiding this comment.
I suggest splitting this in two paragraphs, e.g. at line 25.
| following table: | ||
|
|
||
| +----------------------------------------------+--------+------------+---------------------------------------------------------------------------+ | ||
| | Model | Type | Transient? | Inputs | |
There was a problem hiding this comment.
| | Model | Type | Transient? | Inputs | | |
| | Model | Type | Transient? | Weather inputs | |
There are many other unlisted inputs that could become a dealbreaker when selecting a model. For the sake of precision.
I also wonder whether those two fully-tick-marked columns are really adding some value to the reader, but I don't see much room for edits in there.
7 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--2591.org.readthedocs.build/en/2591/user_guide/modeling_topics/temperature.html