Dynamic Constraint at Time Slice Levels
#1
Hi all !

I would like to have the possibility to introduce dynamic constraints at the time slice level. This would be useful , for example , to implement ramp-up and ramp-down constraints .

To my (limited) knowledge, currently the dynamic constraints operate at a time period level. Is it possible to extend them and make them also work at a time slice level as well, in the same manner as they are currently implemented at the time period level?

One possible complication would be how to initialise the variables introduced in the constraint. I guess that can be done in the same way as we initialise a variable in a growth/dynamic constraint.

One idea can be that the initial value of the variable in time slice 1 in year t is the value of the same variable in the last time slice n in year t-1 (in the order in which the time slices and milestone years are defined by the user). In this way, the constant that the user provides can be used to initialise the variable in the first time slice in the first year.

Or, there is already a way to introduce a dynamic constraint at a time slice level ?

Thanks a lot,

Vangelis

Reply
#2

Thank you for your suggestion. 

In order for it to be properly considered, it would be best if you could submit your proposal to the ETSAP Project Head, with the functional design worked out.

However, by using constraints summing over timeslices  it is already possible, albeit somewhat cumbersome (especially if a large number of successive timeslices are to be constrained).

Reply
#3

Dear all,
In general I support the direct representation of some operational restrictions directly into TIMES for limited models. This could include RampUp/RampDown or minimum operation hours or other features for which one would need a relation between attributes of different timeslices.

Like Antti pointed out, there is a way to use the current user constraint implementation.
I constructed this example down, however did not try this out yet.
Antti, is something like this you were thinking of (indeed cumbersome with many large nr of timeslices) ?

Best,
Wouter

Reply
#4

Yes, Wouter,  I was indeed thinking of something like that.  Approve

However, your UC_RHSRTS would be filled with the timeslices Hour501 etc., which would not work. You would need to use either UC_RHSRTS~ANNUAL (or UC_RHSRTS~<some parent timeslice>) or  UC_RHSRT.

Reply
#5
Correct ! Wink
I started from a constraint that was constructed for each timeslice (UC_RHSRTS) but that is now different.
Thanks for commenting.
Wouter
Reply
#6
I strongly support the idea of the add-on proposed by Vangelis.

Although an alternative is given, this can become extremely time consuming when using a high temporal resolution (or when a lot of different time slices need to be linked as).
Reply
#7

For those interested, TIMES v3.6.0 will support simple dynamic user constraints between timeslices.

Here are three example equations related to "ramps" that could be defined with TIMES v3.6.0:

The first equation, HRAMP-REL, would limit the hourly ramp-up of the technology ECOASTM005 to at most 5% of the full capacity (assuming the DAYNITE timeslices are hourly).

The second equation, HRAMP-ABS, would limit the hourly ramp-up of this technology to at most 0.1 GW (=3.1536 PJ/a), and the hourly ramp-down to at most 0.2 GW (=6.3072 PJ/a).

The third equation, SRAMP-REL, would limit the seasonal ramp-up of this technology to at most 30% of the full capacity (i.e. average power level in each season is at most the average power level in previous season + capacity*0.3).

Hopefully this new feature can be useful for defining dynamic constraints at Time Slice levels.

Reply
#8
Thank you very much Antti for implementing. It will be a powerful feature in the context of increased interests in variability issues.
Kind regards,
Wouter
Reply
#9
These are really great news !!!

When the new version will be available?

Reply
#10

Available now at  http://www.kanors-emr.org/download.asp

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)