conflict analysis...

[Lukas]

Hello,
I have a conflict between a set of equations and variables. However, I am unable to find the EQE_COMBAL equation. The CH4_1A2f emission commodity is aggregated via the COM_AGG attribute into the GHG commodity.
Only the COM_AGG and FLO_EMIS attributes are dedicated to the CH4_1A2f commodity; see the attachment.

Do you have any idea what could be wrong, or where I could find the incorrectly specified equation?


Number of equations in conflict: 1
fixed: EQE_COMBAL('CZ',2019,'CH4_1A2f',ANNUAL) = 0

Number of variables in conflict: 3
fixed: VAR_ACT('CZ',2019,2019,'ICR0',ANNUAL) = 178.089
fixed: VAR_ACT('CZ',2019,2019,'IGL0',ANNUAL) = 163.627
lower: VAR_COMNET('CZ',2019,'CH4_1A2f',ANNUAL) > 0

Thank you,
Lukas

[Antti-L]

There is no need to "find" the EQE_COMBAL equation.  It is there simply by definition, because you have VAR_COMNET.  You always have EQE_COMBAL when you have VAR_COMNET. And you have VAR_COMNET because you have COM_AGG.  So that's simple and clear. But as to your infeasibility, I have no idea; I think there is not enough information. What did you change in your model that started having that infeasibility?

[Lukas]

There is no need to "find" the EQE_COMBAL equation.  It is there simply by definition, because you have VAR_COMNET.  You always have EQE_COMBAL when you have VAR_COMNET. And you have VAR_COMNET because you have COM_AGG.  So that's simple and clear. But as to your infeasibility, I have no idea; I think there is not enough information. What did you change in your model that started having that infeasibility?

Dear Antti-L,

thank you. But if I read the documentatino correctly:
"EQ_COMBAL reads schematically as follows: Procurement – Disposition {>= or = } COEF_FBRHS where COEF_FBRHS is 0 for all balance equations, except for demand balances where it is equal to a positive parameter. In addition, COEF_FBRHS is equal to a variable when the equation is used to define the variables VAR_COMPRD or VAR_COMNET."

If I am not wrong I should have EQ_COMBAL due to COM_AGG attribute, I have EQE_COMBAL=0.  
According to documentation, EQE_COMBAL si associated with the demand function of commodity c, as a strict equality. This constraint is automatically generated for the component demands of all CES demand functions, i.e. demands modeled with substitution elasticities.

But the CH4_1A2f commodity is defined as END, not DMD type.
This confuses me.

[dtsintsk]

There is no need to "find" the EQE_COMBAL equation.  It is there simply by definition, because you have VAR_COMNET.  You always have EQE_COMBAL when you have VAR_COMNET. And you have VAR_COMNET because you have COM_AGG.  So that's simple and clear. But as to your infeasibility, I have no idea; I think there is not enough information. What did you change in your model that started having that infeasibility?

Hi, I don't know if this helps but maybe in the definition of the table we are missing something?

[Antti-L]

>  If I am not wrong I should have EQ_COMBAL due to COM_AGG attribute, I have EQE_COMBAL=0.

The documentation says quite clearly:
"In addition, COEF_FBRHS is equal to a variable when the equation is used to define the variables VAR_COMPRD or VAR_COMNET."

The equation is therefore EQE_COMBAL (i.e. an equality constraint) just because of that: 
  Procurement – Disposition = COEF_FBRHS.

But you are right, you should have EQ(l)_COMBAL, and indeed you do have EQ(l)_COMBAL.  The (l) is in this case E (meaning equality), because the equation is used to define the variable VAR_COMNET.   
EQE_COMBAL is not causing your infeasibility, it is a standard equation usually generated for all emissions commodities. You just have a modeling error somewhere in your model related to CH4_1A2f.

[Antti-L]

If the infeasibility problem persists and you cannot find the modeling error, I can offer to help with it, if you provide the full model input files (*.DD, *.RUN) and the listing file *.LST.  I got curious about it myself, what the error might be. 

[dtsintsk]

If the infeasibility problem persists and you cannot find the modeling error, I can offer to help with it, if you provide the full model input files (*.DD, *.RUN) and the listing file *.LST.  I got curious about it myself, what the error might be. 

Hello dear Antti, I found for the processes IGL0 and ICR0 one of the INPUT was a negative number because of some manipulations probably done earlier, which changed the cell value and we did not notice it. I absolutely do not understand why this was causing the problem, because the model was still working fine before we switched on the emissions aggregating table. Now, after fixing this error (negative input), the model already works. So if you could find any explanation why negative INPUT was affecting the aggregating table, that would be helpful or if this is not sufficient clue for you, I would be happy to go through the model with you to find out together.

Thank you

[Antti-L]

Thanks for the update.
I think it can explain it well, although I am not able to pinpoint the exact mechanism without seeing the model.  Anyway, I am glad that you found the error.