GitLab

Fixing a bug in ramp tier limits: For units with shutdown trajectories, the ramp tier limit was twofold at the interval when the shutdown begins.

#65: *v_startup* divided into *v_startup_LP* and *v_startup_MIP* variants to avoid undesired behavior when using integer online variables.

Updating ramping constraints for units with trajectories so that only the ramping above minimum load causes ramping costs. Also updating the ramping limits during and immediately after shutdown trajectory so that they correspond to start-up trajectory.

Trying to fix the ramp slack equations so that they would work also for units with start-up and/or shutdown trajectory. Most likely needs some further adjustments so that ramping costs are calculated with similar logic in start-ups and shutdowns.

Ramping should cause costs only in normal operation, that is, not when the unit is starting up or shutting down (to/from min. load).

Fixing the first part of issue #72. If ramping capability is too small compared to the min. load of the unit and the current interval length, the unit is allowed to ramp from zero to min. load in the start-up and from min. load to zero in the shutdown.

Fixing a major bug in the state variable reserve equations, that effectively caused them to be ineffective.

The *reserve_length* parameter was searched in the wrong node, occasionally resulting in the *v_reserve* variables not appearing in the constraints as they should.

Making it possible to choose in the modelsInit.gms file whether to include the two additional incremental heat rate equations that use binary variables:
- mSettings(m, 'incHRAdditionalConstraints') = 0: use the constraints but only for units with non-convex fuel use
- mSettings(m, 'incHRAdditionalConstraints') = 1: use the constraints for all units represented using incremental heat rates
Enabling incremental heat rates also in the invest model (and potentially in the building model). Some clean-up to the incremental heat rate equations.

New data parameter hrsection defined (using section will change Lambda results)
Slope for incremental heat rates now defined based on max efficiency (not used in conversion constraints - approximation only required)

Replace the p_effGroupunit(*,*,*,'section') with p_effunit(*,*,*,'section') in constraints.gms to avoid misusing of section in directoutput efficiency

Adding a few conditions to incremental heat rate equations and adding two new equations (and a binary variable) in order to ensure that the first heat rate segments are used first (even if those segments have the worst heat rate). Requires testing.

Trying to combine q_conversionIncHRBounds1-q_conversionIncHRBounds3 into one q_conversionIncHRBounds. Changing also maxGen to unitSizeGen in that equation and ignoring all slopes. Requires testing. If it works, then q_conversionIncHRBounds1-q_conversionIncHRBounds3 can be removed.

ran li authored Feb 14, 2019 and ran li committed Feb 14, 2019

fix the bug caused by messing up p_effunit and p_effgroupunit which lead to section not working and it is ok now

Fixing the bug in q_resDemandLargestInfeedUnit that was fixed in commit a56793b7 for q_resDemand (see issue #70)

Implementing cyclic online states for units (inside/between samples). A new set uss(unit, s, s) added for this purpose. See issue #51.

Errors with interval blocks now print the 'counter' on which the error occurred. Minor readability change to  'q_genRamp'.

Issue #32: Slightly cleaning up the trajectory equations by separating 'p_uCounter_runUp' and 'p_uCounter_shutdown' into minimum and maximum arrays to avoid doing partial time step calculations in '2b_constraints.gms'

Issue #32: Units should now be able to shut down at the end of the shutdown trajectory without enforcing the units to stay offline on the same step. Also fixing a bug in the 'dt_toShutdown' calculation.

Issue #32: Run-up and shutdown trajectories overhauled to permit SOS2 ramping on the last/first run-up/shutdown intervals, as well as include main fuel consumption during run-up/shutdown. However, this formulation still fails to consider changing interval lengths.

Changes to q_reserveDemandLargestInfeedUnit. Some name changes to make things more clear (check your input file too!) and changed the infeed2Cover from nReserves to nuReserves so that it can be defined on unit basis.
New names: infeed2Cover -> portion_of_infeed_to_reserve. Equation name also changed.

Fixes issue #56. The unnecessary term is now removed. The reserve in relation to the expected output of chosen generation forms (typically VG) is anyway a crude mechanism to account for the forecast errors. It should typically act on different time scales (thus different reserves) from the N-1 disturbance reserve. The term remains in the main reserve demand equation (but when doing it properly, the reserve demand should be pre-calculated in the ts_reserveDemand).

'reserveReliability' changed from a fixed reduction in reserve commitment limits to an efficiency-like property. Now only a portion of the committed "unreliable" reserves are accounted for in 'q_resDemand' until the realization of said reserves (commitment ahead of time is still made with the reliability reduction).

Fixing issue #32. The last time interval in the run-up phase had a wrong limit for the q_rampUpLimit, this was corrected by calculating a new parameter p_u_maxRampSpeedInLastRunUpInterval. This might not be the only thing wrong. Needs to be checked futher.