Skip to content

Add polo-smm #2491

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Add polo-smm #2491

wants to merge 6 commits into from

Conversation

jesuspolo
Copy link

@jesuspolo jesuspolo commented Jun 25, 2025

Add the polo spectral model for BIPV facades

  • [ ] Closes #xxxx
  • I am familiar with the contributing guidelines
  • Tests added
  • Updates entries in docs/sphinx/source/reference for API changes.
  • Adds description and name entries in the appropriate "what's new" file in 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`).
  • New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
  • Pull request is nearly complete and ready for detailed review.
  • Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Adding the spectral model for estimating spectral mismatch for BIPV in facades according to ref: Polo, J., Sanz-saiz, C., 2025. Development of spectral mismatch models for BIPV applications in building façades Abbreviations : Renew. Energy 245, 122820. https://doi.org/10.1016/j.renene.2025.122820

Add the polo spectral model for BIPV facades
Copy link
Member

@AdamRJensen AdamRJensen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jesuspolo Thanks for opening your first PR!

I've made some formatting changes, to make sure that the code adheres to the standard flake8 conventions. If you go to the "File changed" tab of this PR, then you can click "Add suggestion to batch" one by one and then commit all of them at once.

@AdamRJensen
Copy link
Member

@jesuspolo As you can see, the Python Flake8 linter action (shown at the bottom of this PR) failed, due to some formatting not adhering to the Flake8 standard (I guess I didn't manage to spot all of them). If you click the action you can see what still needs to be fixed.

Whenever you make changes online and you switch to working on GitHub Desktop, you need to remember to click the "Fetch origin" button to make sure you have the latest changes locally.

@jesuspolo
Copy link
Author

Hi Adam, I don't know how to solve the problems, I've seen they are about line too long and spaces, but I don't know how to edit the code and solve (sorry for my few capabilities)

c = {
'asi': (0.0056, -0.020, 1.014),
'cigs': (-0.0009, -0.0003, 1),
'cdte': (0.0021, -0.01, 1.01),
'monosi': (0, -0.003, 1.0),
}

if module_type is not None:
if module_type is not None:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if module_type is not None:
if module_type is not None:

@echedey-ls echedey-ls added this to the v0.13.1 milestone Jun 25, 2025
Comment on lines 757 to 759
[1]. Polo, J., Sanz-saiz, C., Development of spectral mismatch models
for BIPV applications in building façades Abbreviations : Renew. Energy 245
,122820, 2025.:doi:`10.1016/j.renene.2025.122820`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[1]. Polo, J., Sanz-saiz, C., Development of spectral mismatch models
for BIPV applications in building façades Abbreviations : Renew. Energy 245
,122820, 2025.:doi:`10.1016/j.renene.2025.122820`
.. [1] J. Polo and C. Sanz-Saiz, 'Development of spectral mismatch models
for BIPV applications in building façades', Renewable Energy, vol. 245,
p. 122820, Jun. 2025,
:doi:`10.1016/j.renene.2025.122820`

This is the IEEE citation I get with Zotero.

albedo=0.2):
"""
Estimation of spectral mismatch for BIPV application in vertical facades.
Parameters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Parameters
Parameters

I think it won't render well in readthedocs without the margin.

----------
precipitable_water : numeric
atmospheric precipitable water. [cm]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

For consistency.

Copy link
Contributor

@echedey-ls echedey-ls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice PR @jesuspolo !
There are a bunch of tasks to fulfil so this new feature becomes available to users (most of them are in the PR body):

  • Reference it in docs\sphinx\source\reference\effects_on_pv_system_output\spectrum.rst (so it appears in the documentation, once done, we will be able to review the built docs that appear down below)
  • Add a whatsnew entry in docs\sphinx\source\whatsnew
  • Add tests - the better the exhaustive and the most edge-cases they check

Comment on lines +788 to +789
c_albedo = (0.0, 0.0, 1.0) # 0.2 albedo assumed
albedo = 0.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if this is intentional, but this will ignore whatever value the user provides. If it's intentional, the docstring does not reflect that albedo is only used when the type is given, and assumed 0.2 when given the coefficients.

jesuspolo added a commit to jesuspolo/pvlib-python that referenced this pull request Jun 27, 2025
Add test of use of spectral_factor_polo fuction (pull pvlib#2491)
Copy link
Contributor

@RDaxini RDaxini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this contribution @jesuspolo
I just made a couple of small suggestions for changes to the docstring: rephrasing the summary line and linking the parameter terms to their respective definition on the nomenclature page.
You might already be working on this anyway, but I wanted to add that besides the test you already wrote, it would be good to add tests for edge cases like Echedey suggested. For example, how the function handles inputs such as NaN and 0, or how it handles inputs of different data types such as series or dataframe. I'm happy to help write and/or review such tests if you need, just ask.

Comment on lines +725 to +730
airmass_absolute : numeric
absolute (pressure-adjusted) airmass. [unitless]
aod500 : numeric
atmospheric aerosol optical depth at 500 nm. [unitless]
aoi : numeric
angle of incidence. [degrees]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to link these terms to their respective definitions on the nomenclature page. Not all definitions on that page have been fully developed, but we can link over to them anyway and they will soon be updated.

Suggested change
airmass_absolute : numeric
absolute (pressure-adjusted) airmass. [unitless]
aod500 : numeric
atmospheric aerosol optical depth at 500 nm. [unitless]
aoi : numeric
angle of incidence. [degrees]
airmass_absolute : numeric
absolute (pressure-adjusted) airmass. See :term:`airmass_absolute`. [unitless]
aod500 : numeric
atmospheric aerosol optical depth at 500 nm. [unitless]
aoi : numeric
angle of incidence. See :term:`aoi`. [degrees]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For aoi, I think the definition here should be angle of incidence on the vertical surface, and maybe we don't link to the generic aoi term.

Comment on lines +740 to +741
albedo
Ground albedo (default value if 0.2). [unitless]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
albedo
Ground albedo (default value if 0.2). [unitless]
albedo
Ground albedo (default value if 0.2). See :term:`albedo`. [unitless]

* ``'monosi'`` - anonymous sc-si module.
* ``'cigs'`` - anonymous copper indium gallium selenide module.
* ``'asi'`` - anonymous amorphous silicon module.
albedo
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was more wondering if the code allows for albedo being passed in as a time series?

+1 to making this possible if not already

altitude, module_type=None, coefficients=None,
albedo=0.2):
"""
Estimation of spectral mismatch for BIPV application in vertical facades.
Copy link
Contributor

@RDaxini RDaxini Jun 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Estimation of spectral mismatch for BIPV application in vertical facades.
Estimate the spectral mismatch for BIPV application in vertical facades.

I think the imperative form is standard practice for the summary line

One of the following PV technology strings from [1]_:

* ``'cdte'`` - anonymous CdTe module.
* ``'monosi'`` - anonymous sc-si module.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* ``'monosi'`` - anonymous sc-si module.
* ``'monosi'`` - anonymous sc-si module.

What is "sc-si"? Is this a typo and should be "monocrystalline Si"?

Comment on lines +744 to +745
user-defined coefficients, if not using one of the default coefficient
set via the ``module_type`` parameter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
user-defined coefficients, if not using one of the default coefficient
set via the ``module_type`` parameter.
user-defined coefficients, if not using one of the coefficient
sets via the ``module_type`` parameter.

Comment on lines +725 to +730
airmass_absolute : numeric
absolute (pressure-adjusted) airmass. [unitless]
aod500 : numeric
atmospheric aerosol optical depth at 500 nm. [unitless]
aoi : numeric
angle of incidence. [degrees]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For aoi, I think the definition here should be angle of incidence on the vertical surface, and maybe we don't link to the generic aoi term.

if module_type is not None and coefficients is not None:
raise ValueError('Only one of `module_type` and `coefficients` should '
'be provided')
am_aoi = pvlib.atmosphere.get_relative_airmass(aoi)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it correct that aoi = 90 - zenith? I think so, because the surface is assumed to be vertical. If that's the case, then I think requesting zenith rather than aoi as input would be significantly easier for a user to understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants