I am looking for some help and guidance in terms of how to add an additional element to the prc_grp (proces group) in a TIMES model. As I understand the following groups are available by default:
To illustrate[/font] [font=Monaco, Menlo, Consolas, "Courier New", monospace]I would like to add the following element "DMDHOU" to prc_grp to reflect household heating demand processes. What I hope to accomplish is the following:
1) That I can define a household heating proces as being part of both DMD and HOUDMD.
2) Ensure that HOUDMD is included in the PRC_GRP set in the TIMES GDX output file. This is important for reporting purposes as it offers an easier way of filtering household heating process in my GAMS reporting script.
Cheers,
Kristoffer[/font]
Kristoffer S. Andersen
<br />Advisor, Danish Energy Agency
07-10-2022, 02:43 PM (This post was last modified: 07-10-2022, 02:53 PM by Antti-L.)
As you posted this question on the VEDA 2.0 Sub-Forum, I assume that you need to see the additional process groups in VEDA2.0, for easier creation of results reporting tables.
That can be easily accomplished by adding process sets in VEDA2.0:
Go to Tools → Sets → Sets Editor, and create the new sets.
-----
However, if you would like to add such sets also in the TIMES code, such that they appear in the GDX file TIMES produces, that kind of adjustment would basically no longer be related to Veda. Such is also possible, but would unfortunately require code changes, and if you for some reason would like to do that, you should create a TIMES extension, where you define the GAMS sets for each of the new sets, e.g. with:
SET DMDHOU(r,p) 'Household demands';
DMDHOU(R,P) $= GR_GENMAP(R,P,'DMDHOU');
And then also customize the directive file times2veda.vdd by adding an entry:
DMDHOU DMDHOU r p
If the new extension is named, say DEA, you should put the code into the file rpt_ext.dea, and add the extension hook into the run file template.
Ahh, you also said that you would need it in the PRC_GRP. Then you also need to add DMDHOU in the set PRC_GRP, and then you can add the processes into PRC_MAP:
(07-10-2022, 02:43 PM)Antti-L Wrote: As you posted this question on the VEDA 2.0 Sub-Forum, I assume that you need to see the additional process groups in VEDA2.0, for easier creation of results reporting tables.
That can be easily accomplished by adding process sets in VEDA2.0:
Go to Tools → Sets → Sets Editor, and create the new sets.
-----
However, if you would like to add such sets also in the TIMES code, such that they appear in the GDX file TIMES produces, that kind of adjustment would basically no longer be related to Veda. Such is also possible, but would unfortunately require code changes, and if you for some reason would like to do that, you should create a TIMES extension, where you define the GAMS sets for each of the new sets, e.g. with:
SET DMDHOU(r,p) 'Household demands';
DMDHOU(R,P) $= GR_GENMAP(R,P,'DMDHOU');
And then also customize the directive file times2veda.vdd by adding an entry:
DMDHOU DMDHOU r p
If the new extension is named, say DEA, you should put the code into the file rpt_ext.dea, and add the extension hook into the run file template.
Ahh, you also said that you would need it in the PRC_GRP. Then you also need to add DMDHOU in the set PRC_GRP, and then you can add the processes into PRC_MAP:
PRC_MAP(R,'DMDHOU',P) $= GR_GENMAP(R,P,'DMDHOU');
Dear Antti,
Thank you very much, I will look into the second option, which is exactly what I think I need :-D
I might return at with a follow up question in terms of how I should add an $include timesreport.gms option to the template (e.g., bottom-up of the times run-file), so that by default my times report script (timesreport.gms) is included every time I solve the TIMES model.
Have a great weekend,
Kristoffer
Kristoffer S. Andersen
<br />Advisor, Danish Energy Agency
07-10-2022, 05:08 PM (This post was last modified: 10-10-2022, 01:29 PM by Antti-L.)
Actually, in your case an extension might not bee needed, but you can just add a call to your reporting routine in the RUN file by using the Veda RFCmd_Bot attribute. Then it would be always called ($include timesreport.gms) at the end of the RUN file.
Unfortunately, that nice RFCmd_Bot Veda attribute seems to be undocumented...
[Edit:] Ahh... although it is not included in the online documentation, it is shown under VEDA (TIMES Attributes).
However, note that calling your timesreport.gms routine directly from within TIMES may require some compatibility considerations, i.e. it might not work without some changes in your GAMS code.
(07-10-2022, 05:08 PM)Antti-L Wrote: Actually, in your case an extension might not bee needed, but you can just add a call to your reporting routine in the RUN file by using the Veda RFCmd_Bot attribute. Then it would be always called ($include timesreport.gms) at the end of the RUN file.
Unfortunately, that nice RFCmd_Bot Veda attribute seems to be undocumented...
[Edit:] Ahh... although it is not included in the online documentation, it is shown under VEDA (TIMES Attributes).
However, note that calling your timesreport.gms routine directly from within TIMES may require some compatibility considerations, i.e. it might not work without some changes in your GAMS code.
Thanks Antti, the RFCmd_Bot works like a charm.
Based on working with the above, I have a request for the VEDA/TIMES interface. Would it be possible to include the sets defined in VEDA from the SetDefinition.xlsx into the times gdx-file? This could perhaps be done by defining a new set in the TIMES gdx-file, e.g.:
SET VEDA_pset_map(r,p,VEDA_pset);
Based on the discussion above VEDA_pset would include "DMDHOU", and the VEDA_pset_map would include associated regions and processes. This would be of great help for the GAMS reporting tool I use. However, it might also be a helpful feature for other teams working with linking a TIMES model with other models solved using GAMS (e.g. general equilibrium model). Since having asses to a set like VEDA_pset_map makes filtering processes from TIMES using conditional statements in GAMS so much easier.
Cheers,
Kristoffer
Kristoffer S. Andersen
<br />Advisor, Danish Energy Agency
Well yes, I am sure that such a new attribute could be implemented if there is general interest.
But does that mean that are you not happy with the method I already suggested above:
SET VEDA_pset_map(r,p,item);
VEDA_pset_map(r,p,item) $= GR_GENMAP(r,p,item);
With these statements in your reporting routine you would have the set VEDA_pset_map defined in the TIMES GDX file. You would of course need to define GR_GENMAP in a VEDA scenario, but that would be easy, example below:
Thank you Antti for providing me with a missing link, i.e. defining the GR_GENMAP within a VEDA scenario. For whatever reason I was thinking that I had to define the GR_GENMAP outside VEDA. I will try to introduce the GR_GENMAP into a scenario file and provide some feedback after testing.
/Kristoffer
Kristoffer S. Andersen
<br />Advisor, Danish Energy Agency
(12-10-2022, 02:10 PM)kristofferand Wrote: Thank you Antti for providing me with a missing link, i.e. defining the GR_GENMAP within a VEDA scenario. For whatever reason I was thinking that I had to define the GR_GENMAP outside VEDA. I will try to introduce the GR_GENMAP into a scenario file and provide some feedback after testing.
/Kristoffer
Defining the GR_GENMAP parameter within VEDA seems to do the trick. Even better, it seems that having the GR_GENMAP in the GDX-file is just what I need in terms of filtering processes in my timesreport gams script. Hence there is no need for the TIMES extension that links GR_GENMAP to PRC_GRP and PRC_MAP.
Thanks a million, Antti :-)
Kristoffer S. Andersen
<br />Advisor, Danish Energy Agency
Following up on this post, we at the DEA would like to also export commodity sets to the GDX. This could be a fuel mapping. Would this be possible in another attribute, e.g. "GR_FULMAP" instead of "GR_GENMAP"?
In any case we have a hard time getting any commodity sets exported using the "GR_GENMAP" attribute, possibly since this attribute is defined with GR_GENMAP(P, ., .) and not (C, ., .).
I'd like to make the following points for your information:
● Because GR_GENMAP is also used in two TIMES extensions, there is a risk of some inadvertent interference. Therefore, since TIMES v4.6.6 there has been a new attribute PRC_GMAP(reg,prc,item) (identical to GR_GENMAP), which can be freely used for user process groupings.
● COM_GMAP can be used for any user-defined groupings of commodities. But I would recommend some prefix for easy distinguishing of your reporting groups from other groups.
● COM_GMAP groups can be defined in SysSettings.
PRC_GMAP seems to be working perfectly, putting all desired sets into the parameter.
COM_GMAP on the other hand does not seem to input the extra desired user defined sets.
I input into the COM_GMAP using "~TFM_Csets" as in the demo and apply a scenario file almost identical to the one you provided above, but with "Cset_set" instead of "Pset_Set". Am I missing some form of decleration to get the sets (which are correctly imported to VEDA) exported to the GDX?
14-09-2023, 02:39 PM (This post was last modified: 14-09-2023, 02:54 PM by Antti-L.)
If it does not work, it is a VEDA problem. But did you use "y" in the cells? The table for defining COM_GMAP is ~TFM_COMGRP.
I think it would be highly desirable that it would work, like you said. Let's see what the VEDA developers say.
[Edit:] I think ~TFM_Csets is used for defining the VEDA sets, not for TIMES attributes. But the idea is that you use those VEDA sets in the CSet_Set column for defining the corresponding COM_GMAP for TIMES.
I just tested it with Demos7, and it worked well. The VEDA sets were correctly defined in COM_GMAP, and subsequently appeared in the GDX file. So, I cannot confirm your statement that it would not work.
Could you perhaps post your ~TFM_COMGRP table here (from SysSettings), to see what you are doing?
I think the problem at my part was that i tried to implement the commodity sets using ~TFM_Csets and not the ~TFM_COMGRP. I found out (as you said) that this can only be declared in the syssettings file.
Here is my COMGRP table from SysSettings, which again doesnt seem to import the sets (not even to VEDA):
