The purpose of this feature is to pass net demand deviations from the current interval to the following interval. Based on the demand flexibility formulation, shifted demand does not necessarily need to be completely balanced at the end of an interval (though it likely will be due to the cost minimizing objective). This feature ensures that all shifted demand ends up being accounted for. This PR closes #123.
What the code is doing
In model.jl, a new constraint (rolling_load_balance_first) is added to account for the previous interval's net demand deviation during instances where the rolling_balance parameter is enabled. This new constraint creates an additional rolling window at the beginning of the interval to balance demand deviations and the previous interval's net demand deviation. Additionally, the interval_load_balance constraint is updated to account for the net demand deviation. There is also a small fix to the number of rolling windows that are used in the rolling_load_balance constraint. Previous iterations of the model did not accurately account for the number of balancing periods that should be present.
In loop.jl, the net demand deviation is calculated and passed to the following interval. This implementation is similar to that of the initial state of charge parameter used in the energy storage model. Net demand deviations are calculated as the difference between the up and down deviations for each bus with demand flexibility for each interval. The interval_load_balance and rolling_load_balance_first constraints are also updated appropriately for intervals i > 2.
Testing
I tested this on the iteration of the ERCOT grid that we have been using for testing. When testing on 3 intervals of 24 hours each, net demand deviations are passed to the following interval without issue.
Where to look
Changes are contained within model.jl and loop.jl.
Time estimate
This hopefully shouldn't take too long to review. A good chunk of the noted changes are due to how the demand flexibility constraints and variables are updated in loop.jl. No functionality is changed, just how they are set in the for loops.
Pull Request doc
Purpose
The purpose of this feature is to pass net demand deviations from the current interval to the following interval. Based on the demand flexibility formulation, shifted demand does not necessarily need to be completely balanced at the end of an interval (though it likely will be due to the cost minimizing objective). This feature ensures that all shifted demand ends up being accounted for. This PR closes #123.
What the code is doing
In
model.jl, a new constraint (rolling_load_balance_first) is added to account for the previous interval's net demand deviation during instances where therolling_balanceparameter is enabled. This new constraint creates an additional rolling window at the beginning of the interval to balance demand deviations and the previous interval's net demand deviation. Additionally, theinterval_load_balanceconstraint is updated to account for the net demand deviation. There is also a small fix to the number of rolling windows that are used in therolling_load_balanceconstraint. Previous iterations of the model did not accurately account for the number of balancing periods that should be present.In
loop.jl, the net demand deviation is calculated and passed to the following interval. This implementation is similar to that of the initial state of charge parameter used in the energy storage model. Net demand deviations are calculated as the difference between the up and down deviations for each bus with demand flexibility for each interval. Theinterval_load_balanceandrolling_load_balance_firstconstraints are also updated appropriately for intervalsi > 2.Testing
I tested this on the iteration of the ERCOT grid that we have been using for testing. When testing on 3 intervals of 24 hours each, net demand deviations are passed to the following interval without issue.
Where to look
Changes are contained within
model.jlandloop.jl.Time estimate
This hopefully shouldn't take too long to review. A good chunk of the noted changes are due to how the demand flexibility constraints and variables are updated in
loop.jl. No functionality is changed, just how they are set in the for loops.