Veda2.0 Released!


Issue with EQ_Combal and VAR_Comnet
#1
Hi guys,
I've recently introduced process-based industrial emissions into my model (INDCO2P). I think I've declared this in the right places, and the model appears to be working.

However, I've recently just found an issue that I'm struggling to fix. In INDIA, INDCO2P is being produced, but the net commodity (VAR_Comnet) of INDCO2P is 0 for most of the model period. Instead, the model assigns INDCO2P in India a commodity/slack level (EQ_Combal), and the production of INDCO2P goes into this attribute.

This differs to all other regions, in which production and consumption of INDCO2P by sources and sinks alters the VAR_Comnet of INDCO2P. I'm attaching a brief table showing some BE results which compare IND to AFR (as an example region) to display the issue.

The problem is that then, when I aggregate all emissions to calculate TOTCO2, INDCO2P from India is not being accounted for, because it's VAR_Comnet is 0, whereas it has a positive EQ_Combal.

Could anyone suggest any reasons why this might be occuring, and possible remedies to fix it? Please also let me know if you need any more information on the error.

All the best,
Neil


Attached Files
.xlsx   INDCO2P_Error_Example.xlsx (Size: 16.38 KB / Downloads: 4)
Reply
#2
The commodity balances have two forms: inequality and equality balance (ignoring any exogenous demand here for simplicity).

The inequality formulation is:   production(r,t,c,s) ≥ consumption(r,t,c,s)
The equality formulation is:    production(r,t,c,s) = VAR_COMNET(r,t,c,s) + consumption(r,t,c,s)

As you can see, in the equality formulation the EQ_COMBAL value should be normally zero, because there are no constant terms involved (except when there are demand projections or capacity-related flows on some existing capacity involved, which I think we can ignore here).  The EQ_COMBAL value should thus normally be non-zero only if you have the inequality balance formulation for INDCO2P.

However, if you have indeed defined COM_AGG in order to aggregate INDCO2P to TOTCO2, you should automatically have the equality formulation for the commodity balance. Therefore, could you show the COM_AGG definitions for INDCO2P from the VEDA Browser, to verify that?
Reply
#3
Hi Antti,
That's really helpful, thanks. I had a look at my COM_AGG in VEDA, and while I'd defined INDCO2P to be aggregated into TOTCO2 in the model, for some reason it hadn't taken this in board for the India region (though had for all other regions). So there was no COM_AGG defined for INDCO2P to TOTCO2 in the IND region - hence the error.


I have fixed this (see the 1st worksheet on my latest upload). COM_AGG is now defined in India.

When I run now, then INDCO2P has a VAR_Comnet in India, and is correctly being aggregated into TOTCO2, which is nice. Thanks Antti! However, as you see on the 2nd worksheet on my latest upload, it still has an EQ_Combal, unlike any other regions (and the values in EQ_Combal are quite confusing - I'm not sure where they are coming from).

Should I be worried that IND is still producing an EQ_Combal for INDCO2P? Or is this not a serious problem?

All the best,
Neil


Attached Files
.xlsx   INDCO2P_Error_Example_2.xlsx (Size: 18.98 KB / Downloads: 7)
Reply
#4
I assume you are using FIXBOH (fixing initial periods to previous solution), and the EQ_COMBAL is a leftover from the solution of that previous run. It will go away as soon as you re-run the previous run.

So, I would say nothing to worry about; the EQ_COMBAL values you see are a "cosmetic" leftover issue. But yes, I guess it would be good to fix this also in TIMES (by clearing the previous solution for EQ_COMBAL, like all the variable levels are cleared), so thank you for pointing this out.
Reply
#5
(16-10-2019, 02:57 PM)Antti-L Wrote: I assume you are using FIXBOH (fixing initial periods to previous solution), and the EQ_COMBAL is a leftover from the solution of that previous run. It will go away as soon as you re-run the previous run.

So, I would say nothing to worry about; the EQ_COMBAL values you see are a "cosmetic" leftover issue. But yes, I guess it would be good to fix this also in TIMES (by clearing the previous solution for EQ_COMBAL, like all the variable levels are cleared), so thank you for pointing this out.

Yep you were right Antti - re-running the previous scenarios gets rid of EQ_COMBAL for INDCO2P.

Thanks again for all your help - very much appreciated.

Best,
Neil
Reply
#6
Hi Antti,
Just a quick question. 

I understand that I can use the COM_LIM attribute to change the sense of the commodity balance (if we go from COM_LIM = LO to COM_LIM = FX we go from an inequality balance of >= to an equality balance). Is that correct?

And if so, if I want to constrain an energy commodity to have a VAR_COMNET of 0, do I need to both
a) Change the COM_LIM to be FX (thus activating the equality balance)
b) Create a constraint using UC_COMNET to constrain VAR_COMNET to zero?

Or would just b), creating a constraint on VAR_COMNET, automatically also initialise VAR_COMNET and hence switch the commodity balance to an equality balance?


Thanks in advance,
Neil
Reply
#7
a) Change the COM_LIM to be FX (thus activating the equality balance)
This would usually be sufficient, but only if you don't refer to VAR_COMNET in your model (e.g. by using COM_CSTNET or UC_COMNET). So, if you DO refer to VAR_COMNET in your model, such would trigger creating the VAR_COMNET variable anyway, and in that case COM_LIM(FX) would not be sufficient for bounding it to zero.

b) Create a constraint using UC_COMNET to constrain VAR_COMNET to zero
That would work, but it is not a very efficient way of doing it.

c) Define COM_BNDNET(r,'0',c,'ANNUAL','UP')=2;  ('UP' or 'FX')
I'd say this would be an easy, reliable and efficient way to constrain an energy commodity c to have a VAR_COMNET of 0.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)