Veda2.0 Released!


Modeling transmission lines in multi-regional models
#31
Thank you. I don't know how I should address specific people, and I didn't have any idea who is an expert in VEDA or TIMES.
Reply
#32
Well, at least I specifically informed you about it already much earlier in this thread:
"Sorry, for not being a VEDA expert."  Big Grin
Reply
#33
Hey All,

I have some TB transmission processes and would like to constrain a TB set in one-way only. For example, there are regions A, B, C and D. I have also the following TB processes, as follows:

A - B (PRC_RESID: 10 MW both ways);
A - C (PRC_RESID: 10 MW both ways);
A - D (PRC_RESID: 10 MW both ways);

I would like to build an ACT_BND that pledges that (A->B + A->C + A->D) activities (sum of the 3 TBs) in the time slice level must not surpass, let say, 20 MW. But only when exporting from region A to the other regions. The constraints would not apply the other way around.

I made a TB set at Veda-BE (containing these TBs) so I would be able to apply the Activity constraint on the entire set. The problem is that Veda constraint it on both ways, but I would like to apply it in one way only (commodity export from region A). Is there any other way on doing so? Maybe applying ACT_BND with negative values?

I have also tried to build 2 TU processes, instead of 1 TB, so I could apply the boundary in one way only. I don’t know exactly why, but results behaved very weird.

I am not sure if I made myself clear.
Any ideas?
Thanks,
Reply
#34
Have you tried a user-constraint?
First, write down the equation, and the see if the formulation is linear and can be written in TIMES. For example, perhaps the following constraint may be close to what you want:

For Region=A, for each t≥2020, and for each ts:

(VAR_IRE(A,t,TB-A-B,ELEC,ts,EXP) + VAR_IRE(A,t,TB-A-C,ELEC,ts,EXP) +
VAR_IRE(A,t,TB-A-D,ELEC,ts,EXP))/G_YRFR(ts)  ≤ 20*3.6*8.76/1000.

Then define the constraint in a VEDA Scenario template. For example, the constraint written above can be defined as shown below: [Image: attachment.php?aid=284]
However, note that I have not actually tested it with VEDA at this point, but I think it should work. (20*3.6*8.76/1000=0.63072).


Attached Files Thumbnail(s)
   
Reply
#35
(11-06-2017, 08:10 PM)Hi Antti, Wrote: Thanks for your help.

I have already seen this UC_ATTR in other models, but I’m not very familiar with its use. Could you please clarify it to me?  

I am not quite sure, but it seems the constraint is still bounding both ways of the TB. As far as I know the IRE multiplier with an “-E” in the end stands for exporting activity, right? But, how does VEDA know which TB direction should stand for importing or exporting? Considering that a TB is a bilateral process, both regions (let say A and B) at any time will be an exporting or importing region.

One last question. I didn’t get it exactly, but you presumed in your example a time slice for every second of the year - 3600 seconds x 8760? Why did you shall then divide it by 1*10^6?

In my case, I have 192 values in my time slice (24 hours x 2 days x 4 seasons - as the 2 days represent weekends (WE) and weekdays (WD) they don’t have a same YRFR value). Anyway, considering a weekday-DAYNITE-time slice, shouldn’t my IRE activity constraint be 20*8760*0.0074 (YRFR for WD) = 1296?
Reply
#36
1) UC_ATTR: See the documentation, Part II.

2) Bounded variables: I my example, the constraint is generated in region A only, and the variables to be bounded are the export flows from region A.  So, as far as I can see there is no way it could be bounding the import flows. Can you explain how it could be bounding the imports?

3) In my example, I only assumed that the flow unit is PJ, which is the most common choice. The RHS constant comes directly from that assumption, converting 20 MW into PJ (for a single year, as TIMES operates with years).  In no way I presumed "a time slice for every second of the year"; why do you claim something like that?

[EDIT:] Ahh..., I can see that the VEDA-shortcut for UC_TSL is not mentioned in the documentation. So, to clarify this specific usage, UC_ATTR(reg,uc_n,side,uc_grptype,TSLVL) is equivalent to UC_TSL(reg,uc_n,side,TSLVL), for any uc_grptype. This "shortcut" is useful under VEDA, because the UC_TSL attribute is not supported by VEDA. But all the standard UC_ATTR attributes are described in Part II, see page 262 for an introduction and Section 6.4.6 for details.
Reply
#37
1) UC_ATTR: Thanks for your explanation.
 
2) I am not sure whether or not the UC is bounding on both ways of the TB process. By the results and by the process table in Veda it seems so (figure below). For this example (figure) I have regions N5 and NE1, trading the commodity “ELC_HV” through the TB process “TB_ELC_HV_N5_NE1_01”.
 
[img=601x36]file:///C:/Users/Raulm/AppData/Local/Temp/msohtmlclip1/01/clip_image002.jpg[/img]

 
3) Ok, I perfectly understand now. Once 1 MW equals to 1 PJ-sec, I misunderstood you were claiming for a seconds-time slice. I indeed thought that it would be not usual and probably wouldn’t be what you had wanted, but it worthy to ask.
 
In you example, this value (0.63072) should be further multiplied by the DAYNITE YRFR, am I correct? Once the constraint stands for the DAYNITE level…


Attached Files Thumbnail(s)
   
Reply
#38
I have tested the constraint with the DEMO model, and it certainly bounds only the sum of the export flows of the three processes, and only in region A.  So, I can only disagree again with your assumption that it would also bound the import flows.  The import and export flows have separate VAR_IRE variables, of which only the EXP variables appear in the equation.

Please take a look at the equation I wrote for my example:
(VAR_IRE(A,t,TB-A-B,ELEC,ts,EXP) + VAR_IRE(A,t,TB-A-C,ELEC,ts,EXP) +
VAR_IRE(A,t,TB-A-D,ELEC,ts,EXP))/G_YRFR(ts)  ≤ 20*3.6*8.76/1000.

You should see the LHS being divided by G_YRFR(ts). If you would then further multiply the RHS by the DAYNITE YRFR, you would not get a correct equation for bounding the combined load level of the three export processes. See page 280 of the documentation, Part II.
Reply
#39
Thanks, Antti, it was very helpful.


One last question, regarding Veda’s operation procedure. When I define a TB process (for instance, the matrix below), Veda, itself, define a TB process for it. For example, considering the trades between regions A and B, it may be defined as TB_ELC_RegA_RegB_01 or TB_ELC_RegB_RegA_01. 

This is done by Veda, thus not made by the user (as far as I know). 

And it doesn’t matter if the process is happening in Reg A or B, for all purposes (for example defining any attribute for the process or viewing it in Process Mater Table) it will always appear as defined by Veda. For example, If Veda defines it as TB_ELC_RegB_RegA_01 and I relate a new attribute to the process using TB_ELC_RegA_RegB_01, Veda will not read it and the new attribute will not be considered.


~TradeLinks
  ELC_HV      Reg A       Reg B    Reg C     Reg D
Reg A           -             10          15          20
Reg B          10               -           25          30
Reg C         25             25           -           35
Reg D         20             30         35          -
 
If I am not wrong, the naming convention for Bilateral trade: TB____<01> (e.g. TB_ELC_REG1_REG2_01.

Let’s assume that Veda defined this trade (A-B) as TB_ELC_RegB_RegA_01. How should I proceed to build a constraint on the export flows from region A to B? How Times will know which direction flow I am willing to bound, since both regions (A and B) act as importer/exporter under a same process?

 I am looking for it in the manuals, but until now didn’t find any satisfactory answer. It is probably a very dumb issue, but I’m confusing the right way on approaching it.
Reply
#40
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).
Reply
#41
Yes, That's it. But in your example I didn't noticed the region definition (It does appear only in the process name, did I miss something?  Huh )

From your example, shall I add the region heading instead the UC_RHSRTS column (please se figure enclosed - thats how I ussually do when adding different values per region)?

Furthermore, actually I'd like to add the constraint for different regions. For instance, the sum of the export flows from region A to B, region C to D and region E to F, must not surpass 20 MW (Sum of the 3 flows in the timeslice level). Shall I just add a region heading for each exporting region and in each process lline?

Please, see below:

                                                                                   ~UC_T:UC_RHSTS
UC_N           UC_ATTR       Pset_PN     Cset_CN      Year     LimType    UC_IRE-E    REG A      REG C  REG E    UC_RHSTS~UP~0     UC_Desc
UC_BNDLD   IRE, DAYNITE    TB A-B        ELEC         2020       UP               1         0.63072                                  5                  Max 20 MW flows
                                         TB C-D        ELEC                                          1                           ?
                                         TB E-F        ELEC                                          1                                       ?


Attached Files Thumbnail(s)
   
Reply
#42
Here is my original picture, where you can clearly see ~UC_Sets: R_E: A at the top:
[Image: attachment.php?aid=284]

I give up trying to help at this point, but I wish you all the best!
Reply
#43
Oh, now I get it and indeed had missed it. Thanks. 

Sorry, I usually don't set the desired region at "UC_Sets", but at the UC table itself.  Big Grin
Reply
#44
[First things first: I'm pushing this thread back to the top, since the topic seem to be touched upon in here and, therefore, it seemed to be more appropriate to post in here, rather than opening up a new thread.]

Exactly as Raulm, I do have 192 timeslices in my model with the same yearly structure. The sum of G_YRFR equals exactly one, however the single timeslices have different values according to season/weekday.
Both my PRC_TSL for the trade processes and COM_TSL for the traded commodity (electricity) are set to DAYNITE (thus -1).
PRC_CAPACT = 8.76 for all IRE processes, since capacity is given as 'GW' and activity as 'TWh'.
All trade processes' capacities are bounded via CAP_BND in the Tradeparametes scenario file.

So far I thought everything works well, since the summed yearly values are always correctly constrained. However, recently, I noticed that in some timeslices, the trade flows exceed the given capacity, like in this example:
(All of the following values refer to the same export/import-region pair, the same scenario, the same trade process and the same period.)
- G_YRFR(ts=xy) = 0.0029680365296
- CAP_BND = 2.4 GW
- VAR_FOut(ts=xy) = 0.0631 TWh ≙ 2.426923 GW (divided by 8.76 and G_YRFR)

The VAR_FOut value is slightly too high (should be 2.4 GW at max) since I want that the given capacity bounds the trade flows in every timeslice.

Then, I searched the documentation Part II (July 2016) and found in section 4.2.3, p. 118:
Quote:In TIMES, capacity by default bounds only the activity. However, with the NCAP_AFC / NCAP_AFCS attributes, one can bound the import / export flows instead. Capacity then also refers to the nominal maximum import (or export) capacity, e.g. the capacity of a transmission line in either direction.

The import/export commodity is the same in my model, thus in a next step I integrated:
NCAP_AFC(timeslice='DAYNITE', year=<BASEYEAR>, region='AllRegions', Pset_PN='TU_*', Cset_CN='ELC') = 1.0

However, I had no success, the exceedings became even higher.

Maybe, I misunderstand this sentence in the docs:
Quote:Remarks:
1. As any process has only a single capacity variable, the availabilities specified for the import/export flows are always proportional to the same overall capacity.

To me, the mentioned 'same overall capacity' sounds like the 2.4 GW.

So what am I doing wrong here?

Any help on this would be highly appreciated!
Regards,
Fabian
Reply
#45
Could you please provide some more information; At least I don't see any possibility to explain the problem without seeing at least all the process parameters of the process in question, corresponding to the situation where you get VAR_FOut(ts=xy) = 0.0631 TWh ≙ 2.426923 GW (i.e. before you started using NCAP_AFC).

One remark: Unless you have several commodities in the PG, there is no need to use NCAP_AFC.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)