Skip to content
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

Default MAX_X_GROUND is too small for simulations with many rows #12

Open
kandersolar opened this issue Aug 14, 2023 · 0 comments
Open
Labels
bug Something isn't working

Comments

@kandersolar
Copy link
Member

Originally posted in SunPower/pvfactors#135:

By adjusting the gcr, pvrow_width, and n_pvrows inputs it is possible to simulate arrays covering an arbitrarily large distance. For typical inputs (e.g. n_pvrows=3, pvrow_width=4, gcr=0.4), the spanned distance is relatively small, but it's not wholly unreasonable to model a system with, for example, n_pvrows=15, gcr=0.5, pvrow_width=6, in which case the simulated array spans over 100 meters between the first and last rows. The reason this matters is because the default value of MAX_X_GROUND is 100, so the farthest segments in the scene get ignored entirely in the above extreme example. This leads to strange effects like the following, where legend entries indicate pvrow_height and pvrow_width:

image

Because the row width to height ratio is constant across all three variants, I'd expect the returned irradiance values to be identical. However, they are not, and it's due to an increasingly large portion of the array crossing that MAX_X_GROUND boundary as the array scale increases. By setting MAX_X_GROUND to a number large enough to capture the entire array, the difference disappears and the three curves overlap as expected. Here is some code to reproduce:

Click to expand!
from pvfactors import config
# uncomment these lines to make the three lines overlap
#config.MAX_X_GROUND = 1e3
#config.MIN_X_GROUND = -config.MAX_X_GROUND

import pvfactors
from pvfactors import geometry
import pvlib
import pandas as pd
import matplotlib.pyplot as plt

times = pd.date_range('2019-12-21 11:30', '2019-12-21 13:05', freq='5T', tz='Etc/GMT+5')
loc = pvlib.location.Location(40, -80)
sp = loc.get_solarposition(times)
cs = loc.get_clearsky(times)
tr = pvlib.tracking.singleaxis(sp.zenith, sp.azimuth, gcr=0.5)

data = {}
for height, width in [(1.5, 2.0), (3.0, 4.0), (4.5, 6.0)]:
    ret = pvlib.bifacial.pvfactors_timeseries(sp.azimuth, sp.zenith,
                                              tr.surface_azimuth, tr.surface_tilt,
                                              180, times, cs.dni, cs.dhi,
                                              0.5, height, width, 0.2,
                                              n_pvrows=15, index_observed_pvrow=7)
    data[f'({height}, {width})'] = ret[1]
pd.DataFrame(data).plot(figsize=(7, 4))
plt.ylabel('Rear-Side Irradiance [W/m2]')

For reference, the above plot was generated with pvfactors 1.5.1 and pvlib 0.8.1.


The above scenario is certainly unusual, but I don't think it's out of the realm of reasonable usage. Here are some ideas:

  • Increase the MAX_X_GROUND and MIN_X_GROUND values. I'm not sure what consequences this would have, if any, for more typical simulations.
  • Emit a warning if the simulated array is large enough for the default values to be problematic, for example if any of the rows extends beyond the limit, or maybe any of the ground shadows or something.
  • Mention in the documentation somewhere how to increase these limits on the user's end like I've done in the above example. I think pvfactors.config is not mentioned anywhere in the sphinx docs, though maybe I've just missed it.

cc @spaneja

@kandersolar kandersolar added the bug Something isn't working label Aug 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant