search

PowerGenome / PowerGenome

A tool to quickly and easily create inputs for power systems models
MIT License
201 stars 68 forks source link

Separate all new-build resources by build year? #64

Open gschivley opened 4 years ago

gschivley commented 4 years ago

Related to #63. Is there any need to distinguish fossil resources by build year? I could see a benefit to mapping existing/new-build resources to a common set of names and then distinguishing them by age. But is there a use case for separating CT's, nuclear, or something else by when it was built?

Possible arguments for separating all new-build resources by planning/build year:

Arguments against:

@JesseJenkins @nspatank @sambuddhac, I know that extra renewable clusters don't greatly increase solve time. What about thermal/commit resources with New_Build of 0? If it's a big increase in complexity (>= proportional to # of resources) then this probably doesn't make sense to do in all cases. But I might still build the framework

JesseJenkins commented 4 years ago

Extra thermal clusters are the most important factor for runtime as they have the most complex constraints. Easier for existing than new, but still will add runtime.

What would be ideal is a way to track the underlying individual generators and vintage of new build in a pre/post process step, and then update the average plant characteristics for GenX inputs for actual runs. Does that make sense? Ideas on how to do that?

it would be particularly beneficial for creating visualizations of existing generators that retire over time, and charting vintages of new build over successive planning periods.

Jesse

On Thu, Sep 24, 2020 at 3:23 PM Greg Schivley notifications@github.com wrote:

Related to #63 https://github.com/gschivley/PowerGenome/issues/63. Is there any need to distinguish fossil resources by build year? I could see a benefit to mapping existing/new-build resources to a common set of names and then distinguishing them by age. But is there a use case for separating CT's, nuclear, or something else by when it was built?

Possible arguments for separating all new-build resources by planning/build year:

  • ATB doesn't change heat rate or O&M over time but we could apply projected changes to these values (increase O&M or decrease heat rate as a plant ages)
  • User-supplied data (heat rate/O&M) for a resource type could change over time.
  • More easily track how much capacity was built in each planning period or which period stock was retired from.

Arguments against:

  • Will increase the number of resources in later planning periods. A single period by decade would have 3x as many new-build resources in 2050.
  • Maybe others?

@JesseJenkins https://github.com/JesseJenkins @nspatank https://github.com/nspatank @sambuddhac https://github.com/sambuddhac, I know that extra renewable clusters don't greatly increase solve time. What about thermal/commit resources with New_Build of 0? If it's a big increase in complexity (>= proportional to # of resources) then this probably doesn't make sense to do in all cases. But I might still build the framework

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gschivley/PowerGenome/issues/64, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPYTSAHTGXCBRQQXXPKXILSHOMBJANCNFSM4RYVZEMA .

gschivley commented 4 years ago

I started something similar with #18 a long time ago. In theory I know how it should work, it's just a matter of implementing and then getting used to a new PG/GenX workflow.