Add initial storage support

[Peque]

Abstract

The storage support proposal for NumFOCUS Small Development Grants was recently accepted.

This issue aims to track progress of the development and discussions related to the proposal.

Goal

The goal of this project is to make a first step in supporting storage within pvlib. To do so, it
aims to complete at least:

• One use-case (PV for self-consumption)
• One configuration (i.e.: behind-the-meter)
• One technology (i.e.: lithium-ion batteries)
• One connection (i.e.: DC)
• One model (i.e.: NREL)
• One dispatch (i.e.: store all excess non-self-consumed energy)

Phases

1. Use case refinement phase
   a. Reading and understanding the state-of-the-art battery models and use cases
   b. Talking to stakeholders/experts to understand the most needed use case (PV installers, HW manufacturers and other professionals)
   c. Adjustment of the scope, first use case and detailed planning for the implementation phase
2. Implementation of the first prototype
   a. Public discussion with pvlib maintainers for an initial candidate API
   b. Implementation of the first functions and tests
   c. Validation of the first use case with well-known data
3. Integration
   a. Adjustments to the API for a ready-to-be-integrated version
   b. Project documentation update (API, storage, example code)
   c. Fix any issues or comments in the pull-request dis

Timeline

• October 2021: Notification (no phase or work load associated)
• November 2021: Use case refinement phase
• December 2021 - January 2022: Implementation phase
• February-March 2022: Integration phase

[Peque]

So, the first step is to understand the state-of-the-art battery models and use cases. I will start with:

• The SAM videos about battery models.

Any other interesting readings are more than welcome! 😊

Another goal is to talk to different stakeholders to understand the current market needs and technologies. Also, this would create awareness around pvlib and, maybe, attract more contributors. 🚀

I will start with people I know I have a higher likelihood of response (people I'm already connected with in the Spanish/EU market):

• ASEALEN (Spanish Energy Storage Association)
• A couple of PV installers here in Spain that I know are installing batteries at least for residential use cases (probably the first use-case to cover) to know which technology/configuration/connection they are using and they plan to use in the near future
• A couple of PV distributors here in Spain that I know are selling batteries, to know which technology/configuration/connection they are selling the most today, and which they plan to sell in the near future

If you know other people that you think it could be interesting to meet with, please share their contact or introduce us! It is always much easier to organize a meeting when you are introduced by someone or if you already know that person. 😉

In particular, I think it could be interesting to meet with some hardware manufacturer. Also, meeting someone outside the EU would be good to avoid geographic bias.

[btaute]

With respect to further reading / reference material:

• I think it would be great to explore potential ways to incorporate the EPRI STORAGE-VET or DER-VET models in this project.
• There are also some interesting papers resulting from the DER-CAM software development by Berkely Lab.

With respect to conversations:

• I have 5 years' experience developing utility scale solar and storage facilities and microgrids globally (but mostly in the US), and I would be happy to discuss the ways in which I've modeled these systems in the past and how this project could benefit developers.
• I'd also be happy to make some connections to other people in the project development / operations industry.

[Peque]

@btaute Thanks for your suggestions and interesting pointers! 😊

May I contact you using the Gmail address you use on your commits?

[btaute]

Ya, that would be great.

[cwhanse]

So, the first step is to understand the state-of-the-art battery models and use cases. I will start with:

There is a lot of battery-related content going into the next release of SAM, I believe. @janinefreeman perhaps you could point @Peque to a few of the key algorithms?

[janinefreeman]

Hi all! We have many updates to the battery models and dispatch algorithms going into SAM for the next release, and we would love to make sure the pvlib capabilities are closely aligned with SAM's capabilities. @Peque we're happy to meet with you to help figure out the best way to make this happen, and which algorithms may be of interest for your first steps. My colleagues Darice @dguittet and Brian @brtietz are great resources for the battery modeling pieces of SAM as well. @cwhanse can send an email intro as needed! Thanks!

[Peque]

Thanks a lot @janinefreeman, that would be great! 😊

[williamhobbs]

I agree with @btaute about looking at EPRI's DER-VET/StorageVET. I could make email introductions with EPRI contacts if that has not already been done and is of interest. And of course I agree that SAM is an excellent resource.

I can be available to provide any input that might be useful. I have an electric utility and IPP/developer background. My pvlib experience is a little light, but I have been a pretty heavy SAM user over the years.

This is likely outside your current scope, but if future work will involve battery dispatch for PV output smoothing, https://github.com/epri-dev/PV-Ramp-Rate-Smoothing could be worth looking at. It will be in NREL SAM soon. A 2021 IEEE PVSC preprint should be available soon, or I can send a copy over email.

This is also likely outside your scope, but I'd be interested in discussing things such as modeling real-world considerations of needing both solar and load forecasts for for optimized dispatch if variable utility pricing is included. Hypothetical example: it's 10AM, the battery just charged with some excess energy, and now load drops below solar. Do you discharge it now when time of use rates are low, or store that energy until afternoon when TOU rates are high but miss out on capturing additional excess energy if it becomes available? If you have a forecast of excess energy between now and then, you can make a better decision.

[cwhanse]

I think functions that represent automated controls, like ramp rate smoothing, could be considered within the scope of pvlib. An algorithm to optimize storage dispatch based on forecasts and TOU rates strikes me as scope for another project.

[Peque]

I leave here a couple of notes I have taken during the use case refinement phase. With the intention of starting with the next phase (implementation of the first prototype) this month. 😊

Market analysis

So, one of the goals for this initial phase was to analyze the market and talk to different stakeholders. During November I had the opportunity to go to a national professional fair about renewables. There, I had the opportunity to talk to PV installers, hardware distributors and hardware manufacturers.

With the idea of covering a first use-case for residential self-consumption (behind-the-meter, small PV, stationary storage), this is the feedback I was provided with:

• LFP is currently the preferred chemistry
• LFP adoption is growing in stationary applications, specially in residential self-consumption installations
• It seems adoption is growing even in non-stationary applications like EVs
• Professionals see LFP as the preferred technology in the near future
• Implemented by many manufacturers like BYD, Huawei, Sonnen, Enphase... and other "local" manufacturers like Pylontech, Victron and Cegasa.
• Selling points of LFP:
  • Chemical and thermal stability (i.e.: safety for in-house storage)
  • Easier to manufacture/recycle (cobalt-free)
  • Longer useful life (more cycles)
  • Very flat voltage discharge curve
• DC-connected storage is the norm

This feedback may of course be biased, since we are talking about a national fair. It may extrapolate better to other countries in the EU market but worse to other markets around the world.

In particular, I was told that the use of DC-connected storage is not so common in other markets. For example, in the US it seems it is more common to use AC-connect batteries (i.e.: Tesla batteries). This may be influenced by the local regulations. In Spain, for example, you may get grants if you use DC-connected batteries, since they maximize self-consumption and you cannot charge them using grid power.

Models and code reuse

@cwhanse and @janinefreeman were very kind to organize a meeting in order to discuss this initial implementation and answer some questions. @dguittet and @brtietz (from NREL) were also present. They have been directly involved in the storage developments within SAM. ❤️

Due to the time constraints of this project we agreed that what makes sense (and is viable) is to integrate the capabilities of SAM (i.e.: battery models) by adding it as an optional dependency to pvlib. Cliff agreed that was okay and the goal of pvlib is always to support different/multiple models. So the idea here is to define a flexible API that could allow the integration of other models/dependencies/implementation in the future.

SAM implements 2 battery models:

• Battery: An holistic model. It includes not only the battery model, but also power flow accounting (where the energy is going by every time step), losses, replacements... But does not allow to run on arbitrary time steps or time series, it requires an hourly full-year (8760 data points) series.
• BatteryStateful: it is just the battery management system (without the losses and ancillary models like power flow). All it does is takes the input and output at every time step, but it allows arbitrary time steps.

The initial pvlib implementation will be focused on supporting a custom dispatch series (i.e.: delegate any energy flow optimizations). Although for this use case the BatteryStateful strikes as more flexible, performance may be an issue. These were the results of my performance tests, in both cases using a custom dispatch with a full-year hourly series (8760 data points):

• The battery model run in a couple hundred milliseconds
• The battery-stateful took a couple milliseconds for each iteration (for each call to .execute()), which resulted in a total simulation time of over 15 seconds

Pending confirmation in case there could be other factors affecting the results, this could be due to the Python-to-C-to-Python interfacing. I noticed the .Controls.input_power parameter of the battery-stateful model needs to be numeric (i.e.: not an array/tuple), so I'm guessing iterating at the Python level is a must to run this model with PySAM.

Since the idea is to cover an initial use-case for residential self-consumption, simulations are expected to span over a period of multiple years (10+, up to 25). 15 seconds per year would mean minutes to wait for the results, which sounds unreasonable.

I will, therefore, start with the Battery model, even if ignoring or not using many of its ancillary models/capabilities for this initial implementation in pvlib.

This comes with another restriction: AC connection. Supporting DC-connected batteries with the Battery model would require changes in SAM's C++ code.

AC connection sounds reasonable for a first implementation in pvlib, since DC connection would require changes in the inverter model as well, to take into account inverter constraints when it comes to the interter-to-battery connection and power flow. For what I know, no inverter models in pvlib currently contemplate DC-connected storage (and SAM, using the Sandia model, does not either).

Other use cases

Of course this is just the first step in adding storage support, so other use cases can be added later on. @btaute @williamhobbs Be sure I will contact you for those involving larger storage for utility-scale or front-of-meter installations. 😊

[mikofski]

Thanks @Peque, baby steps, this is just a starting point. We can use this as a launching point for future additions like DC-coupled or relaxing hourly time constraints. I have also been doing a lot more PV+BESS modeling lately so I may be able to contribute more. Another thing I would suggest is that you could also contribute to SAM/SSC as well. Perhaps that's out of scope for the small dev grant, but something to keep in the back of your mind.

[Peque]

Thanks for your support @mikofski!

I'm starting to fear the same (that at some point, changes to SCC may be required). While I have experience with Python programming, and even some with embedded C, I still think C++ is one of the most difficult programming languages. 😂

Anyway, the team at NREL was very welcoming and open to external contributions. So that compensates the programming language barrier. 😊

[wholmgren]

Thanks to everyone for their time and efforts so far! @Peque sorry if I missed this, but what is the value in wrapping pySAM? Or why not just use/improve PySAM directly? Perhaps a draft PR would make this obvious, so my apologies if I'm both too late and too early to these discussions.

From my perspective, a slow but reliable and reasonably complete python implementation would also be welcome. Once we're happy with the algorithms, I suspect numba could improve performance relatively easily.

[adriesse]

Thanks for the updates @Peque. At a very high level, what information would be the inputs and output to/from SAM?

[adriesse]

Apparently @wholmgren was typing while I was thinking similar things. Somethings really basic in native pvlib would be my preference, although I recognize there may be users who have different needs.