Hi all,
I am still relatively new to TIMES - and am using the global TIAM model. I am trying to introduce some constraints to China, to constrain the total primary energy supply / final energy. I have attached an example Excel spreadsheet below with the two example constraints.
The first (Sheet1) attempts to enforce a 10% share of gas in TPES for China in 2020.
The second (Sheet2) is meant to limit final energy consumption in industry in China in 2020.
When I sync the file, I get the following warning:
VI: IRE processes need UC_IRE, UC_FLO will be ignored by TIMES.
For the Primary Energy constraint, the problem appears with MIN* processes. For the final energy constraint, the problem is with IMPNRGZ
I understand that UC_IRE is a constraint to do with trade flows. But I am not sure how I need to update my constraint worksheets in order to prevent these constraints having values ignored.
08-02-2019, 09:37 PM (This post was last modified: 09-02-2019, 04:10 AM by Antti-L.)
I suspect that you have modelled all the MIN* processes as trade processes, importing energy from an external "mining region". If so, you cannot use UC_FLO for the import flows, but you must use UC_IRE instead. For imports, the easier shortcut solution in VEDA would be to use UC_IRE-I. Both UC_FLO and UC_IRE define UC coefficients on process flow variables, but the first works only for flows of normal processes, and the second for trade process flows.
However, I wonder why on earth you have NRG under the Pset_Set column? NRG is the commodity type for energy commodities. So, I suspect that is in error, no?
Similarly, the dummy import process IMPNRGZ is a trade process, and you should probably just exclude it from the final energy constraint to avoid the warning about using UC_FLO for IRE.
24-09-2021, 07:07 PM (This post was last modified: 24-09-2021, 07:09 PM by Kristina.Haaskjold.)
Hi all, I have a similar problem as Neil. I have an offshore region where I want to export wind production. I want to give the model the option to invest in trade cables to Norway and to the UK, however I don't want the opportunity of importing electricity from the UK to Norway through my offshore region. I have tried to implement a user constraint with the following intention: Sum(export offshore region) <= Production wind farm. With other words, the amount of export to all regions (Norway or UK) should be constrained by the amount of wind produced. I have attached a photo of the UC.
My problem is that when I run the model, I never get investments to UK (even with marginal investment cost on cable and high electricity prices in UK). Even if I define an existing cable to UK, the model does not choose to export any electricity on this (even with artificially high UK prices). I thought defining two lines, one for UC_FLO to Norway and one for UC_IRE to international regions, would do the trick but it did not help. Can you see any other reasons for why the model does not allow for trade to UK?
Looking at the Attributes Master, you can see that UC_IRE expects the import/export indicator (IMP/EXP). I cannot see you defining any, and so I suspect that your constraint is reduced to the following:
-VAR_COMPRD(ELC-HV) ≥ 0
As you can see, you would then not be able to have production of ELC-HV at all. Is that what you are seeing?
Also, I don't see why you are defining both UC_FLO and UC_IRE for EE-RNW-WIND? I think it was clearly stated above in this thread that you can only use UC_IRE for trade processes and UC_FLO for normal processes, you can never use both.
27-09-2021, 10:59 PM (This post was last modified: 27-09-2021, 11:01 PM by Antti-L.)
Ok, I just tried a similar constraint specification myself with VEDA2, assuming that EE-RNW-WIND is a trade process, exporting ELC-HV to some other region(s). And indeed, I can see that the constraint is reduced to what I suspected above. Thus, the UC_FLO and UC_IRE were both ignored, the former because the process was a trade process, and the latter because no IMP/EXP indicator was specified.
However, I admit you did not in fact say what kind of a process that EE-RNW-WIND actually is, and so I cannot be sure it is a trade process, but your description seemed to suggest that it should be the case.
Nonetheless, a small correction to my earlier statement that UC_FLO cannot be used for a trade process: Actually that is not fully accurate, because you can use UC_FLO for capacity-related flows of a trade process (as they do not have the IMP/EXP indicator), but then you need also UC_ATTR(CAPFLO). I am sorry for this mistake, and hope it did not cause you any confusion.
28-09-2021, 11:30 AM (This post was last modified: 28-09-2021, 12:17 PM by Kristina.Haaskjold.)
(27-09-2021, 10:59 PM)Antti-L Wrote: Ok, I just tried a similar constraint specification myself with VEDA2, assuming that EE-RNW-WIND is a trade process, exporting ELC-HV to some other region(s). And indeed, I can see that the constraint is reduced to what I suspected above. Thus, the UC_FLO and UC_IRE were both ignored, the former because the process was a trade process, and the latter because no IMP/EXP indicator was specified.
However, I admit you did not in fact say what kind of a process that EE-RNW-WIND actually is, and so I cannot be sure it is a trade process, but your description seemed to suggest that it should be the case.
Nonetheless, a small correction to my earlier statement that UC_FLO cannot be used for a trade process: Actually that is not fully accurate, because you can use UC_FLO for capacity-related flows of a trade process (as they do not have the IMP/EXP indicator), but then you need also UC_ATTR(CAPFLO). I am sorry for this mistake, and hope it did not cause you any confusion.
Hi again Antti,
Thank you for the clarification!
Yes you were right that the both UC_FLO and UC_IRE were ignored as I did not have any IMP/EXP indicator. However, my EE-RNW-WIND is not a trade process, but represent the wind power aggregator. I therefore still use UC_FLO to represent the wind power that is generated by my wind farm. I have attached a screenshot of how I currently have modelled it. On an annual level it seems to be working as my total FOut on the trade cables is less than the produced wind power.
However, if I go to each timeslice I have import of electricity for some periods which apparently is added to the allowed export amount. I have attached a photo, where you can see that in timeslice SU_20 I have import in 2020 on cable TRDES_Sorlige_UK. If my constraint was working on timeslice level, the sum of the amount exported (VAR_FIn) on TRDEN and TRDN should be lower than VAR_FOut on EE-RNW-WIND.
Can you see from the UC what I am missing that allows for this import?
Sorry if this is a simple mistake, I am new to TIMES and this is my first time creating a UC. I very much appreciate your help on this
Unfortunately, I still am not quite able to see how you are modeling this, and what the issues actually are. For example, I can see in your results capture that you have processes TRDEN_Sorlige_UK, TRDES_Sorlige_UK and TRDN_Sorlige_NO2. I assume these three are now trade processes? But why do you have imports of ELC-HV into the Sorlige region (through TRDES_Sorlige_UK)? I thought the Sorlige region was supposed to be an offshore region exporting wind production, and so why would it be importing electricity? Is the imported electricity necessary for operating the offshore wind power plants?
But if you think your problem is related to your current constraint being defined at the ANNUAL level instead of being defined for each timeslice, sure, you can use the timeslice-dynamic UC feature of TIMES for easy defining the constraint on the DAYNITE level. The timeslice-dynamic feature is quite easy to use: just define UC_ATTR(FLO,DAYNITE) on the LHS side. Then the constraint is "pseudo-dynamic" only. And make sure your RHS constant is defined by UC_RHSRTS, because you cannot use UC_RHSRT or UC_RHST with a timeslice-dynamic constraint. That's all you need for defining your constraint for each DAYNITE timeslice.
This is exactly where my problem is. As you are saying, it is an offshore region and it should only be exporting wind production. At the moment, there is no demand in the offshore region and it should therefore not be any reason for it to import. However, at a later time I would like to add a fixed demand in the region in every hour. If it occurs that the wind farm does not produce enough electricity to cover this demand in every hour, it would have to import it. This is why I don't want to delimit import completely, but I want to add a restriction that export has to be lower than production in every hour. I tried to add the UC_ATTR(FLO,DAYNITE) to the LHS of the constraint, but it does not seem to do the trick.
From the attached picture, you can see that the import is very small (but more or less constant) in every hour. There is a cost related to the import, so there has to be some sort of requirement for this electricity. As it is so small, I thought it might be caused by losses or something else, but I can't see that this has been defined anywhere.
28-09-2021, 04:09 PM (This post was last modified: 28-09-2021, 04:10 PM by Antti-L.)
Thanks, now I understand the need for the import link(s)!
>If my constraint was working on timeslice level, the sum of the amount exported (VAR_FIn) on TRDEN and TRDN should be lower than VAR_FOut on EE-RNW-WIND.
Yes, that's exactly what the timeslice-dynamic constraint would accomplish.
>I want to add a restriction that export has to be lower than production in every hour. I tried to add the UC_ATTR(FLO,DAYNITE) to the LHS of the constraint, but it does not seem to do the trick.
Yes, that's exactly what the timeslice-dynamic constraint accomplishes, assuming that by production you refer to the VAR_FOut on EE-RNW-WIND. If you would you define the constraint on the DAYNITE level as I suggested, the sum of the amount exported (VAR_FIn) on TRDEN and TRDN will thus be lower than VAR_FOut on EE-RNW-WIND in every hour. Therefore, I am a bit confused why you say "it does not seem to do the trick". Can you clarify that?
28-09-2021, 07:07 PM (This post was last modified: 28-09-2021, 07:29 PM by Kristina.Haaskjold.)
Hi again,
Sorry for the late respons, I was running some test runs.
My last respons was a bit incorrect. I believe the DAYNITE is doing the trick to ensure that export < production in every hour, but I don't understand why I still have import of electricity in addition. If export = production then imported electricity would just be waste (but still cost to buy). The fact that it also imports about the same amount in each hour (see picture in last post) makes me believe there is some sort of demand or loss it has to make up for. Do you have any idea of what might cause this import? For your information, I am currently running with AFA = 1 on the cables.
>Do you have any idea of what might cause this import?
No, I don't. As you noted, imported electricity would just be waste (but still cost to buy), which does not make sense. Perhaps you could post the *.DD file for the scenario, where you define the UC_Offshore_exp, to verify how it gets written out there? The DD files are in the Work folder.
29-09-2021, 01:09 PM (This post was last modified: 29-09-2021, 01:09 PM by Kristina.Haaskjold.)
Hi Antti,
Here is a PDF copy of the *.DD file where I define the UC_Offshore_EXP. You can find the UC definition in the bottom of the file. It seems that even though I have UC_ATTR(FLO, DAYNITE) and UC_Sets: TS_E, it reads the constraint to be on annual level, am I right? I have EE-RNW-WIND, ELC-HV and all trade links on DAYNITE level, so I don't understand why the UC is defined on annual level.
29-09-2021, 02:34 PM (This post was last modified: 29-09-2021, 03:34 PM by Antti-L.)
>It seems that even though I have UC_ATTR(FLO, DAYNITE) and UC_Sets: TS_E, it reads the constraint to be on annual level, am I right? I have EE-RNW-WIND, ELC-HV and all trade links on DAYNITE level, so I don't understand why the UC is defined on annual level.
No, I see no indication of such. I just wanted to verify that it gets correctly written out for TIMES, and as far as I can see, it is indeed correct (thanks for showing the DD file). I also just tested a similar constraint myself and it was defined for each and every hour as expected. I verified that from the equation listing.
The only fully reliable way of verifying how the equations are defined is looking at the equation listing in the listing file (use LIMROW=999999 for getting all equations written out). If you insist on saying that it is not working as you expect, please show the equations by posting them here (use a ZIP file if the file is large).
