Dear all,
I am trying to implement an annual growth constraint (10% per year) on a process installed capacity, using a UC scenario file, but I have some troubles in the result at the end of the modelling horizon, as the bound is not respected. Indeed, in 2100 (last milestone year) there is a spike in installed capacity, while up to 2090 the constraint was met.
Probably I am doing something wrong in the way the constraint is defined and/or the extrapolation rule which is applied.
Can someone help me?
this is how the UC scenario file has been defined:
and these are the results obtained in VedaBE, with the spike at the EOH
Hmm... looks strange; I cannot see what might be wrong here.
I just tested with a similar constraint in a small test model, and it worked well: the capacity in the last period was constrained fully as expected, according to the growth coefficient specified.
Could you perhaps post the TIMES input file (*.dd) for this particular scenario (ZIP compressed)?
And please also state the version of TIMES you are using (see the top of QA_check.log, where the version number should be reported).
(17-04-2018, 04:51 PM)Antti-L Wrote: Hmm... looks strange; I cannot see what might be wrong here.
I just tested with a similar constraint in a small test model, and it worked well: the capacity in the last period was constrained fully as expected, according to the growth coefficient specified.
Could you perhaps post the TIMES input file (*.dd) for this particular scenario (ZIP compressed)?
And please also state the version of TIMES you are using (see the top of QA_check.log, where the version number should be reported).
Hi,
thank you for the answer!
I am attaching the results but I cannot find the version number on top of QA_check file
I am using the TIAM model in Grantham Institute (version2.0), but i do not know if this helps...
Ehh... the file you posted was s01_baseline_2c_trialdac_constrdac_sumreg_ts.dd, i.e. it just contains the timeslices.
I was asking for the scenario where you have defined this UC constraint. Can you post the dd file for that scenario?
If you cannot find the version number on top of QA_check file, your TIMES version is too old, such that no support can be given for it anymore. So, you should upgrade... sorry.
(17-04-2018, 05:08 PM)Antti-L Wrote: Ehh... the file you posted was s01_baseline_2c_trialdac_constrdac_sumreg_ts.dd, i.e. it just contains the timeslices.
I was asking for the scenario where you have defined this UC constraint. Can you post the dd file for that scenario?
If you cannot find the version number on top of QA_check file, your TIMES version is too old, such that no support can be given for it anymore. So, you should upgrade... sorry.
Ok, sorry I got confused, this is the .dd file of that scenario (is not the only constraint implemented in that Excel sheet)
Ok, thank you for the file, it was useful to see the input data.
I still cannot see anything wrong with the constraint. I suspect that the constraint is indeed being met even in 2100, because you are incorporating dummy import flows in the UC constraints. The dummy import flows make it possible for the model to meet the constraint with basically any capacity development (but with a cost penalty, of course). I suspect that in the final period paying the cost penalty just "pays off".
Could you therefore check the results for any dummy imports: Do you see any flows of the IMPNRGZ process?
However, if you do not see any dummy import flows, then I am very puzzled, because I think the constraint looks otherwise OK. So, please let me know...
(17-04-2018, 06:28 PM)Antti-L Wrote: Ok, thank you for the file, it was useful to see the input data.
I still cannot see anything wrong with the constraint. I suspect that the constraint is indeed being met even in 2100, because you are incorporating dummy import flows in the UC constraints. The dummy import flows make it possible for the model to meet the constraint with basically any capacity development (but with a cost penalty, of course). I suspect that in the final period paying the cost penalty just "pays off".
Could you therefore check the results for any dummy imports: Do you see any flows of the IMPNRGZ process?
However, if you do not see any dummy import flows, then I am very puzzled, because I think the constraint looks otherwise OK. So, please let me know...
Actually, I cannot see any flows of IMPNRGZ process beyond 2012...
How can you say that I am incorporating dummy import flows? And how can I avoid it?
One can see the dummy imports being incorporated in the input file: You have UC_IRE coefficients for the dummy import process being added to these constraints.
But could you still show the VEDA-BE table you attached in your first post, but with the Scenario, Region, and Process dimensions shown as well, so that one can see the VAR_Cap in more detail? (Maybe in an Excel file if it gets too big).
(17-04-2018, 07:05 PM)Antti-L Wrote: Ok, then I am getting practically clueless.
One can see the dummy imports being incorporated in the input file: You have UC_IRE coefficients for the dummy import process being added to these constraints.
But could you still show the VEDA-BE table you attached in your first post, but with the Scenario, Region, and Process dimensions shown as well, so that one can see the VAR_Cap in more detail? (Maybe in an Excel file if it gets too big).
(17-04-2018, 07:05 PM)Antti-L Wrote: Ok, then I am getting practically clueless.
One can see the dummy imports being incorporated in the input file: You have UC_IRE coefficients for the dummy import process being added to these constraints.
But could you still show the VEDA-BE table you attached in your first post, but with the Scenario, Region, and Process dimensions shown as well, so that one can see the VAR_Cap in more detail? (Maybe in an Excel file if it gets too big).
here it is...
I have just noticed that applying that constraint on each region (UC_set:R_E) it works perfectly also in 2100, but when I try to apply to the sum of regions (R_S) it shows that strange behavior at the end of the century...
17-04-2018, 07:48 PM (This post was last modified: 17-04-2018, 07:48 PM by Antti-L.)
What you noticed (that with UC_set:R_E it works), is good to know, but I still cannot see where the problem could be.
I'd be happy to investigate it to the bottom, if you give me all the model input files (e.g. via some cloud server like dropbox). But without that option, I am sorry but I feel clueless now. But perhaps some other users might have some ideas?
(17-04-2018, 07:48 PM)Antti-L Wrote: What you noticed (that with UC_set:R_E it works), is good to know, but I still cannot see where the problem could be.
I'd be happy to investigate it to the bottom, if you give me all the model input files (e.g. via some cloud server like dropbox). But without that option, I am sorry but I feel clueless now. But perhaps some other users might have some ideas?
So, do I have to send you all the folder with the VEDA_model I am using, or just the SubRES and Scen file where I define and apply constraints on that technology?
In case, give me the email where to share this through dropbox
Ok, if you provide me with all the input files, this issue will certainly be solved!
Just pack all the *.DD files and the *.RUN file for the case that reproduces the issue, into a ZIP file. Make sure you include all the DD files. Then you can send me the Dropbox link for downloading it, by using the Private Message facility on this Forum. Is that ok for you?
(17-04-2018, 08:01 PM)Antti-L Wrote: Ok, if you provide me with all the input files, this issue will certainly be solved!
Just pack all the *.DD files and the *.RUN file for the case that reproduces the issue, into a ZIP file. Make sure you include all the DD files. Then you can send me the Dropbox link for downloading it, by using the Private Message facility on this Forum. Is that ok for you?
Thank you for providing the model input files for investigating the issue.
Indeed, you have discovered a bug in TIMES related to certain types of dynamic user constraints. This bug manifests itself only when all of the following conditions are true:
• The dynamic user constraint is formulated by summing over regions
• The dynamic user constraint is formulated with the dynamic type (t, t+1)
• The model is run by fixing the first periods to a previous solution (using FIXBOH)
As you can see, the bug appears only under rather specific conditions, which I guess explains that it has not been discovered before.
The bug will be fixed in the next version of TIMES. Meanwhile, there is an easy workaround, by formulating the constraint with the dynamic type (t, t–1) instead of (t, t+1). The screen capture below shows your constraint formulated with the dynamic type (t, t–1):
Many thanks for bringing the issue up here and being so helpful with investigating it and getting this old bug fixed!
