Setting com_lim to 'N' produces an unexpected result - Printable Version +- IEA-ETSAP Forum ( http://iea-etsap.org/forum)+-- Forum: Model Generators ( http://iea-etsap.org/forum/forumdisplay.php?fid=2)+--- Forum: TIMES ( http://iea-etsap.org/forum/forumdisplay.php?fid=8)+--- Thread: Setting com_lim to 'N' produces an unexpected result ( /showthread.php?tid=113) |

Setting com_lim to 'N' produces an unexpected result - pauldodds - 02-10-2017
I have an emissions counter for LULUCF emissions (GHGmLULUCF). It is negative in 2010. The normal COMBAL equation, for com_lim = 'UP', is: _EQE_COMBAL(UK.2010.GHGmLULUCF.ANNUAL)#8172: - VAR_COMNET(UK.2010.GHGmLULUCF.ANNUAL)#3205 - 439.288824543984 VAR_FLO(UK.2010.2010.ALU00.ALAND.ANNUAL)#4728 = 0 I tried to disable the COMBAL equation by setting com_lim to 'N', but this then changed the COMBAL equation to: _EQE_COMBAL(UK.2010.GHGmLULUCF.ANNUAL)#8172: - VAR_COMNET(UK.2010.GHGmLULUCF.ANNUAL)#3205 + VAR_COMPRD(UK.2010.GHGmLULUCF.ANNUAL)#3493 = 0 This latter equation caused an infeasibility. Yet I was not expecting an equation to be created when using 'N'. Can you explain this to me? (Further notes: the first COMBAL equation does not produce an infeasibility as long as COM_BNDNET is set to a large negative value, so the model is working. But I'm interested to know what the 'N' option is doing. Both equations are from the CPLEX writelp option.) RE: Setting com_lim to 'N' produces an unexpected result - Antti-L - 02-10-2017
There are multiple unclear issues in your question: 1. You say that the first equation was a "normal" equation generated with COM_LIM=UP. However, COM_LIM=UP is used for unlimited renewables, for which no commodity balance is to be generated. The normal commodity balance equation is generated with COM_LIM=LO, and it is of type >= (EQG_COMBAL) Your equation is of equality type (EQE_COMBAL), and so the equation is definitively neither normal, nor one that you should get when using COM_LIM=UP. 2. You say that the second equation is generated by setting com_lim to 'N'. When COM_LIM=N, no commodity balances will be generated, unless you explicitly request that it should nonetheless be generated, by defining a bound or a cost on the corresponding VAR_COMNET variable, or referring to the VAR_COMNET in a user constraint. In that case, the equation type will be EQE_COMBAL, and the VAR_COMNET variable is activated. I believe you thus must have requested the generation of such a commodity balance, by referring to the VAR_COMNET variable in one way or another. If you can reproduce the issue with the DEMO model, I would be happy to look at it more closely. RE: Setting com_lim to 'N' produces an unexpected result - pauldodds - 02-10-2017
For (1), my mistake - the commodity balance was generated with the default COM_LIM=LO, as you say it should be. It was set to the default ENV COM_LIM. For (2), a COM_BNDNET was defined for the commodity. However, removing this and leaving only COM_AGG and FLO_EMIS defined for the commodity does not change the behaviour. It looks like an EQE_COMPRD equation is created to produce VAR_COMPRD, which is equal to VAR_COMNET in the COMBAL equation. However, since COMPRD must be greater than zero by default, and the emissions are negative, this causes an infeasibility. So I think it might work if the emissions are positive, but not if they are negative. RE: Setting com_lim to 'N' produces an unexpected result - Antti-L - 02-10-2017
I believe you are also using COM_AGG for the this LULUCF emission. COM_AGG aggregates VAR_COMNET into the target commodity, if COM_LIM=LO. But if COM_LIM=FX or COM_LIM=N, it aggregates VAR_COMPRD into the target commodity (this seems a natural convention to me, because if the user does not want to have the VAR_COMNET variables, what else than VAR_COMPRD can we then aggregate)? That would explain the VAR_COMPRD in your commodity balance, when COM_LIM=N. Obviously, if you are indeed using COM_AGG, you must have either VAR_COMNET or VAR_COMPRD active. And surely you would want also the negative emissions aggregated into the target, no? Therefore, the solution would be to set the lower bound of either variable to -INF. RE: Setting com_lim to 'N' produces an unexpected result - pauldodds - 02-10-2017
Thanks for the explanation, Antti. We did indeed solve the issue by setting COM_BNDNET to a large negative number. Just as an aside (and admittedly off-forum but related to your answer), is it possible to set -INF in VEDA? It was ignored when I tried it for COM_BNDNET for this commodity. RE: Setting com_lim to 'N' produces an unexpected result - Antti-L - 02-10-2017
You can set the lower bound of VAR_COMNET/COMPRD to -INF by setting as follows (NET case): COM_BNDNET(r,t,c,'ANNUAL','N') = -1 (for period t), or COM_BNDNET(r,'0',c,'ANNUAL','N') = -1 (for all periods). Hope that helps. RE: Setting com_lim to 'N' produces an unexpected result - pauldodds - 03-10-2017
Great, thanks Antti, it certainly does. I have it working. I'm learning a few new tricks today :-) |