IEA-ETSAP Forum
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 :-)