Issues using LPOINT
Closed this issue · 33 comments
This issue has been reported in kanors-emr/Veda2.0-Installation#26
TIMES related input for reproducing the issue is submitted here.
Hmm... I cannot find there any information about what the issue about LPOINT might be. The info given there seems to be about VEDA. Please describe what the related TIMES issue might be, and if possible, could you please provide a reproducible case, with a set of TIMES input files (to eliminate the impact of any VEDA versions, which is essential for diagnosing any TIMES issues). And of course, investigating TIMES issues is also much more efficient and less error-prone if a set of TIMES input files is provided for reproducing the case (i.e. VEDA files are not needed and are hardly even useful).
Thanks @Antti-L, the intention is to submit *.dd files here (incl. the corresponding gdx file). I just have not managed to do it in one go yet (the case in question originally took about 2 hours to run).
Ok thanks. But there you said:
The issue is gone when the input for those 4 technologies is corrected in this version.
So, are you saying that there is nonetheless some issue persisting in TIMES, although you saw the issue being gone after correcting your VEDA input data? If you do see that there is an issue with TIMES, can you disclose what that issue is, as you perceive it?
@Antti-L here are the .dd files and the gdx file. FIXBOH should be set to 2022 (I could not see from the run file where exactly it is set)
mitigation_cb.zip
Thanks.
But what is the TIMES issue that I should be able to reproduce with this case?
Tbh, I was really surprised that those 4 technologies could cause an issue like this. In the absence of any error messages an issue like this could become a huge headache for any user. More so if they don't use version control or have long periods of development without making model runs.
Thanks. But what is the TIMES issue that I should be able to reproduce with this case?
So basicallly, executing this case should lead to doubling of the objective function due to large dummy imports and production of some of the commodities (e.g. ELCC) should be absent in the fixed period.
Would a resulting gdx file be useful as well?
I cannot se any NCAP_AFC defined (or any missing parameter indexes) for those four pumped hydro processes. So, at least I cannot see there being anything to report about them in the QA_Check.log (NCAP_AFC is not mandatory for storage processes).
Can you suggest what in your view TIMES is doing wrong in this case?
I really do not know. To me this seems like some kind of a nasty bug. I think it would be really nice to get to the bottom of it, but also think that it can definitely wait to 2024.
On the observation side what puzzles me most is that I would have expected the results until 2022 to be the same as in the gdx they are fixed to, but that doesn't seem to be the case. That's why I thought it must have something to do with LPOINT, but I really don't know.
Ok, thanks, it is beginning to sound very puzzling indeed!
I will try to investigate when I have the time.
Ok, thanks a lot! I've got my model working, so definitely no rush on my side.
Thanks. But I just noticed that there is no FIXBOH present. So this case is actually not fixing the first periods to the previous solution.
So, it is an LPOINT without FIXBOH, that may give some clues...
@olejandro : I already made some tests, but could not reproduce the symptoms you mentioned:
- First of all, the case does not have any
FIXBOH, i.e. no periods were fixed to a previous solution. - In my tests, I am getting
ELCCproduced by about 100 PJ in 2018, and 104-130 PJ in 2019-2022. It includes e.g. imports, hydro, wind, and various thermal plants (gas, coal, peat). - I can see some dummy imports in the years 2018-2021, but they are not too large.
- I then tested the same case with the fixed parameters (as in your fixed VT_IE_PWR.xlsx). The objective function then increased by 0.05% (in your case I guess it decreased a lot). The small increase in the OBJ is as expected, because of the storage capacity specification was changed to output-normalized.
Consequently, thus far it seems to me that I am not able to reproduce the issues you were describing (e.g. large dummy imports, no ELCC being produced in the early periods, and that the few pumped hydro parameters would be causing a big difference).
@Antti-L, thanks a lot for looking into it!
As you can see in cases.json, the following entry is present:
"GdxUseSolution": {
"FixYearsUpto": "2022",
...
}
At the same time, like you, I also was not able to find FIXBOH in the run file. Do you think this info is passed differently to GAMS by Veda? @akanudia any chance you could help us figure it out? I believe this is essential for reproducing the issue, because without fixing the initial years the issue does not occur.
@Antti-L I am also sharing here the results of the run (e.g. to compare the objective functions). The files need to be unzipped and then combined with 7-Zip.
mitigation_cb.gdx.001.zip
mitigation_cb.gdx.002.zip
Well yes, there could be a large difference in the OBJ between a case that uses FIXBOH and a case that doesn't, because the case you provided does have a large impact of the dummies to the OBJ, due to some dummies for demands. I suspect now that maybe you actually compared such very different cases? However, I am not able to reproduce any absent production of ELCC (with or without FIXBOH), and so there could have been even more differences in your cases...
Do you think this info is passed differently to GAMS by Veda? @akanudia any chance you could help us figure it out?
No. If FIXBOH is used, VEDA writes it to the RUN file. That's the only way it's designed to be working. I think your first run (with the higher OBJ) has probably been run without FIXBOH, and then you compared it to a FIXBOH case. If so, that would not be a TIMES issue. But if you can provide a reproducible case showing otherwise, please do.
Ok, so it sounds like a Veda issue then, because as you can see from the cases.json the correct setting are stored there.
Besides, on my side, I have been able to reproduce the issue at least 3 times already; each time deleting the model. However, every time I did so I used Veda and have not yet tried reproducing it using GAMS directly...
So, have you actually been able to reproduce the "absent ELCC production" (in the fixed years) as well? That would be important to see... so can you provide all the work folder files from such a case?
Well, yes, but as you say FIXBOH did not make it to the run file for some reason, so I guess, the missing ELCC production for some processes is due to their output being optimised instead of being fixed to values from the other case....
Thanks. It is starting to look all much clearer now.
Just an additional small note: Also the listing file you provided confirms that FIXBOH was not used in your run case (and so VEDA did not pass that FIXBOH info in any way for the run).
However, I still don't get why the objective function would double in the case where FIXBOH is not set compared to the case where FIXBOH is set. The cases are same, except for those 4 processes and FIXBOH. The cases have very tough mitigation constraints, incl. a carbon budget for 2020-2025, so not setting FIXBOH should actually make it easier and cheaper to meet...
It is because the GDX file, when used for the fixing of first periods, does not have those dummy imports for demands. That GDX file must have been produced from a run where the model was a bit different. I tested fixing with that GDX file (the one you provided), and it confirms this: there were no dummies for any demands in that GDX file! (and the results can then remain such, because the model equations are eliminated for the fixed periods).
Ok, so let me just do a test where I do not attempt to fix the initial period for the case in question (I know it doesn't get fixed anyway despite the setting). I guess there should be no difference in the results?
there were no dummies for any demands in that GDX file!
Except for some small ones, correct?
No, there were none at all in the GDX file you provided. Only energy dummies (IMPNRGZ). And you have high cost for the demand dummies, which indeed fully explain the OBJ difference.
Ok, sorry, for some reason I missed "demand", only saw dummies.
Let me just do a couple tests, because I am puzzled by those demand dummies. Based on the constraints included in the case they should not have occurred.
Btw, does activating LPOINT without any FIXBOH has any effect/impact on results?
It should cause the previous solution to be used as a starting basis by Cplex, if the solution is complete enough. In that case Cplex would resort to simplex (which can make use of the "warm restart"). However, GAMS may have changed the default BRATIO (which controls the completeness of the basis required). Anyway, in this case Cplex proceeds with Barrier, and it apparently has no effect.