-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add spectral mismatch model comparison table #2353
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
Questions: How many cell technologies is too many to list? I think after 2 or 3, it might be best just to write "multiple"? |
I don't think links to the input definitions add much value. It would be easier to read the list of inputs if the list had one input on each line, rather than a comma-separate text paragraph. It doesn't seem very helpful when most "Cell technology" fields have a value of "Multiple". I'd use the vertical real estate to list all the cell technologies, except for 'sapm' and 'mismatch_field' which aren't specific to a cell type. The SAPM model is specific to a module product, not to a cell type. I think "Data source" doesn't add much here. The primary use is for a modeler looking to select a model. Data used for development and validation can be relegated to the references. |
@RDaxini it looks like you're thinking to create a single page to house all comparison tables, is that right? In #2329 I was imagining these tables would live in pages dedicated to the relevant modeling topic. For example, the table in this PR would be one component of a broader page explaining pvlib's functionality related to spectrum and spectral mismatch. Similarly, the transposition model table would be in a page talking about the irradiance models. I still think that's a good approach, although of course I am interested in hearing opposing viewpoints. |
@kandersolar you're too fast again, haha. I went for single page originally because we did not have subsections at that time, but I think 0be2e46 just before your comment should have fixed this in line with your suggestion. We now have one main subsection called model comparisons, and then there will be individual subsubsections explaining the functionality and comparing models. Have a look, let me know if that's what you had in mind. Or did you mean a whole subsection for "spectrum", another for "irradiance", rather than a subsection called "model comparison" (can be renamed) with subsections for those topics (spectrum, irradiance, etc.)? |
Ok I see, nice. I suggest merging the |
@kandersolar, how about 7e79344? Aside, related: the user guide folder could benefit with some organization of the files, what do you think? I was considering opening a separate issue to seek opinions on categorizing those files into folders, perhaps folders aligned with the subsections perhaps... not urgent/major but the thought came to mind while working on this |
I am +1 to where it's going now.
+1 to this as well |
Converted from draft. I think we're ready for a full review now. |
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 like it. What do you think about reworking the structure to look like this?
Source code:
.. currentmodule:: pvlib.spectrum
+-----------------------------------------------------+-----------------------------+---------+---------+------+------+------+------------+-----------+
| Model | Inputs | Generic coefficient values available? | Reference |
+ + +---------+---------+------+------+------+------------+ +
| | | mono-Si | poly-Si | CdTe | CIGS | a-Si | perovskite | |
+=====================================================+=============================+=========+=========+======+======+======+============+===========+
| :py:func:`Caballero <spectral_factor_caballero>` | :term:`airmass_absolute`, | yes | yes | yes | yes | yes | yes | [2]_ |
| | :term:`precipitable_water`, | | | | | | | |
| | :term:`aod` | | | | | | | |
+-----------------------------------------------------+-----------------------------+---------+---------+------+------+------+------------+-----------+
| :py:func:`First Solar <spectral_factor_firstsolar>` | :term:`airmass_absolute`, | | yes | yes | | | | [3]_ |
| | :term:`precipitable_water` | | | | | | | |
+-----------------------------------------------------+-----------------------------+---------+---------+------+------+------+------------+-----------+
| :py:func:`JRC <spectral_factor_jrc>` | :term:`airmass_relative`, | | yes | yes | | | | [6]_ |
| | :term:`clearsky_index` | | | | | | | |
+-----------------------------------------------------+-----------------------------+---------+---------+------+------+------+------------+-----------+
| :py:func:`PVSPEC <spectral_factor_pvspec>` | :term:`airmass_absolute`, | yes | yes | yes | yes | yes | | [5]_ |
| | :term:`clearsky_index` | | | | | | | |
+-----------------------------------------------------+-----------------------------+---------+---------+------+------+------+------------+-----------+
| :py:func:`SAPM <spectral_factor_sapm>` | :term:`airmass_absolute` | | | | | | | [4]_ |
+-----------------------------------------------------+-----------------------------+---------+---------+------+------+------+------------+-----------+
Can we work in a shout-out to: https://datahub.duramat.org/dataset/module-sr-library? Also wondering about chronological ordering of the models so new ones will get added at the end. |
In addition to @kandersolar suggestion I want to suggest:
If you want to change the widths of each column, you may need to use the
Point 4. makes this table too wide: Details
An idea to make it work would be to transpose it: Details
This table does not have point 5 applied. Spreadsheet file: pv-dax-spectrum-comparison.ods Btw, I'm using this generator here: https://www.tablesgenerator.com/text_tables |
I used the ticks at first too, but my editor did not display them in monospace font, so it messed up the table alignment. I switched to "yes" out of irritation. I am +1 to the unicode ticks, as long as someone else makes them work ;) |
I did have that mismatch too. DejaVu Sans Mono fixes it and looks great. Uniglyph does too, but it's too pixeled for me. I had DejaVu already installed in Windows, IDK if that was past me, some program I had installed or Microsoft getting something right. |
I mildly prefer the "models in column" format. I think it is more likely to add new models (rows) than to add columns. "Default parameters" > "Generic parameters" for me. I also like the link to pvlib terms, as long as each term has its own row so I'm not reading a paragraph of variable names. |
Thanks all for the reviews. I will get back onto this PR soon. |
@adriesse, a suggestion: 298caa8. Your thoughts? (note Ref. was changed to Reference in the next commit) |
Having reread the whole page now, I think it would benefit from an introduction that clearly separates functions/models that actually use spectrally-resolved data vs. those that don't. Then I think the reference will also fall into place more naturally. |
Tests addedUpdates entries indocs/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.Build: https://pvlib-python--2353.org.readthedocs.build/en/2353/user_guide/spectrum.html