Veda2.0 Released!


Problems with FLO_EMIS
#1
Hi!

I have recently run into problems when trying to assign emission factors in my model. The emission factors register as it they should in both the SubRES files and base year file (see the attached "Picture1" showing the TIMES-view in VEDA, the yellow marked area is the base yeaar technology). 

However, for some reason, the technologies in the BASE year generates the following error (from the QA-check, which is also attached): "FLO_SUM Commodity Not in CG1 - parameter ignored". 

This makes my base year technologies behave strange and with no emissions, while the SubRes technologies work as intended. All emission factors have been assigned in the exact same way, using a scenario file. 

Could someone please try to help me figure out what could be the problem?
I also attached the LST file, if that could be of any help.

Best regards
Erik


Attached Files Thumbnail(s)
   

.txt   Test4.txt (Size: 248.15 KB / Downloads: 3)
.txt   QA_CHECK.txt (Size: 45.9 KB / Downloads: 3)
Reply
#2
I cannot see anything in the screenshot, something wrong with the picture?

To see why your emission factors do not work as expected, could you thus show (for an example process), the process topology, the commodity types of the commodities in question, and the VEDA TIMES view for the emission parameters.
Reply
#3
(14-10-2019, 03:30 PM)Antti-L Wrote: I cannot see anything in the screenshot, something wrong with the picture?

To see why your emission factors do not work as expected, could you thus show (for an example process), the process topology, the commodity types of the commodities in question, and the VEDA TIMES view for the emission parameters.

Hmm, I accidentally uploaded the wrong picture in the first try, which i then edited. Maybe my edit did not work properly (I have some internet connection issues at the moment). Is it possible to see it now? 

For your second part of the question, how can I provide that information in the easiest way?

/Erik


Attached Files Thumbnail(s)
   
Reply
#4
Ok, thanks for the updated screenshot showing the FLO_EMIS parameters.

Could you show from the Process Master the Process Information tab for an example process having the problem?  For example, ISF-BLAFU00-BFG?  And, if the emission commodities (INDCO2-Bv, INDCO2-Mv) are not explicitly in the process topology, could you please also show the Commodity Information for them from the Commodity Master?

(BTW: Note that there is no need for defining the interpolation options 3 for FLO_EMIS, as that is the default.)
Reply
#5
(14-10-2019, 05:09 PM)Antti-L Wrote: Ok, thanks for the updated screenshot showing the FLO_EMIS parameters.

Could you show from the Process Master the Process Information tab for an example process having the problem?  For example, ISF-BLAFU00-BFG?  And, if the emission commodities (INDCO2-Bv, INDCO2-Mv) are not explicitly in the process topology, could you please also show the Commodity Information for them from the Commodity Master?

(BTW: Note that there is no need for defining the interpolation options 3 for FLO_EMIS, as that is the default.)

Ok! I have attached the process information of one technology that do not work (BLAFU00), one that works (BLAFU01), and the commodity information of the emission commodities connected with both processes (INDCO2-Fv, INDCO2-Bv, and INDCO2-Mv).


Attached Files Thumbnail(s)
                   
Reply
#6
Thanks.  Unfortunately, I am not able to spot any clue for the problem there.

I also tested myself with a similar process (albeit with less flows) but could not reproduce the problem.

If you have not already found the problem yourself, but would like to get it resolved ASAP, I would be willing to help. But to save time, could you then provide me with the model input files (*.DD, *.RUN)?  Maybe you could upload them (e.g. to Dropbox) and send me the download link (in a private message)?
Reply
#7
Dear Erik,

Thanks for providing the model input files, for my testing!

However, by running the model from these input files, I am not able to reproduce the problem. See below the contents of QA_CHECK.log I am getting for the model run, where I think there are no warnings related to the processes you described (and very much less warnings):

             ******          TIMES -- VERSION 4.3.7           ******
             **************   QUALITY ASSURANCE LOG   **************

*** FLO_EMIS with no members of source group in process - ignored
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBCP COM=FUECO2-Bc
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBCP COM=FUECO2-Bv
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBDU COM=FUECO2-Bc
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBDU COM=FUECO2-Bv
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBRK COM=FUECO2-Bc
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBRK COM=FUECO2-Bv
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBRS COM=FUECO2-Bc
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBRS COM=FUECO2-Bv
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBWO COM=FUECO2-Bc
*01 WARNING       -     R=SE           P=FUE-ETH1100-BIO CG=FUEBWO COM=FUECO2-Bv


*** RPC in TOP not found in any ACTFLO/FLO_SHAR/FLO_FUNC/FLO_SUM
*01 WARNING       -     R=SE           P=ISF-SMEFA01c C=FUEBCH-ISF   IO=IN
*01 WARNING       -     R=SE           P=ISF-SMEFA01c C=FUECOA-ISF   IO=IN


So, is it possible that the problem has vanished already?  Huh
Reply
#8
Thanks for the feedback Antti!

Hmm, that is odd! I just tried to run the model again, but the problem is still there. Is there anyway to start from a clean slate? I have tried the "start from scratch" option a few times in VEDA but without success. 

/Erik
Reply
#9
Ok, thanks for confirming.

I tested now with GAMS v24.7 (your version of GAMS), and I was now immediately able to reproduce the problem!

This indicates that we have a GAMS-related problem here, which is ... hmm... pretty unexpected and possibly a rather serious matter. I am going to have to investigate this to the bottom, so unfortunately no resolution is available at this point (other than maybe by downgrading GAMS). According to my initial tests, GAMS 24.0 and below work as expected.  So, GAMS v24.7 produces the unexpected results, but other versions remain to be tested....

Sorry for this, it is getting a bit messy.  But occasionally GAMS does have bugs too...

[EDIT:] I just tested with GAMS 24.8.5, and it worked as expected!  This suggests that the problem may be only related to GAMS v24.7.  Therefore I would recommend to update your GAMS to any newer version, if possible.
Reply
#10
(14-10-2019, 07:27 PM)Antti-L Wrote: Ok, thanks for confirming.

I tested now with GAMS v24.7 (your version of GAMS), and I was now immediately able to reproduce the problem!

This indicates that we have a GAMS-related problem here, which is ... hmm... pretty unexpected and possibly a rather serious matter. I am going to have to investigate this to the bottom, so unfortunately no resolution is available at this point (other than maybe by downgrading GAMS). According to my initial tests, GAMS 24.0 and below work as expected.  So, GAMS v24.7 produces the unexpected results, but other versions remain to be tested....

Sorry for this, it is getting a bit messy.  But occasionally GAMS does have bugs too...

No worries! At least we now seemingly have a clue what is causing the issue. I will keep my eyes and ears open for any update on the matter. In the meantime I will see if I can get hold of version 24.0 of GAMS. [Edit] *the 24.8.5 version it is then. Thank you for your help!


/Erik
Reply
#11
Ok, here are some more test results:
  • GAMS v24.4 and below appear to work well.

  • GAMS v24.5 – GAMS v24.7 appear to have a bug, causing the unexpected problems in TIMES.

  • GAMS v24.8 and above appear to work well again (tested a few versions up to v28.1).


I hope that helps.
Reply
#12
It helps, the model is now running as intended, with GAMS version 28.2.
Reply
#13
Thank you for the good news.

My investigation has revealed some additional information: The issue was apparently being triggered by the domain violations in your model. Although there were only a few domain violations (related to the undefined process UE-ETH1100-BIO), and these were basically unrelated to the serious problems that were then manifested, the bug in those GAMS versions mentioned above caused incorrect processing of the model topology, when the model had the domain violations. But I tested also by removing the 10 FLO_EMIS parameters defined for UE-ETH1100-BIO, and the problems then no longer occurred!

It would be good modelling practice to check for any domain violations and eliminate them from the model (you can see the GAMS warnings in the listing file). But I know that many TIMES models (perhaps even the majority I have had the chance to have a look at) do have some domain violations, at least during model and/or scenario development and testing phases. Therefore, I would think that this GAMS bug may actually have been affecting many users.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)