Veda2.0 Released!


how to stop 2050 emissions go negative
#1
Hi, I'm having trouble stopping 2050 emissions going negative. 

I'm not sure why it happens as it would be more expensive to go negative than being zero. 

I have put an additional constraint to restrict it to be zero but it doesn't work. 

I'm wondering if I could get some help on this if possible? 

Thank you
Reply
#2
I am not a VEDA expert, but I think all VEDA input tables have been needing some "tag".  For user constraint definition tables, I think the tag has been ~UC_T. I see none in your table. The position of the tag has also been of importance, although less so in VEDA2.0. See an example in the picture below:

https://forum.kanors-emr.org/attachment.php?aid=1054
Reply
#3
Thank you for your reply. Sorry I've missed the tag. 

I've added it and did another run and still got the same negative emissions in 2050.

What might be the reason for that?
Reply
#4
I have no idea, but perhaps your constraint is a soft constraint (with dummy variables). Try turning off the dummies (Under user-options), re-import this (and only this) scenario, and re-run the model. See what happens.
Reply
#5
(09-08-2021, 06:42 PM)Antti-L Wrote: I have no idea, but perhaps your constraint is a soft constraint (with dummy variables).  Try turning off the dummies (Under user-options), re-import this (and only this) scenario, and re-run the model.  See what happens.

I've taken a look for the user options, and it seems there is no dummies selected. 

I've attached the screen shot for User option general and Import settings.
Reply
#6
Good! Then that can be excluded. So, I at least have still no idea about the explanation at this point.
You could consider posting the *.DD file for the scenario here (zipped or renamed to *.txt), and maybe the listing file *.lst, in case they might help identifying the cause for your problem.
Reply
#7
(09-08-2021, 07:15 PM)Antti-L Wrote: Good!  Then that can be excluded.  So, I at least have still no idea about the explanation at this point.
You could consider posting the *.DD file for the scenario here (zipped or renamed to *.txt), and maybe the listing file *.lst, in case they might help identifying the cause for your problem.

will do, thank you. For *.DD file, do you need only scenarioname.dd or all the other dd files such as uc_agr.dd? 
I'll upload *.lst as well
Reply
#8
I've zipped all the dd files anyway, and the lst file
Reply
#9
Well, if you posted all the DD files, you might as well post the RUN file as well.

I tried running your model without knowing your RUN file settings, and the model was infeasible.  So I wonder how you are getting a feasible solution in the first place.

Anyway, I see nothing wrong in the constraint: it looks being defined quite as it should in the model.
Reply
#10
Thank you. I've attached the run file. I've got feasible solution but not optimal solution. 

What I don't understand is that it would be more expensive to create negative emissions than zero emissions. Why would model do this and ignore the constraint of zero emission in 2050?
Reply
#11
Ok, thanks for the RUN file.

I was surprised by actually being able to get a feasible solution with your RUN file and your Cplex.opt settings.  I note that you have disabled crossover, which means that the solution may not be very reliable. Specifically, in your model instance, with the constraint fixing the 2050 value of VAR_COMNET(GHGTOT_MT) to zero, the commodity balance of GHGTOT_MT is reported by GAMS to have the following values in the solution (LO,Level,UP,Marginal):

'UK','2050','GHGTOT_MT','ANNUAL',0,-33.3923741920795,0,-260561593.702034

As you can see, this commodity balance is infeasible, because the level is -33.39 while the lower and upper bounds are both zero.  And the undiscounted marginal is also interesting:

"EQ_CombalM","GHGTOT_MT","-","2050","UK","-","ANNUAL","-",-205932230.277127

I am not sure about your units (millions GBP per Mt CO2 eq. would mean the marginal is 206 Million GBP per tonne!), but whatever they are, your CO2 price looks extremely high. But so are many other marginals in your model...

The constraint UC_NoCCS_2050_Zero itself does not have a marginal at all in the results, apparently because the bound is fixed and Cplex has been able to eliminate the constraint from the model (I am sure the marginal would be reported if you would use crossover and the model would be feasible).

In summary, it looks like your model is not behaving well, and the emissions are in some way forced to be negative (or have an extreme price), such that Cplex does not actually find a truly feasible solution, although it reports a feasible solution when using barrier without crossover. The reason for that being that the model is numerically so ill-conditioned.

(P.S. Your TIMES version is v4.3.3 from 2019. The current version is v4.5.6.)
Reply
#12
Thank you for the explanation, that's very helpful. Should I set barcrossalg 0 or 1? I've just tried both and both show infeasible.

We'll change it to v4.5.6 soon, and I'm wondering would changing to this version of TIMES make any difference to this result? that without CCS (this is what I'm trying that would the model produce a result for net zero emissions by 2050 without CCS) it cannot reach net zero.
Reply
#13
> We'll change it to v4.5.6 soon, and I'm wondering would changing to this version of TIMES make any difference to this result?
Hardly not; there are some small bug fixes and improvements probably not affecting you, but in general good to use up-to-date code.

> that without CCS (this is what I'm trying that would the model produce a result for net zero emissions by 2050 without CCS) it cannot reach net zero.

Not sure what you mean by this.  I think your negative emissions are not related to CCS, which you have disabled until 2060 anyway. As far as I can see, you have a lot of negative emissions from exporting coal, crude oil and oil products, then from forestation as well as agricultural soil options, from non-energy uses etc.  All together, the negative emissions are about 1000 Mt in 2050. The positive emissions are about 965 Mt, and the net is then −33 Mt as mentioned above (bad and actually infeasible result from the solver). I think the problems you have in your model (the infeasibility and probably the numerical problems in general) are the key things here.
Reply
#14
Thank you for your reply. I meant that stopping CCS technologies, as you mentioned, caused the model having difficulties producing optimal/sensible solution. 

Thank you for all your explanations to this issue, I have learned a lot here. :-) 

I'm wondering if you suggest setting barcrossalg 0 or 1 in general? I've just had a look on GAMS website and it seems 0 means automatic and 1 means basic solution, what would be the differences? 

Also given that we may migrate to Veda2.0 later, do you think it's okay to keep using TIMES version v4.3.3 for a little longer? what's the main differences between this version and v4.5.6? 
Reply
#15
> what's the main differences between this version and v4.5.6?

I attach a summary of the changes, so you can see what you will be missing.
Among the improvements, the most important new feature is probably the extension for Ancillary Balancing Services (ABS): 
See the ABS Documentation

I have myself been mostly using   barcrossalg 0
I know that some users want to save solution time and therefore disable crossover. While that may work reasonably well if the model is numerically stable, it usually produces solutions that are somewhat non-optimal, and the deviation from the true optimality tends to get bigger when there is some numerical instability. And, as shown by your scenario, at worst it may even produce an infeasible solution even though falsely reported feasible.


Attached Files
.docx   Changes-2019-2021-Sum.docx (Size: 18.07 KB / Downloads: 5)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)