switch-model / switch

A Modern Platform for Planning High-Renewable Power Systems
http://switch-model.org/
Other
130 stars 85 forks source link

Legacy renewable projects: failing to assign capacity factors when periods > gen_max_age #108

Closed sergiocastellanos closed 5 years ago

sergiocastellanos commented 5 years ago

When building a long-term scenario (2050) I included renewable energy plants installed in 2015, however I kept getting the following error:

RuntimeError: Failed to set value for param=gen_max_capacity_factor, index=('renewPlant', 338), value=0.248987. source error message="Error setting parameter value: Index '('renewPlant', 338)' is not valid for array Param 'gen_max_capacity_factor'"

It seems that SWITCH can't assign capacity factors for legacy plants (and hence can't construct the model to be run) if their max age have been reached before an investment period. In this particular point, no capacity factors could be assigned after 2040 (2015 init period +25 commission = 2040) because they weren't mean to exist then.

A quick workaround to construct and run was to extend these projects' lifetime.

mfripp commented 5 years ago

If I understand correctly, this is working as intended. To save memory, Switch doesn’t define any details for generation projects during periods when it is not possible to run those projects. This includes build, commit and dispatch variables, as well as parameters like variable capacity factors. Switch (actually the underlying Pyomo framework) will generate an error if you try to supply data for these undefined periods. That forces users to be correct in the data they supply, and avoids any possibility that they will believe Switch is modeling those periods when it really isn’t.

Could you explain why this is a problem? Would you just find it easier to provide data for all periods even though it won’t be used? Or do you want to allow the renewable facility to run beyond the end of its normal life?

If it’s the latter, you could define a follow-on project that represents the cost and performance if that facility is used beyond its normal life. Then you could allow Switch to choose whether or not to build that follow-on project.

Or you could raise the lifetime of legacy projects (as you did), but impose your own constraint that output must be zero in later years unless some cost is paid for life extension. In this case you’ll have to be a little careful about costs because the original project will now be amortized over a longer period, and also you will need to make sure the life-extension costs are amortized correctly.

If this is a common use case we could potentially add code to support life-extension of existing generation projects at some price. (Will wait to hear if anyone else chimes in on that.)

On May 26, 2019, at 8:13 AM, Sergio Castellanos notifications@github.com wrote:

When building a long-term scenario (2050) I included renewable energy plants installed in 2015, however I kept getting the following error:

RuntimeError: Failed to set value for param=gen_max_capacity_factor, index=('renewPlant', 338), value=0.248987. source error message="Error setting parameter value: Index '('renewPlant', 338)' is not valid for array Param 'gen_max_capacity_factor'"

It seems that SWITCH can't assign capacity factors for legacy plants (and hence can't construct the model to be run) if their max age have been reached before an investment period. In this particular point, no capacity factors could be assigned after 2040 (2015 init period +25 commission = 2040) because they weren't mean to exist then.

A quick workaround to construct and run was to extend these projects' lifetime.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

josiahjohnston commented 5 years ago

I ran into this issue a few weeks ago while working on another dataset. I was meaning to post it after I finished up that project, but sounds like it's impacting others as well. I implemented option 2 from the below into PR #109 which passes all my tests.

...I ran into problems where the capacity factor for an existing solar plant was included for all timepoints (including 2040), but the plant was only expected to operate till 2033. The model threw an error because the index on the cap factor wasn't in the set VARIABLE_GEN_TPS (a sparse set that only includes periods for which the plant is operational).

Options: 1) Put more logic into building the input files to filter out cap factors that extend beyond the plant's lifetime. Pro: no changes to switch model. Con: pushes more complexity & model-specific rules into the input gathering, which increases redundancy in code, and would make the input logic more fragile & harder to maintain or explain. 2) Update the model to create a new index for gen_max_capacity_factor based on available data, then do a build check to ensure that is a superset of VARIABLE_GEN_TPS. Including extra cap factors will use a little more RAM, but won't impact the model. 3) I considered tweaking the model to delete extra entries right after reading them in, but the set VARIABLE_GEN_TPS isn't available at that time, and I don't want to write new redundant code to derive that set. I don't know of a better place to trim that data.

I hit the same problem with hydro timepoints in hydro_simple, and implemented the pattern from option 2 from above.

bmaluenda commented 5 years ago

Version 2.0.3 (#112) released by Matthias addresses this concern and allows including max capacity factors for timepoints later than the retirement year of generation projects. Closing this Issue.