Veda2.0 Released!


User Constraint not Binding
#1
Hi,

I'm working on developing a  Regular Scenario with user constraints to limit CO2 emissions. This is modeled using the EPA US 9 Region TIMES model. I have attached a sheet that shows a sample of the constraints that I am trying to use. However when running the model, I get results that exceed the user constraints.

In 2050 the constraint limits the sum of ELCCO2, TRNCO2, and INDCO2 to 800, however in the results attached, TRNCO2 alone is at 1087. The constraint is obviously working in some capacity as ELCCO2 emissions were reduced drastically. I am wondering if there is a setting somewhere in VEDA that allows this constraint to be broken or if there is another issue I am missing altogether.


Thanks!


Attached Files Thumbnail(s)
       
Reply
#2
I suspect there is another issue you are missing.  Can you share the *.vd file for this case in order to investigate? 
I know it is big, but if you zip it, I guess you could then easily provide me the download link via e.g. Dropbox or Google Drive, couldn't you?
Reply
#3
(02-11-2022, 09:40 PM)Antti-L Wrote: I suspect there is another issue you are missing.  Can you share the *.vd file for this case in order to investigate? 
I know it is big, but if you zip it, I guess you could then easily provide me the download link via e.g. Dropbox or Google Drive, couldn't you?

Hi,

I have attached the .vd file for the scenario. One suspicion I have is there could be a discrepancy on where the commodity flows and emission flows are grouped, potentially with some of the negative BIOCO2 emissions. However I could not confirm this and wanted to make sure no other settings were incorrect.

https://www.dropbox.com/s/myfpnoi00frqmw...11.vd?dl=0

Thanks for your help
Reply
#4
Thanks.

But hmm... looks like the VD file was actually not from the same run. The results in the vd file clearly indicate that you have defined UC_RHSTS(UC_CO2sink,2050,UP)=1500, and not 800. Maybe you can confirm this confusing inconsistency?

Anyway, I can see that even that looser bound (1500) is indeed getting violated, because you have enabled dummy variables for UCs.  And the dummies are active for this constraint, even though the cost for the dummy flows appears to be as high as 99999. This cost is thus also shown as the marginal cost of the constraint.

So, because you have enabled dummies for the constraint, it is not firmly binding, but a "soft" constraint. Please have a look at the IMPNRGZ flows for the UC_CO2sink- commodity, and you should see those flows are equal to the constraint violations.  That is what I can see in the VD file you provided.

I hope that can help?
Reply
#5
Thanks for your response. You are correct I sent the .vd file for a different run with an altered constraint level. Thanks for pointing out the dummy variable setting, I had neglected to check those in the SysSettings file, and was only looking at the 'slack variables' in the VEDA run manager. However when disabling those settings it did not seem to make a difference and the IMPNRGZ dummy process is still accounting for the discrepancy in the constraint. 

I've attached a photo of the SysSettings and an updated .vd file. I would appreciate any other insights you have as to why the dummy variable is still active. 

https://www.dropbox.com/s/myfpnoi00frqmw...11.vd?dl=0

Thanks!


Attached Files Thumbnail(s)
   
Reply
#6
I think I may need to leave that to the VEDA experts (I am not such), but if you are using the new VEDA2, the option is under User options. Those ImpSettings in SysSettings have no effect under VEDA2.
Reply
#7
Are you referring to this screenshot, in VEDA2: Tools > User Options. There are no explanation for the check boxes, but I tried with and without them active and still had dummy variables active.


Attached Files Thumbnail(s)
   
Reply
#8
Antti is right - that table in SysSettings file is not read anymore.

You need to re-synchronize the model after deactivating the dummy imports under user options.
Reply
#9
Thank you for clearing that up for me!
Reply
#10
Actually, you could also deactivate dummy imports via a scenario file. Just bound them out with ACT_BND year=0 value=2 for process=IMP*Z.
Reply
#11
What would you suggest for deactivating them for all UCs in a specific scenario, or for a specific user constraint?
And can you also explain why there are two sets of dummy variables for UP/LO constraints? Wouldn't one be enough? I guess no dummy variables are at least not generated for free (N) constraints, am I correct?

By the way, do you think one might consider tying the UC dummies to a different process, say IMPUCNZ, instead of IMPNRGZ?
Reply
#12
The dummy commodities are accessible via transformation tables in the scenarios where UCs are defined. You can bound them out with cset_cn = *.

I didn't want to rely on the LimType of UCs for creating the dummies as UP/LO might change to FX in some scenarios. IMPUCNZ is a good idea; will put it on my list.
Reply
#13
> You can bound them out with cset_cn = *.

Hmm... I have thought that cset_cn = * would match any commodity, but I guess I am missing something: how will the asterisk match only those dummy commodities? And, is bounding out the only way, or is there a simple way of deactivating all UC dummies for a specific scenario?
Reply
#14
sorry... the silly editor removed angular brackets and I did not notice.

[user constraint name]*

There is not way to deactivate dummies for a specific scenario, but we can discuss this possibility if you think it can be useful.

I once exported a long list of UC names from browse to deactivate them. The dummy UC commodities should be seen in all scenarios, actually. The only exception is UCs that are defined only in parametric scenarios.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)