Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange results when using GDX Reference #26

Open
olejandro opened this issue Dec 22, 2023 · 18 comments
Open

Strange results when using GDX Reference #26

olejandro opened this issue Dec 22, 2023 · 18 comments
Assignees

Comments

@olejandro
Copy link

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
Copy link
Author

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

@akanudia
Copy link
Contributor

@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

This comment was marked as resolved.

@Antti-L
Copy link

Antti-L commented Dec 22, 2023

@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

This comment was marked as resolved.

@olejandro
Copy link
Author

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
Copy link
Contributor

akanudia commented Dec 23, 2023

@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
Copy link

Antti-L commented Dec 24, 2023

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
Copy link
Contributor

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

@olejandro
Copy link
Author

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

@akanudia
Copy link
Contributor

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

@olejandro
Copy link
Author

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

@akanudia
Copy link
Contributor

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

This comment was marked as resolved.

@olejandro
Copy link
Author

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
Copy link
Contributor

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

@olejandro
Copy link
Author

olejandro commented Dec 26, 2023

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
Copy link
Contributor

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

@deepakgupta256 deepakgupta256 self-assigned this Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants