-
Notifications
You must be signed in to change notification settings - Fork 73
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
Feat/inverter availability #131
Conversation
Picking this PR up again to implement the methods in Anderson & Blumenthal "Overcoming communications outages in inverter downtime analysis", PVSC 47 |
It's the difference between |
@kanderso-nrel I suggest adding the reference for your work on the availability algorithm on the overview docs page |
* Update overview * reword * heading update
Done (despite brain fart of "soiling" in the commit message). I also took the liberty of adding one for the degradation section. |
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 think this is looking good. Here are a couple suggestions.
Co-authored-by: Michael Deceglie <[email protected]>
…rdtools into feat/inverter_availability
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.
LGTM Thanks for putting this together @kanderso-nrel !
Should we use double backticks in the tables describing dataframes? |
…t nan/zero values instead of the first positive value
@mdeceglie I added an "other uses" section in the notebook with an example like we discussed in the meeting earlier today, of running the entire thing at the inverter level instead of at the system level: https://rdtools--131.org.readthedocs.build/en/131/system_availability_example.html#Other-use-cases The other option (omitting the cumulative energy data) would require some more in-depth changes to get working, so I think we should leave it as a possible future improvement. Also made a small change to how the outage bounds are reported; the end of the outage was previously being reported as the timestamp of the first non-outage value rather than the last outage value. This was introducing a small error into the calculated actual energy during the outage, because it was including that single interval of energy after the outage. |
Code for inverter availability calculations. Two main functions:
Detecting offline inverters should be easy, except communication outages make it tricky. The code assumes that meter-level data is reliable and never has comms outages but is mostly robust to inverter comms outages. I believe the only thing it will fail at (assuming good meter data) is when some inverters are truly offline and some are only non-communicative. In that case the code says that they're all offline.
For lost production, the preferred method is inter-inverter comparison -- examining how inverters have performed relative to each other in the past and assuming the same relative performance can be used to calculate lost production when some inverters are offline. If all inverters are determined to be offline, an expected_power signal provided by the user is used to determine lost energy. If there is no expected power data for the outage (eg the entire system is offline, so there's no weather data), a user-provided 12x24 typical production profile is used instead.
Documentation links:
Edit for anyone reading this -- the above info is mostly about the original implementation and is largely out of date.
__init__.py
(waiting for Feat/monthly soiling metrics #193 to get merged with the whatsnew file)