I have three processes which all consume a commodity called COM1. Theses processes have multiple inputs, but COM1 is their main input (meaning their COM1 input is normalized to 1 and the other inputs scale with the COM1 input).
I would like to constrain my model so that:
1) All COM1 is consummed at specific key time periods (e.g. 2020, 2030, 2050, 2100)
2) COM1 is consumed among the processes (PROC1, PROC2 and PROC3) according to predefined shares.
I tried to implement this using the attached UC but it does not work as expected. Do you have any insights or suggestions on how to properly formulate this?
Yesterday, 05:51 PM (This post was last modified: Yesterday, 06:23 PM by Antti-L.)
I found your statement “but it does not work as expected” quite broad, raising a lot of open questions, such as:
● What exactly do you mean by saying that the constraint does not work as expected?
○ What is it exactly that does not correspond to your expectations?
○ Is the equation not formulated as you expected? If so, in what way not?
○ Is the formulation as expected, but the constraint nonetheless does not appear to function as you expect? If so, in what way does it not function as you expect?
Anyway, I tested similar constraints myself, and I am not able to confirm your findings. All three constraints worked fully as documented and as expected. Therefore, I would like to pose some further questions:
• Which version of TIMES you are using? Providing the listing file would show us that.
• Do you still have domain violations in your model? Having domain violations may cause many problems in the model. Providing the listing file would show us that status.
• Do you have DATAGDX enabled? Providing the listing file would show us that.
• Do you have dummy imports enabled, and if you have, for which types, and at which costs?
• I cannot see all the details of the UC constraints from the picture. Could you provide the DD file for this scenario, or at least show what you have in the last three columns?
• It seems that you are not defining any IE option for UC_2 and UC_3. Could you explain why they are modelled differently in that respect? It looks like you are expecting that UC_2 and UC_3 should not be defined for any other years than 2020, but as I said, I cannot really see what you have in those second- and third-last columns.
As you can see, providing the listing file would give a lot of useful information, which would reduce the time spent in narrowing down possible explanations to a modelling issue. Classifying the listing file as “confidential” does not really make sense to me, because the standard TIMES listing file does not show any model data (unless you still do have domain violations), nor any model equations. But it does contain many useful pieces of information for troubleshooting.
Finally, I would like to point out that modeling such a set of FX equations like yours represents bad modelling practice. You should avoid defining sets of constraints in an over-specified manner (i.e. including some redundant constraint(s)), because they can be expected to cause numerical problems and/or infeasibilities.