Implement Multi-Horizon Optimization

[ktehranchi]

Feature Request

Goal: Implement multi-horizon perfect foresight optimization.

Suggested Solution:

After speaking with @FabianHofmann, it is suggested that we first implement the perfect foresight optimization in a single pypsa network rather than multiple network files to track each investment period in a myopic solution. The myopic solution as currently implemented in PyPSA-Eur iteratively solves each investment period as a new network, and feeds forward the results. In perfect foresight, the network snapshots are multi-indexed with each planning horizon as the first level in the multi-index.

Decided not to implement myopic since pypsa is working to integrate that internally.

Tasks:

• [x] add lifetimes to generators
• [x] add build-year to the generator
• [x] Create demand files for each planning horizon in build_demand. Which motivates #298 demand-xarray implementation.
• [x] Add forecasted demand to the loads_t table for each investment period
• [x] Determine best step in process to add the additional demand to the network. @trevorb1 curious to hear your thoughts on this. It probably makes sense to add the demand in the new add_demand module rather than post-clustering?.... only worry as fabian mentioned would be memory usage.
• [x] #322
• [x] Update add electricity to create new generators for each build year
• [x] Update Plots for multi-horizon solutions
• [ ] Set n.investment_period_weightings correctly
• [x] Implement multi-horizon for SAFER, RPS, and RCo2L opts
• [x] Update validation plots for multi-horizon indexing compatability
• [ ] Implement multi-horizon Co2 constraint in config file

[trevorb1]

Determine best step in process to add the additional demand to the network. @trevorb1 curious to hear your thoughts on this. It probably makes sense to add the demand in the new add_demand module rather than post-clustering?.... only worry as fabian mentioned would be memory usage.

Hmm... current writing strategies are tied to pre-aggregated versions of the network (either on BA, State, county). But I think updating them for a new field arbitrary region (ie. clustered_region) should be doable without changing the writing strategy. We will will have to provide logic to calculate the LAF for that arbitrary region, though.

[ktehranchi]

What if we just added them non-clustered?

[trevorb1]

What if we just added them non-clustered?

yeah, good idea! This probably makes the most sense rather than messing around with adding in new logic to the write strategies

I guess the the process would be:

1. Reading in of datasets remains unchanged (ReadStrategies)
2. Disagregation of load to individual buses remains unchanged (WriteStrategies)
3. The add_demand rule is then updated to bring in the clustered bus regions, and clustered network, rather than the base network

[ktehranchi]

yeah i guess i was also thinking we would add all the demand for all investment periods in add_demand

so the process would look just like it does today except at each step moving forward from add_demand, there would be a multi-indexed snapshot with investment periods specified