25-11-2021, 03:55 PM (This post was last modified: 25-11-2021, 03:57 PM by AkramS.)
Hello,
I try to generate a scenario where I want to increase efficiency or other attributes of already defined technologies. For this reason, I use a ~TFM_UPD table (enclosed file). When I sync the model I see that only EFF and NCAP_Cost are considered and not the AF or Share-I attributes. When I add TIMESLICES for these parameters, I get error even. Could please let me know the problem in this table?
Share-I is not working because you have ACT in Other_Indexes col. Just removing that should get it to work. AF must have a similar issue, but I don't see it in the doc you attached.
In general, you should use the minimum specification to identify values uniquely, and don't use default entries that are inserted by Veda. Like the commodity_group for FLO_SHAR, if not specified by the user.
I tried a table as in the enclosed file to change the efficiency (or other attributes) of some technologies from 2040 and onwards. These technologies had been earlier had been mainly defined in the SUBRES files. When I check the table I see that, for example, efficiency of technologies has been changed just in 2040 and not for the years after. Another problem is that the efficiency change is not as I have given in the table e.g. 1.5 times more than it was given in the SUBRES file. Could you please let me know how I can correct the table?
(21-12-2021, 10:09 PM)AKanudia Wrote: Q1: why do you have the "-0" in year2 in the first half of the table?
Q2: what are you trying to achieve in the year=year2=2012 section?
A1: I am not familiar with the MIG table (my first thought was to use UPD table) and so most probably my table is wrong. I wanted to extrapolate the change I made for 2040 onwards by the end of model time horizon.
A2: I just wanted that the model keeps the assumptions as they are for the first model years up to 2040.
As Amit has not responded, perhaps I can give some small suggestions, even though I am no VEDA expert.
The "-0" in Year2 activates the Time-series filtering option, which I think can indeed be quite useful here.
I tested it myself, with a test process EXAMSTD, which has EFF defined in a Subres for years 2020, 2030 and 2050.
Then, in a Scenario file, I use the following TFM_MIG table:
The resulting DD files no longer have any EFF defined for EXAMSTD in the Subres, because of being filtered out, as requested by the Time-series filtering option. But now, in the Scenario file, the source values to be multiplied are taken from the values defined for in the Subres scenario for 2020 and 2030. In the resulting DD file, the EFF is correctly defined with the original value for 2020, and is multiplied by 1.5 for 2030, just as requested in the TFM_MIG table. So, the resulting new EFF values look to be as intended, with the efficiency having the original value in 2020 and then is increasing linearly to 1.5 times the original value in 2030. And, the change I made for 2030 will indeed be extrapolated onwards to the end of model time horizon, just like you wanted (this is the default behaviour of TIMES), because any values defined earlier beyond 2030 have been now filtered out.
It seems to me that this could be close to what you were looking for? I hope it might be of some help.
(23-12-2021, 06:15 PM)Antti-L Wrote: As Amit has not responded, perhaps I can give some small suggestions, even though I am no VEDA expert.
The "-0" in Year2 activates the Time-series filtering option, which I think can indeed be quite useful here.
I tested it myself, with a test process EXAMSTD, which has EFF defined in a Subres for years 2020, 2030 and 2050.
Then, in a Scenario file, I use the following TFM_MIG table:
The resulting DD files no longer have any EFF defined for EXAMSTD in the Subres, because of being filtered out, as requested by the Time-series filtering option. But now, in the Scenario file, the source values to be multiplied are taken from the values defined for in the Subres scenario for 2020 and 2030. In the resulting DD file, the EFF is correctly defined with the original value for 2020, and is multiplied by 1.5 for 2030, just as requested in the TFM_MIG table. So, the resulting new EFF values look to be as intended, with the efficiency having the original value in 2020 and then is increasing linearly to 1.5 times the original value in 2030. And, the change I made for 2030 will indeed be extrapolated onwards to the end of model time horizon, just like you wanted (this is the default behaviour of TIMES), because any values defined earlier beyond 2030 have been now filtered out.
It seems to me that this could be close to what you were looking for? I hope it might be of some help.
Sure, yes, in my test it was. I think it may be important to specify the source scenario, to be sure the value is taken from the Subres as intended, because some other scenarios may also define some other values for the efficiency.
I fully agree with Antti, about the danger of picking up unintended seed values. It is recommended to specify the source scenario for UPD/MIG/FILL tables.
Now I have tried and it works when a technology has been defined in a SUBRES file.
I have some technologies which their efficiencies or costs have been defined in one or two scenario file(s). For these technologies the table still does not work. Should I use another type of table for these technologies?
Ok, I tested myself with a technology, which has its efficiencies defined in a scenario file.
I am seeing the TFM_MIG table working well, provided that the TFM_MIG scenario, which defines the modified EFFs, is sequenced alphabetically after the source scenario. That's because VEDA can only take values from alphabetically preceding scenarios when processing MIG tables (but, to my knowledge, from any Subreses or Base templates, @Amit: is that correct?).
Therefore, can you confirm whether your MIG scenario was alphabetically later or not (than the source scenario)?
(27-12-2021, 07:32 PM)Antti-L Wrote: Ok, I tested myself with a technology, which has its efficiencies defined in a scenario file.
I am seeing the TFM_MIG table working well, provided that the TFM_MIG scenario, which defines the modified EFFs, is sequenced alphabetically after the source scenario. That's because VEDA can only take values from alphabetically preceding scenarios when processing MIG tables (but, to my knowledge, from any Subreses or Base templates, @Amit: is that correct?).
Therefore, can you confirm whether your MIG scenario was alphabetically later or not (than the source scenario)?
OK. I checked and the scenario file containing the TFM_MIG table is alphabetically later than the other two scenarios.
(27-12-2021, 07:57 PM)Antti-L Wrote: But still not working? How can that be possible? It sure does work here...
OK. Now I analysed the technology again. The invcost of technology in the previous scenario file has been defined only for 2012. Now I want in the MIG table of the later scenario file to change the invcost from 2050. Could this be a problem (that in the earlier scenario file there is not an "invcost" for the technology in 2050)?
I have another question, for the other technologies that the MIG table works, I see (when I Browse the scenario file after Syncronization) that the values have been changed in the year I specified in the table (e.g, 2030 in your table above) and not onwards. Is this OK and it means that the table has extrapolated the change by the model time horizon?
27-12-2021, 09:08 PM (This post was last modified: 27-12-2021, 10:10 PM by Antti-L.
Edit Reason: improve wording
)
AkramS> Now I want in the MIG table of the later scenario file to change the invcost from 2050. Could this be a problem (that in the earlier scenario file there is not an "invcost" for the technology in 2050)?
Hmm… can you elaborate what this would exactly mean? You want to change Invcost "from 2050", but without any Invcost value for the technology in 2050? For which year(s) you would like to define the new values, and how would you derive them "from 2050", without having any original value for 2050?
AkramS> I see (when I Browse the scenario file after Syncronization) that the values have been changed in the year I specified in the table (e.g, 2030 in your table above) and not onwards. Is this OK and it means that the table has extrapolated the change by the model time horizon?
TIMES automatically extrapolates the last value defined onwards to the end of the model horizon. Here, "extrapolation" means that the rest of the model time horizon will also have that last changed value you have defined in your TFM_MIG table. If you are happy with that, then it is OK, meaning that those changed values will indeed be extrapolated to the end of the horizon. But if you would like to have some different trajectory for the extrapolation, you would just need to add some additional year(s) into your TFM_MIG table, with multipliers corresponding to your tailored extrapolation trajectory.
It sure does work here...