trade bound

[xiao.li8@mcgill.ca]

Hi,

Sorry just a quick question;

how do I limit the activity bound for a bi-trade flow: e.g., from A state to B is 10PJ, while revert is 0.

Best,
Xiao

[Antti-L]

Some alternatives:

1) Define the process type as 'DISTR'; the activity is then the IMP flow only, which you can bound in A and B;
2) Use FLO_BND instead of ACT_BND:
     FLO_BND('B',y,p,'NRG','ANNUAL','UP') = 10;
     FLO_BND('A',y,p,'NRG','ANNUAL','UP') = 0;
3) Use IRE_BND (works for bounding total trade (IMP/EXP) of given commodity between regions A and B);
4) Use a user constraint, which can refer to the IMP/EXP flows directly.

[xiao.li8@mcgill.ca]

Some alternatives:

1) Define the process type as 'DISTR'; the activity is then the IMP flow only, which you can bound in A and B;
2) Use FLO_BND instead of ACT_BND:
     FLO_BND('B',y,p,'NRG','ANNUAL','UP') = 10;
     FLO_BND('A',y,p,'NRG','ANNUAL','UP') = 0;
3) Use IRE_BND (works for bounding total trade (IMP/EXP) of given commodity between regions A and B);
4) Use a user constraint, which can refer to the IMP/EXP flows directly.

Hi Antti,

Thank you, I will try to use FLO_BND

Best,
Xiao

[Kristina.Haaskjold]

Dear Antti,

What is the best way to limit an IMP process on 'DAYNITE' level? It's a unilateral process used for import of electricity at a given price (defined at hourly level). It therefore only has outflow and only one region.
I have tried using both ACT_BND, FLO_BND, IRE_BND and user constraints but the model doesn't respect the hourly limits. I have tried defining it both as 'IMP' and as 'DISTR' without success.

[Antti-L]

I am not sure I understand the problem.
If the process is operating on the DAYNITE level, ACT_BND and FLO_BND do work on individual DAYNITE timeslices. I have not seen any such problem with using them. 

Therefore, could you please clarify the nature of the issue, or provide a reproducible case?

[Kristina.Haaskjold]

I have attached a screenshot of how the process is defined and the resuling Var_FOut of the process in some of the timeslices. I would like to limit the maximum hourly output of the process to 150, but the FLO_BND~DAYNITE (and similarly with ACT_BND) doesn't seem to work. Both process (IMP_ELC_DEU) and commodity (ELC-HV-on) is defined on DAYNITE level. I'm also trying to limit the total annual flow (hence the FLO_BND~2030 etc.).

[Antti-L]

Ok, it looks like the same issue you had before with COM_BNDNET.  ACT_BND and FLO_BND expect a timeslice index, and DAYNITE is not a timeslice.  So, you cannot define FLO_BND('DAYNITE').

I understand that it would be convenient to define it with FLO_BND('DAYNITE'), but it does not work that way.  You should either define it for each and every timeslice, or use a timeslice-dynamic user constraint (such an UC does allows the bound to be automatically levelized to the DAYNITE timeslices). Or, you could also define a CAP_BND if the bound has the same value for all timeslices and the DAYNITE timeslices are of equal length, or you could also use NCAP_AF(ANNUAL) for a fixed capacity.

[Antti-L]

If there is general interest for it, I guess one could consider changing the bound attributes, or adding a new attribute that would support setting flow bounds for all DAYNITE timeslices with just 'DAYNITE' as well. But for now, I think using a simple timeslice-dynamic user constraint (or a capacity bound, or maybe NCAP_AF) is not too far in convenience.

[Kristina.Haaskjold]

Thanks for the clarification. I think it's a bit cumbersome that it doesn't support flow bounds on DAYNITE timeslices with just using 'DAYNITE', so if that could be an addition to a later version update, I think that would be appreciated by other users as well.

I've tried with adding a timeslice-dependent user constraint, but seems to be something wrong there as well. I've attached a screenshot of how I defined it. Appreciate if you could have a look and tell me what's wrong.

[Antti-L]

You should use UC_ATTR column and put IRE,DAYNITE under it (and remove the Timeslice column).

[Antti-L]

Ahh... but why are you putting EXP into Other_indexes? I thought the processes are importing (IMP), and not exporting?

[Kristina.Haaskjold]

Yes I always get confused by this. Since the process only has a Comm-OUT, I think of it as exporting (flow out), while importing would be flow into the process. But this is just my head thinking opposite. I'm testing with IMP now.

Thanks and have a nice weekend!

[Antti-L]

Ok, I guess a new attribute could be implemented for it in TIMES.
But could you first clarify what that FLO_BND('IMP_ELC_DEU','ELC-HV-on','DAYNITE') = 150 you defined is in fact meant to mean?  Do you mean that for each DAYNITE timeslice the flow bound should be 150 GWh, regardless of the timeslice length?  So, for example, if one timeslice has a length of 1 hour, and another has a length of 100 hours, the maximum power rate level would be 150 GW for the 1-hour timelice but only 1.5 GW for the second, 100-hour timeslice?  I think such would usually not make much sense, and it would make the effect of the parameter to be dependent on the timeslice resolution.

Hence, I would think that maybe a better design would be to make the meaning of the parameter independent of the timeslice resolution, and so perhaps the flow bound derived for each timeslice s should be the parameter value specified multiplied by G_YRFR(r,s)?  In that way, in terms of the power rate level, the bound for each DAYNITE timeslice would be the same, and not dependent on the timeslice length. What do you think about that suggestion?

Additional Note: The TS-dynamic UCs work just like that, and so if you, in fact, meant that for each DAYNITE timeslice the power rate level should be at most 150 GW, you would need to define the RHS constant as 150 GW × 8760 h = 1314000 GWh, because that would be the annual flow equivalent for 150 GW.

[Antti-L]

Dear Kristina,
In view of preparing a new TIMES release soon, I'd be grateful of any comments on the possible designs for implementing the new attribute, for bounding process flows/activities at all DAYNITE timeslices by using a single parameter instance. And it would also be good to know whether you got the UC constraint working in the way you wished. 

Comment from all other Forum members are likewise welcome, about the suggested new bounding feature.

[Kristina.Haaskjold]

Dear Antti,
Sorry for the late reply!

Good question. I only considered this on an hourly level, but it becomes a bit more tricky with other timeslice lengths yes. With your proposed solution, having the parameter independent of the timeslice resolution, how would that work if e.g., the timeslice lengths is 8760 vs. 24 and I would like to limit the power rate to 150 MW for an hour? Would the parameter be set to 150 in both cases, and the G_YRFR would take care of the differences regarding the timeslice length?