UC to Cumulativly Constrain TOTCO2e

[AKanudia]

Try changing the Year to 2015 in the declaration below, and launch run from VTRUN.CMD

PARAMETER
UC_IRE ' '/
UC_MaxGHGBound.LHS.AUT.**2010**.IMPNRGZ.UC_MaxGHGBound-.ANNUAL.IMP -1
UC_MaxGHGBound.LHS.AUT.**2010**.IMPNRGZ.UC_MaxGHGBound_.ANNUAL.IMP 1

[Antti-L]

I can see there are both UC_R_EACH and UC_R_SUM in the DD file!

I tested it myself, and I can indeed see both generated by VEDA. This appears to be a bug in VEDA, and should be corrected.
This bug did not appear in earlier VEDA versions (a few years ago), and so it has been introduced in recent years.

However, I am not suggesting that it would be causing the infeasibility.

[AKanudia]

The problem is that UC_RHS has been used with UC_SETS: RE:

This can be fixed by either using UC_RHSR or UC_SETS: RS:

[MartinBaumann]

The problem is that UC_RHS has been used with UC_SETS: RE:

This can be fixed by either using UC_RHSR or UC_SETS: RS:

I changed the year to 2015, same result, same infeasibility.

Should I change to UC_RHSR?

[Antti-L]

Amit: Why would that matter?
VEDA should never generate UC_R_EACH or UC_R_SUM unless the user has requested so, by using UC_SETS: R_E: <regions> or UC_SETS: R_S: <regions>

[AKanudia]

What you propose can be done. But just to be sure, what would happen in the case that Martin created by using RE with UC_RHS? I mean, if there is such inconsistency and VEDA stopped creating the UC_R_SUM entry that the user probably intended, would the behavior change? I think we started doing this because it is easy to make a mistake in RS/RE... the RHS attribute is more reliable.

[Antti-L]

Yes, of course it can be done, because earlier VEDA versions did not have this bug.

TIMES auto-generates UC_R_SUM if UC_RHS has been used (and UC_R_SUM has not been defined by the user), and so it works much better that way. The same applies to UC_R_EACH, and so VEDA should never generate either, unless the user has requested so.

[MartinBaumann]

I changed to UC_RHSR, but I still get the infeasibility.

Do you have another suggestion for introducing a cumulative bound for one region for a defined period of time?

[Antti-L]

I tested Amit's approach with the DEMO model and it worked just fine, exactly as intended.

The reason for your infeasibility is thus most likely not related to using the UC_CUMCOM approach.

[MartinBaumann]

I have now a version that triggers no infeasibility, but it does not work.

The DD-file seems to be ok, it just has non impact on the solution.

Does any one have an idea what I can look for to identify the problem?

Any advice is very welcome, as I should have this feature running by next week.

Thanks a lot,
Martin

[AKanudia]

Let's do a web meeting tomorrow?

[MartinBaumann]

Yes, thank you.

About 10:00 CET? Tomorrow I would be available until 18:00 (CET)

[AKanudia]

Continue on email

[MartinBaumann]

The problem has been solved: I used "Other_Indexes: NET" , but I should have used "PRD", as there was no net amount of this commodity.

Thanks a lot for the help!

[Anna (AKR)]

Dear All,

Thank you for an instructive thread.

I am trying to implement a cumulative net-emission cap between year 2020 and 2045, and thereafter don't allow any net emissions. But I don't get it to work. 

Net-emission is defined as: "Domestic emissions" - "emissions removed by BECCS" - "emissions reduced abroad"

What am I doing wrong?

/Anna