Modeling transmission lines in multi-regional models

[fg]

Hi Antti! Sure, I posted you a screenshot from the VEDA TIMES-View into the attachments in which I removed the NCAP_AFC attribute already.

[Antti-L]

Ok, thanks!

Unfortunately, the process parameters did not reveal anything suspicious to me, so I am equally puzzled than you are. The next thing that comes to my mind possibly helping to diagnose it, is to post your syssettings.dd (the DD file from the working folder) and the QA_Check.log, if you think that's ok (Zipped). 

[EDIT:] Looking at your numbers more closely, it seems to me that you may have a problem in your G_YRFR and/or timeslice set definition after all. If that is correct, I guess here, once again, one might add an additional QA check to alert the user. But let's see if you/we can confirm where the problem is...

[fg]

Yeah, I was already also thinking whether these long float number ratios in the timeslice definition might be the cause...
Alright, I've attached you the zip file.
[Caveats: This is a test scenario, so please don't give too much about the names given here.]

[Antti-L]

Ok, thanks again.

But again, I could not find anything suspicious!

It might save time if you would just send me a private message giving me a link to the whole model (all the *.dd files and the *.run file), but I can understand you might not want to disclose them all to me.

Unfortunately, at this point it looks like I am not able to see where the problem is, without seeing the model. Sorry for wasting your time...

[Antti-L]

Ahh…, sorry again, I overlooked the fact that you are defining the G_YRFR on multiple timeslice levels! In fact, you are defining them on all levels, including the ANNUAL level. That is quite unusual, as most users define the year fractions only on the finest level, typically the DAYNITE level.  The fractions on the other levels are then implicitly defined to be the sums of the fractions of the timeslices below each higher level timeslice, which is easy and consistent.

But, as you have pointed out earlier, the user obviously must have had some purpose for defining the values on multiple levels. TIMES fully respects that, and therefore the final G_YRFR values to be employed in the model are calculated using the most obvious, and probably the only reasonable method:

1) The timeslice fractions on the SEASON level are obtained by normalizing the user-provided values to have a sum of 1.
2) The timeslice fractions of any timelice below a SEASON timeslice SS having a year fraction XS are obtained by normalizing the user-provided values of the timeslice fractions on the timeslices below SS to have a sum of XS.
3) The timeslice fractions of any timelice below a WEEKLY timeslice WS having a year fraction XW are obtained by normalizing the user-provided values of the timeslice fractions on the timeslices below WS to have a sum of XW.

Consequently, I would conclude that you have defined, in an unusual way, timeslice fractions on multiple levels, and TIMES respects your purpose in doing so, as described above. But when you calculated the VAR_FOUT value, and argued that it is slightly too high, you neglected the fact that you have defined year fractions on multiple timeslice levels that are inconsistent as such, and have thus been normalized.

An easy solution to the problem would be to remove the G_YRFR definitions on all other levels but the DAYNITE level. But if you insist on defining the fractions on multiple levels, please use the normalized values when calculating the load levels. Would you kindly let me know if this helps?

[fg]

Antti, you're my hero of the day - Thank you a lot!
After deleting all level definitions other than DAYNITE it works now perfectly!

Thanks for clarifying this - I found that the mistake was a rounding step in the initial timeslice calculation sheet that caused these little devitiations (e.g. one weekday timeslice was 0.18002 while the sum of the daynite timeslices below was 0.18082).
Indeed very good to know that only the finest level of definitions are required, I didn't know that TIMES calculates the higher levels itself.

So thank you again!

[guozhi1305]

Hmm... I am not sure I understand the problem.

If you want to build a constraint on the export flows from region A to B, just define that constraint only for region A, using UC_IRE coefficients on the export flows of the process(es), just like in my example. When the exporting region is given, the export flow of any bilateral process is unique, and so there is no ambiguity. TIMES will know that you are bounding the export flows from region A, because you define both the coefficients and the RHS only in region A for that constraint.  Or would you say that I am missing something?

BTW: You can name the bilateral trade processes any way you like, see example here:

You can write any process names instead of the TB_* names shown in the picture. But of course, then defining parameters in the matrix form may not work (I have myself never used the matrix approach for parameters).

Hello,
   In multi-regional model, for each link declared (1=active links), VEDA-FE will automatically create an IRE (inter-regional trade) process, which means that we don’t need to describe for the process. However, when I use ~TRADE_Param:CAP_BND and ~TRADE_Param:INVCSOT, it occurs CAP_BND is ignore due to absence of Tech. Attached files are ScenTrade_ScenLinks and ScenTrade_ScenPara.
   Could you please help me to figure out the problem? Thank you very much.
Zhi Guo