Veda2.0 Released!


How do I add additional element to prc_grp?
#16
you don't see these _ENS items on the CommGrp tab under Items Detail?
Reply
#17
Hi Amit

No, they don't appear in CommGrp tab under Items Details, nor in the Sets Browser tab.
Reply
#18
Okay now after restart they appear items details but not in sets browser...
Reply
#19
You do need to refresh the Items view after sync, if it is already open. These are commodity groups, not sets. They will not show up in sets browser. But they should make it to the GDX.
Reply
#20
I am a bit confused by that TFM_COMGRP picture.  I thought you wanted to get the VEDA sets into the GDX file.  But in that picture, you are not putting the VEDA set names into the CSet_Set column (it was all empty in your picture), why?  Huh
Reply
#21
So I wanted to create some commodity sets that could be exported to the GDX for further use down the reporting road (and linking with other models).

Using the previous picture's TFM_COMGRP table I can get commodity groups to appear in the items detail, but they are not exported to the GDX.

Changing my TFM_COMGRP table as attached, they now do not appear in itmes detail and are again not exported to the GDX.

Again, the PRC_GMAP works like a charm for the proces sets. 

I am sure I misunderstand something regarding the commodity sets, but can't seem to get my head around it?


Attached Files Thumbnail(s)
   
Reply
#22
I am puzzled by that problem. 
As I mentioned above, I tested it with the DemoS7 model, which does have some VEDA sets defined.
I added these sets into the TFM_COMGRP table in SysSettings, by putting these set names into both CSet_Set and Name column, such that the corresponding commodity groups with the same name are defined. 

And I checked that they do appear in the GDX file, with the correct members. So, the COM_GMAP route for commodities worked pretty much equally well as the PRC_GMAP for processes.
Reply
#23
Ah okay I have made a mistake (at least one).

My mistake was that I misunderstood you earlier, Antti, when you said to use the TFM_COMGRP. I then thought I should define the VEDA sets AND the commodity group this way. When in fact I should initially define the sets, and then do what you said about putting the defined sets in the TFM_COMGRP in SysSettings.

Now the commodity sets are defined and found in VEDA, and also the commodity groups are defined and found in VEDA. BUT I still can't get the commodity sets/groups into the GDX.

I have attached the definition of the sets and the TFM_COMGRP table.

Thank you very much!

Cheers,
Steffen


Attached Files Thumbnail(s)
           
Reply
#24
What are you looking for, and how, in the GDX file?  The commodity groups are defined in the set COM_GMAP, just like the process groups are in the attribute PRC_GMAP. Your SysSettings.DD file should indeed contain the appropriate entries, and if so, they will inevitably be included in the GDX file. So can you post that DD file (zipped)?
Reply
#25
Dear Antti

All seems to work fine now after a restart of veda (PC-restart). COMP_GMAP appears in both the dd-file and the GDX.

Again, thank you very much for the help (and the patience) :-)

Cheers
Steffen
Reply
#26
(14-09-2023, 04:24 PM)SDockweiler Wrote: 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):

I have a follow-up on this post concerning a heartfelt wish for a quality of life improvement in terms of allowing com_gmap to be defined or amended in a scenario file.

I rely heavily on com_gmap and prc_gmap in the TIMES gdx output for defining commodity and process group set used for automated postprocessing and reporting. However, when defining com_gmap and prc_gmap my understanding based on this treat is that com_gmap needs to be defined in syssettings.xlsx using ~TFM_COMGRP whereas the prc_gmap is defined in a scenario file using ~TFM_INS. It would really be significant improvement if it was possible to define ~TFM_COMGRP in the same scenario file where I define the prc_gmap? An alternative solution would be to allow the user to define com_gmap or amend data to com_gmap using ~TFM_INS in the scenario file. Would this be difficult to implement?

Background: In my current setup I have to manually copy information from the the Sets-TIMES-modelname.xlsx file (related to commodity group set) both to 1) syssettings.xlsx and to 2) a dedicated scenario file used for reporting. It would be so nice I only had to copy information from Sets-TIMES-modelname.xlsx to the scenario file.

Best,

Kristoffer
Reply
#27
(14-09-2023, 04:24 PM)SDockweiler Wrote: 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):

I have a follow-up on this post concerning a heartfelt wish for a quality of life improvement in terms of allowing com_gmap to be defined or amended in a scenario file.

I rely heavily on com_gmap and prc_gmap in the TIMES gdx output for defining commodity and process group set used for automated postprocessing and reporting. However, when defining com_gmap and prc_gmap my understanding based on this treat is that com_gmap needs to be defined in syssettings.xlsx using ~TFM_COMGRP whereas the prc_gmap is defined in a scenario file using ~TFM_INS. It would really be significant improvement if it was possible to define ~TFM_COMGRP in the same scenario file where I define the prc_gmap? An alternative solution would be to allow the user to define com_gmap or amend data to com_gmap using ~TFM_INS in the scenario file. Would this be difficult to implement?

Background: In my current setup I have to manually copy information from the the Sets-TIMES-modelname.xlsx file (related to commodity group set) both to 1) syssettings.xlsx and to 2) a dedicated scenario file used for reporting. It would be so nice I only had to copy information from Sets-TIMES-modelname.xlsx to the scenario file.

Best,

Kristoffer
Reply
#28
There is a notable difference between the COM_GMAP defined by TFM_COMGRP and PRC_GMAP:  TFM_COMGRP also has to declare the CGs for the GAMS domain set COM_GRP, and all those CGs are supposed to be available for being used in numerous TIMES attributes that expect a CG as one of its indices, in any scenario, and including the headers of FI_T tables. PRC_GMAP on the other hand does not introduce new elements in any domain set. Therefore, PRC_GMAP can well be defined in scenario files, while the CGs introduced by TFM_COMGRP need to be declared in the base scenario, and apparently must be known to VEDA before processing all scenarios (by reading it from SysSettings first).

I guess that is the reason why the use of TFM_COMGRP is restricted to SysSettings. Adding new members to an existing CG should, however, be quite doable in scenarios, and I would be pleased if that would be made possible. However, I am not sure if that would correspond to what was meant by "amend data to com_gmap using ~TFM_INS".
Reply
#29
>>Adding new members to an existing CG should, however, be quite doable in scenarios, and I would be pleased if that would made possible.

Sounds great.

With amend I was thinking about the feature the $onMulti feature in GAMS, useful when adding additional element to an existing set. However, that is like not relevant here.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Error 170 Domain violation for element BrageAG 11 11,014 10-05-2021, 06:40 PM
Last Post: Antti-L

Forum Jump:


Users browsing this thread: 1 Guest(s)