Strange results when using GDX Reference

[olejandro]

I've had a very strange experience when using GDX Rerence with this model version. Basically, when running Mitigation_CB the objective function doubles compared to No_Mitigation (i.e. GDX reference until 2022) and some results in the fixed periods appear to be missing (e.g. for commodity ELCC).

It seems that this can be traced to missing indexes for attributes of 4 technologies specified in this file, range Processes!X67:AD70. No error was thrown and no entries appear to be present in QA_CHECK.LOG regarding these.

The issue is gone when the input for those 4 technologies is corrected in this version.

[olejandro]

@Antti-L I am a bit unsure whether this should have been opened in the TIMES repository instead?

[akanudia]

@olejandro, I imported the model in the current version of Veda and the data in the range you mentioned appeared OK in browse even in the original version of that file. Do you get a different reading behaviour after moving those parameters to a new table?

[Antti-L]

@Antti-L I am a bit unsure whether this should have been opened in the TIMES repository instead?

@olejandro : If you think the issue is related to TIMES, could you please provide a reproducible case (the .DD, .RUN files, plus any GDX file if needed for reproducing the model run). The listing file would also be helpful.

[Antti-L]

@akanudia I looked at the original file, and I see NCAP_AFC defined there without any CG index specified (Processes!X67:AD70). Does that really work (what will be the default CG?), or am I missing something?

[Antti-L]

No error was thrown and no entries appear to be present in QA_CHECK.LOG regarding these.

@olejandro : If there are missing indexes for attributes, there will be GAMS domain violations, which TIMES filters out and issues a warning in the QA_CHECK.LOG. Domain violations cannot be caught by TIMES in a more detailed way, because they cause strange phantom parameter entries. If you say that no warning appears in the log about domain violations (even if there are missing indexes), I would indeed be interested to have a reproducible case.

[olejandro]

I am using this Veda version. There is some difference between the tech data shown in browse. For the model version that experiences the issue, NCAP_AFC is not shown and STG_EFF is specified for 1974 (2018 in the version that doesn't experience the issue).

[akanudia]

@akanudia I looked at the original file, and I see NCAP_AFC defined there without any CG index specified (Processes!X67:AD70). Does that really work (what will be the default CG?), or am I missing something?

@Antti-L , sorry for the confusion. I just pulled the main branch without realizing that it had a different version of that file. The file that Olex had pointed to would certainly have "commodity_group" as the CG for AFC.

[Antti-L]

The file that Olex had pointed to would certainly have commodity_group as the CG for AFC.

Sorry for being slow (once again), but I cannot see any commodity_group specified for the AFC in that file. Do you mean literally 'commodity_group', i.e. leading to a domain violation?

[akanudia]

@Antti-L, I meant text "commodity_group", which would lead to domain violation. I have corrected my original message too.

[olejandro]

@akanudia, as far as I could see no "commodity_group" text was added, so no domain violation was generated.

[akanudia]

@olejandro, can you please what was there in the commodity_group index then?

[olejandro]

Nothing, as far as I could see in Browse. The attribute is just not displayed.

[akanudia]

OK, thanks for pointing this out. I see some inconsitency in the way missing informaiton is handled in FI_T and TFM tables. We will streamline this in the next update.

[Antti-L]

Thanks Amit And Olex. That is what raised my confusion about it, as Olex said that there were neither error messages nor anything in the QA_check.log.

[olejandro]

Thanks @akanudia. Any kind of feedback would definitely be helpful in a case like this. Even better if it is consistent between FI_T and TFM tables.

It seems that this issue occurs due to a missing FIXBOH setting in the run file. This should not have anything to do with the input table, right? As far as I can see, the setting is stored correctly in cases.json...

[akanudia]

Correct, nothing to do with Excel files. FIXBOH is defined in the GDX references part of the case definition form.

[olejandro]

What could it be then? I was able to reproduce the issue several times and each time I would check that GDX reference is specified in the form and the year to fix solution up to is chosen...

[deepakgupta256]

@olejandro let us do a web meeting to understand this problem.