Re-implement ExcessGen

[grgmiller]

In commit https://github.com/grgmiller/SWITCH247/commit/bceccc306f7b800206951d9de280e340e1f84d0e, referenced as Commit 2021.03.24 in the CHANGELOG, I had removed the implementation of ExcessGen for renewable generators, in an effort to reduce the model dimensionality. However, looking at this now, I realize that the calculation of ExcessGen for individual generators and timepoints actually serves several useful purposes:

• Allows us to constrain storage to only charge from excess renewable energy (#17)
• Allows for simpler calculation of excess time-coincident RECs, and the value of this excess generation (#18)
• Allows us to constrain overprocurement (#10)
• Allows for a simpler implementation of curtailment (#9)
• Allows us to figure out the time-coincident utilization of each generation resource, which is useful for determining which resources best align with load at lowest cost
• Allows us to more accurately calculate our delivered energy mix

The ExcessGen variable essentially acts as a slack variable, which allows us to re-set the load balance constraint as an equality constraint.

Although there are many benefits to re-implementing, adding this variable back will likely slow down the model, since we would be adding 8760 additional decision variables for each generator, plus any additional constraints.

Adding ExcessGen back in will require:

• [x] Re-index DispatchGen to all non-storage generators, and get rid of RenewableGen variable
• [x] Remove any indexing to VariableGens
• [ ] Create a dynamic constraint such that DispatchGen + ExcessGen = DispatchUpperLimit (it needs to be dynamic so that a curtailment term can be added if implemented in the curtailment module)
• [x] Re-work the generation cost formula to include a Dispatched component and Excess component. Total cost should equal (DispatchGen + ExcessGen) * (PPA - Pnode)
• [x] Implement constraint on storage charging so that it can only charge from excess renewables
• [x] Implement constraints for overprocurement
• [x] Change the load balance equation to an equality constraint
• [x] rename congestion_pricing.py to nodal_pricing or wholesale markets etc

This will require changes in the reporting module (#23)

• [ ] Calculation of delivered energy mix will be based on DispatchGen
• [ ] For load balance graph, we might want two versions - one with dispatched energy, and one with generated energy. Or maybe keep generated in same order, but shade out the excess chunks
• [ ] Update excess gen /REC resale calculations

[grgmiller]

If we want to re-sell excess generation, there are a few ways this could be implemented:

• No resale of excess generation or RECs (excess generation is sunk cost)
• Sell excess volumetric unbundled RECs only
• Sell excess time-coincident unbundled RECs
• Sell excess generation, bundled with RECs. We would need to sell excess time-coincident generation

• [ ] Add an option to re-sell excess generation in the objective function
• [ ] Add information about value of re-selling excess as options in summary_report, which relies on data that is independent of their inclusion in the objective function.

[grgmiller]

How will this affect the dispatch of storage, in particular when storage may discharge. Currently, we allow storage to discharge whenever it is cost optimal, which is allowed because the load balance constraint says that generation >= load. If implemented, the slack variable would not actually appear in the load balance constraint Injections == Withdrawals DispatchGen + SystemPower + StorageDischarge == Load + StorageCharge

So if we wanted storage discharge to be able to exceed load, we would need to create another slack variable (ExcessDischarge) which would appear in the objective fuction, but would not show up in the load balance constraint. We would also need to set the discharge constraints and any other expressions that rely on storage discharge to also consider the excess discharge. This would probably be best implemented as an option.

[grgmiller]

When performing this update, we want to ensure that all generators (whether variable or renewable) are eligible to count toward our goal, in case we model dispatchable biogas.

[grgmiller]

If we are counting storage as a load-modifying resource, then we need to make sure that our implementation is consistent. For example, when storage is charging (increasing load), it should increase dispatchgen. but then it makes it hard to constrain storage dispatch to excess gen <- are we already able to do this?

[grgmiller]

If we want to use ExcessGen to indicate how many excess RECs we can sell, we need to make sure that ExcessGen does not include any volumes charged by our batteries.

Increasing StorageCharge would also increase DispatchGen by an equal amount, thus decreasing ExcessGen. Do we need a new DV that is DispatchGenToStorage? Then ExcessGen would always be constant

• [x] Fixed this by not requiring that storage charge from excessgen

[grgmiller]

What can we learn from how we regulate hybrid charging? If hybrid storage is allowed to charge from the full dispatchgen, couldn't standalone storage do that too?

• [x] Allow storage to charge up to total zone dispatch

[grgmiller]

The prior implementation of ExcessGen was as an expression. Would we solve our problems by making it a decision variable?

[grgmiller]

In order to prevent geothermal to look like it is dispatching, should we implement it as baseload, which wouldn't be allowed to have excessgen?

• [x] prevent baseload resources from having any excessgen

[grgmiller]

Upon implementing excess gen, at least when using an annual goal, the model wants to balance load mostly with system power, and let most of the generation still be ExcessGen. The desired behavior would be for Dispatch Gen to equal load when available, and for system power to only be used to fill in the gaps.

One issue is that system power currently has no cost associated with it, so there is no penalty for using system power and contracted power at the same time. If we assigned a cost to system power, then there would be a disincentive to use it unless necessary.