LCOE function

[eccoope]

A function that calculates LCOE would be a great addition to pvlib-python, and could be one of the first functions in a new class - i.e. pvlib.financial, which could provide structure and support for TEA analyses.

The function itself should be minimal and exclude preprocessing to encourage a modular workflow offering user flexibility. Parameters might be an array of annual energy production values [kWh], an array of annual capital costs, and an array of annual maintenance costs; output would be a single float [cents/kWh].

The workflow could incorporate functions from the pvsystem class to generate the annual production array - i.e. PVWatts or SAPM - or use raw production data. And there may also be an audience for preprocessing functions in this financial class - ex. a function that, given CAPEX, # of modules, debt fraction, interest, ect, returns the annual capital cost array used as a parameter for the LCOE function.

[kandersolar]

I thought I remembered the idea of adding "money" functions to pvlib being met with hesitation when it came up previously. I am not a finance person, so please forgive my ignorance: are these kinds of financial calculations standardized to the extent that a pvlib implementation would be suitable for actual (non-"toy") use cases? My uninformed impression of real-world financial models is that everyone has their own "secret sauce" with too much variation for pvlib to reasonably accommodate. Maybe that's way off base and there is indeed one LCOE definition to rule them all.

Separately from the code's utility, I doubt pvlib is the right place for it, at least in part because I don't think any of the pvlib maintainers do financial calculations themselves. If we wouldn't be users of that code, I don't think we're the right people to maintain it. I suppose I can only speak for myself here, but I certainly wouldn't feel as confident maintaining a pvlib.financial as I would any of the other pvlib modules.

[mikofski]

I’m not so quick to dismiss it. While I agree with many points Kevin makes, for example I don’t know much about financing and don’t use these equations often, as long as the contributors agree to help maintain I think there could be a place in pvlib to incubate them for now, perhaps in a contrib folder. While I also agree financial calculations can be very bespoke, there are references to rely on, and in general common formulations. But most importantly including them I believe is important for 3 reasons:

1. Optimization include financing can be a more realistic study and may reveal surprising outcomes. We shouldn’t always only optimize annual energy or instantaneous max power
2. Including some financial calcs in pvlib may draw more investors and bankers to pvlib, increasing usage in an important way, helping to decrease LCOE, & accelerating energy transition
3. Having more engagement from financing can increase competence and interactions both ways, bankers and investors become more savvy and confident with energy calculations, and performance modelers get a better understanding of the complicated trade offs in development & operation

I don’t think we should write off this issue so quickly. I think there are opportunities here that benefit all

[cwhanse]

Each time we've had a user group meeting at PVPMC, someone asks for this capability.

[kandersolar]

I'm not disputing the value and demand for financial calculations in general, just whether it makes sense for pvlib and us to try to provide them. My main question is around whether we are familiar enough with the financial side of PV to competently evaluate whether a proposed addition would actually be useful to pvlib users. I don't want to implement a figurative isotropic LCOE if it won't get any use because we didn't know that our users actually want the perez LCOE.

I would feel better if we had more confidence that we are implementing the right thing. One way to do that would be if people in the target audience of the proposed pvlib.financial told us that yes, they would use a specific financial calculation. Or even better, a specific bit of code like #1687.

[mikofski]

Anyone familiar with the authors from NREL: W. Short, D. J. Packey, and T. Holt?

[eccoope]

@kanderso-nrel I don't think that I can speak to the demand for financial calculations, as I have yet to attend user groups. But if a .rst file on how to apply some basic financial principles to PV would be helpful for maintenance (and users), I can add one to the pull request.

[brtietz]

NREL ATB and SAM developer here. If you all decide to add this, I would strongly recommend adding tax credits to the LCOE formulation. Given the new Inflation Reduction Act regulations, having options for both the investment tax credit (in the project finance factor formula) and the production tax credit (in the LCOE formula) would be best. Right now the best source for these equations is likely the ATB data master spreadsheet: https://data.openei.org/submissions/5716, I've added improving the level of detail on tax credit treatment in our "equations and variables" page to my todo list.

@mikofski Regarding those authors - that report is old enough that most if not all of those folks have retired. The SAM team including me, @janinefreeman, and @n8blair are good people to ask PV financial modeling questions. Note that Nate is better reached via email and is unlikely to comment on GitHub issues.

[brtietz]

One more comment after some additional code review - users of this code will need to be clear on whether they're calculating real or nominal LCOE. An explanation of the difference and why this is important is available at: https://www.utilitydive.com/news/LCOE-resolution-as-proper-solar-wind-cost-metric-NREL/586556/ I'm happy to discuss whether it's preferable to comment the code and name the variables to encourage the use of real discount rates, or leave it up to users with recommendations of which is appropriate when.

[eccoope]

@brtietz Thank you for sharing this article. I will adjust variable names to encourage the use of real discount rates.

[janinefreeman]

Hi all! Sorry to be late to the party! Some thoughts from our experience with financial modeling in SAM:

• @mikofski is absolutely right, that optimizing for financial benefit can be super valuable. LCOE can be a useful metric for that, although it is not always the right financial metric to use for system design optimization.
• @kanderso-nrel is absolutely right, that there is not one LCOE definition to rule them all. The one proposed here is one of the simpler definitions, most consistent with the ATB that Brian mentioned. This definition is largely used by the DOE wind and water power offices, but notably is not the one used by DOE SETO- they use SAM's full cashflow models to calculate that metric.
  • it is possible to get the same LCOE out of this approach and a more complex cashflow approach, if many of the more advanced features of a cashflow model are not used.
• I do see the simple approach proposed here as having value for pvlib. If the collective pvlib community is interested in adding more detailed financial modeling capabilities, we should have an in-depth discussion between SAM and pvlib teams about the best path forward. Maintaining relevant and appropriate detailed financial models requires a lot of effort and expertise (we lean on many other folks at NREL to help us with many of those details), and it would be best to ensure that our teams are synergistic and not duplicating effort.
• I wonder if there are things we can do to help pvlib users leverage PySAM for some of those more detailed financial modeling capabilities, if there's interest from this community? Perhaps a streamlined way to connect pvlib functions into those models, example files, better tutorials on using the financial models from a python environment that we could link here?

[kandersolar]

Thanks very much @brtietz and @janinefreeman for your comments! This kind of involvement from the SAM team would certainly address my concern of not having sufficient domain knowledge to review and maintain a pvlib.financial at the same standard we require for the rest of pvlib, but I don't think we can reasonably expect the SAM team to accept that burden in perpetuity.

It's puzzling to me that I am the only pvlib maintainer expressing hesitation here. Am I the only one of us that feels underqualified to review and maintain financial calculations in pvlib itself? Would any of us have known to point out the IRA tax credit and real vs nominal rate items that @brtietz did?

If we are to dip our toes into supporting pvlib's use with financial models, I'm inclined to support @janinefreeman's last point: a better option may be a documentation example showing how to pipe pvlib's output into PySAM's financial functionality.

[cwhanse]

a better option may be a documentation example showing how to pipe pvlib's output into PySAM's financial functionality.

It would be worth trying to use SAM's financial tools via PySAM so we can know if that task is easy, difficult, or perplexing. I haven't tried it.

[janinefreeman]

We can put together a Python example using the simplest financial model in SAM for starters! I would guess that's the functionality that most pvlib users would be looking to start with. Give us a week or two and we'll get something together, then the group can evaluate from there what good next steps would be. We can look at more complicated financial models subsequently, although I'd guess those start to edge more into Cliff's "perplexing" category :P

[wholmgren]

It's puzzling to me that I am the only pvlib maintainer expressing hesitation here. Am I the only one of us that feels underqualified to review and maintain financial calculations in pvlib itself?

@kandersolar I'm also hesitant, but you were already on the case and I didn't want to pile on :) I would like to become qualified for this kind of review, but that's not going to happen in the next few months.

[mikofski]

I don't claim to be an expert, and I also realize that LCOE calculations can be complex and bespoke. However, I don't want to succumb to analysis paralysis. I think we can perhaps offer a simple LCOE model, that can be a guide for optimization of amortized cost of energy. Especially with the PTC as part of IRA, the need to understand PV production in a financial context is important. I think ppl prefer the flexibility of pvlib to dive into code both for understanding and to hack it how they like. As long as the methods are documented in the public domain, and the references are relevant, I don't see the harm. Of course, that's easy to say, but maintaining this will be a burden without some dedicated expertise. There's no easy answer to this dilemma.

[mjprilliman]

We can put together a Python example using the simplest financial model in SAM for starters! I would guess that's the functionality that most pvlib users would be looking to start with. Give us a week or two and we'll get something together, then the group can evaluate from there what good next steps would be. We can look at more complicated financial models subsequently, although I'd guess those start to edge more into Cliff's "perplexing" category :P

Here is a basic notebook with that linkage to pvlib annual energy calculations (I used a basic example from the gallery) linked to PySAM's LCOE calculator, along with the FCR calculations involved.

pvlib_samlcoefcr_example.zip

[kandersolar]

Thanks @mjprilliman! Seems like it's pretty easy to pipe a pvlib energy time series into at least this simple PySAM financial model. I think that notebook could be the basis of a good addition to the example gallery, regardless of what we end up deciding with #1687.

Regarding #1687, I realized much of my reluctance could be addressed by a simple name change to not conflate abstract functionality with the specific models that provide it. The Short et al. model isn't the only way to calculate these values, but #1687 gives it the lofty name pvlib.financial.lcoe. I think we should rename it pvlib.financial.lcoe_short95 or pvlib.financial.short95.lcoe or something else that has a clear and static functionality boundary.

[cwhanse]

we should rename it pvlib.financial.lcoe_short95

gets my vote