Download the latest version of VEDA-FE (45828) and VEDA-BE (492014)

Veda Application Installation guide

Cost reduction scenario
We are attempting to apply a percent reduction in cost to wind turbines in our model.  We set up the constraint with the reduction value to be applied for each time period.  But when we browse VEDA-FE, the calculations have been done incorrectly, including the fact that the price continues to decline when it should have leveled off.  I am attaching both the uploaded scenario and the results in the browser showing the base price and the incorrectly calculated new price.  Help with solving this would be appreciated.

Attached Files Thumbnail(s)
Looking at the documentation (Part IV), I found the following explanation for TFM_UPD:
Transformation Update Tables (~TFM_UPD) in scenario and transformation files operate on existing data defined in previous scenarios. Updates are applied to seed values that are picked up from the closest alphabetically preceding scenario.

This makes me suspect that maybe you have some other, alphabetically preceding scenarios already defining cost reductions for wind power? You only showed the values from BASE and CostReduction60 in your screenshot, but are there perhaps NCAP_COST values defined also in some other scenario alphabetically preceding CostReduction60, such as CostReduction40to50?

However, I have myself had the feeling that it could also be controlled. And, looking at the Notice Board on this Forum, I can indeed see that “SourceScen“ has been announced as a "new column for UPD table to filter the scenario to be used to get seed values". Maybe you could try using that, with BASE as the SourceScen?
I am working on this project with Carol and I think I can add some more information to help with troubleshooting. 

I have checked all other scenarios and none affect ncap_cost as far as I can tell, unless there are some hidden chains of affect that I have not been able to track. 

The way that we have constructed the analysis is to create multiple "CostReduction..." scenarios that all affect the cost of the shown group of processes to different degrees, but no more than one is ever selected for any given model run, so they should never compound or overwrite each other (if my understanding that ONLY the order of selected/checked scenarios is what matters). 

I will add the SourceScen column to the TFM_UPD table and see if that corrects our issue.

Thanks for you help, and any additional insight would be great.

Thanks Antti.

Morgan, I am sure it will work.
After a couple of tests, seems like that works! Thanks for highlighting the SourceScen column, I think that fixed our issue and not sure if we would have found it quickly otherwise.

At the core of our issue, I believe, was a misunderstanding to how scenarios affect each other. It had been my understanding that I could have multiple scenarios pulled into Veda FE in the Scenarios section  and in the VEDA Model SuppXLS folder, but they were only "active" if I selected them in the Case Manager when I ran my models. 

Taking the example of the CostReduction60 scenario that Carol showed:
That was one of many cost curves that we developed in TFM_UPD tables to update the cost curves for a set of processes in our database. The research we're doing is a sensitivity analysis, so it seemed the most efficient to import all of the tables to the SuppXLS folder and then select only the one we wanted to apply for each model run. This was especially important because we wanted to utilize the batch run feature which would require that we set up all of the iterations of our model runs ahead of time thus requiring all of the scenarios to be present. 

Going forward, should we use the SourceScen column for all scenarios that might be impacted by similarly named scenarios? It seems like this would be best practice if our scenarios have similar naming conventions. Or would you recommend that we just name our scenarios more differently?

Thanks again for all of your help, its been useful!

Forum Jump:

Users browsing this thread: 1 Guest(s)