Posts: 26
Threads: 7
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2018
(18-04-2018, 02:04 PM)Antti-L Wrote: 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! 
Dear Antti,
thank you very much for your help. I am happy that my problem was useful on a wide scale ;-)
Giulia
Posts: 26
Threads: 7
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2018
(18-04-2018, 02:04 PM)Antti-L Wrote: 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!
Dear Antti,
sorry for bothering you again but I tried what you suggested (t,t-1)and it is not working at all: indeed the bound is not met in the scenario (marginal value not present in VedaBE). Did you try to see if it was actually working?
This are my results:
Giulia
Posts: 1,989
Threads: 26
Likes Received: 68 in 59 posts
Likes Given: 20
Joined: Jun 2010
Sure, I tried it with your model files (replacing your original constraint data with the (t, t-1) variant), and it worked perfectly, for all periods from 2030 to 2100.
Posts: 26
Threads: 7
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2018
Posts: 1,989
Threads: 26
Likes Received: 68 in 59 posts
Likes Given: 20
Joined: Jun 2010
You managed to what?
Does the (t, t-1) approach work now for you? What was the problem?
Thanks.
Posts: 26
Threads: 7
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2018
I managed to have the right results! Don't know what was going wrong exactly, probably I wrote the wrong column header!
