Download latest Version of VEDA-FE 4.5.812.

Veda Application Installation guide


UC to Cumulativly Constrain TOTCO2e
#16
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
Reply
#17
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.
Reply
#18
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:
Reply
#19
(20-02-2018, 04:03 PM)AKanudia Wrote: 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?
Reply
#20
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>
Reply
#21
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.
Reply
#22
Yes, of course it can be done, because earlier VEDA versions did not have this bug. Rolleyes

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.
Reply
#23
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?
Reply
#24
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.
Reply
#25
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


Attached Files
.txt   emi_cumbndtest.dd.txt (Size: 1.11 KB / Downloads: 2)
.xlsx   Scen_EMI_CumBndTest.xlsx (Size: 457.67 KB / Downloads: 5)
Reply
#26
Let's do a web meeting tomorrow?
Reply
#27
Yes, thank you.

About 10:00 CET? Tomorrow I would be available until 18:00 (CET)
Reply
#28
Continue on email
Reply
#29
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!
Reply
#30
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


Attached Files Thumbnail(s)
   
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)