PyPSA / PyPSA/atlite

Rooftop PV yield

Open
#429 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: low type: enhancement
Dominant language
Python
Stars
402
Forks
134
PR merge metrics
No merged PRs in 30d

Description

Problem

We notice in several PyPSA-Eur runs for ongoing projects that PyPSA-Eur favors rooftop solar. There are multiple factors contributing to this, but an important issue here is that model currently uses the same solar profile for both utility-scale and rooftop PV, which is not ideal.

Rooftop PV systems are installed at suboptimal azimuth and tilt angles due to roof orientation, resulting in lower overall generation per MW installed and a flatter generation profile compared to utility-scale PV. NB there also factors like partial shading from buildings or trees, higher operating temperatures (as roofs trap heat), and dust accumulation.

What could be done

To capture profile: We might consider implementing a feature to generate distinct rooftop PV time series (eventually using some heuristics). One potential implementation (w/o deep thought) could be introducing optional randomization in panel slope and azimuth (attributes of Atlite's orientation parameter for PV calculation). For example, assigning azimuth values somewhere in range of S-W/South/S-E orientations and applying some variations in a slope within a reasonable bound.

A key thing upfront is whether a way of constructing smth like an average time-series across N simulations sampling from pseudo-random orientations is a good engineering solution, or a more clever approach exists?

To capture shading/heat/dust: Well, I think one can "downscale" the profile based on some empirically observed average yield disparity.

For context, some empirical data

For example this paper from LUT folks says system-weighted average yield disparity of rooftop VS utility-scale-optimally-tilted panel is at 18%.

a bit surprisingly for me, sub-optimal orientation is less of a contributing factor for residential rooftop than shading (same paper, figure 3):

How to proceed

To move forward, I'd ping @coroa and @FabianHofmann with the following:

  • have you seen Atlite-based solutions for rooftop PV? If yes, we may not need to reinvent a wheel.
  • If not, do you think the approach described above reasonable? Or you know about any better way to proxy rooftop PV generation?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing Atlite's PV calculation path and the orientation parameter, then compare any existing rooftop-PV approaches referenced by the issue. Done requires an agreed engineering approach for distinct rooftop time series, including how orientation variation and yield disparity should be represented.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.