-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with unit ramp limits #1029
Comments
你 好! I have no idea why my coefficient is 3.6 instead of 4. But the main problem is that Yes the units_started_up must be equal to units_shut_down because fix_units_on was set. This was also discussed in issue Simultaneous starts/shutdowns. |
My coefficient is 3.6 instead of 4 because I defined a fix_ratio_out_in_unit_flow 0.9 between fuel and output. |
Constraint code
Results fix_units_on: 1 t_before=2021-05-01T03:00 (1_hour)->2021-05-01T04:00, I get a very reasonable result:
Here the 0.9 comes just from fix_ratio_out_in_unit_flow because the output flow is automatically replaced by input flow in the constraint. |
Here is my next version. For the example: fix_units_on: 1 temporal block resolution ["1h","1h","1h","1h","4h","4h"] t_before=2021-05-01T03:00 (1_hour)->2021-05-01T04:00, The result for maximum ramp down for unit flow is 30 units as expected. This comes from 6 units during
|
RHS terms. Terms 1 and 2 calculate the time averages of Fig. 1. Unit flow time average calculation. Not sure about the third term on RHS. LHS terms Terms 2 and 3 on the RHS calculate the effect of Term 1 corrects the effect of shut_down_limit for plants which are shutting down during t_after. So for them it is assumed that they are generating at shut_down_limit during t_before and zero during t_after. Not sure if ramp down limit is needed in this term. Terms 4 and 5 calculate the actual ramping potential during half of t_before and t_after. No adjustments at this point for units which are shutting down or starting up. Fig 2. Units started up and units shut down contribute to the ramping capacity. |
Description
Ramping down will be difficult when time resolution changes.
How to reproduce
Set the following unit and unit-output node parameters for a simple generator unit:
fix_units_on: 1
unit_capacity: 100
minimum_operating_point: 0.4
ramp_up_limit: 0.1
ramp_down_limit: 0.1
Set the following model parameters:
temporal block resolution ["1h","1h","1h","1h","4h","4h"]
model start: 2021-05-01T00:00:00
We will then have the ramp down limit constraint with t_before and t_after as follows:
t_before=2021-05-01T03:00 (1_hour)->2021-05-01T04:00,
t_after=2021-05-01T04:00 (4_hours) ->2021-05-01T08:00
Realized constraint:
3.6 * unit_flow[t_after] >= 640 * units_on[t_after] -200 * units_on[t_before] + 0.9 * unit_flow[t_before] -800 * units_shut_down[t_after]
Let's suppose the the demand (and thus unit output) is as follows:
unit_flow[t_before] = 90
unit_flow[t_after] = 70
It should be possible within the 0.1 ramp limit but the constraint will not be fulfilled unless units_shut_down[t_after] > 0.
Expected behavior
The ramping should be possible without shutting down units.
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: