jrissman
commented
3 years ago Your proposed "fix" is already how the new wedge methodology works today. (A detailed description appears in issue #119.)
The issue you are encountering doesn't have anything to do with the category in WebAppData the carbon tax lever is under. That plays no role in the wedge diagram calculation procedure. All policies are now broken into pieces based on how they affect every sector, and each sector's total is protected from the influence of other sectors. The problem you are seeing is that within the same sector, we still allow policy interactions. This is a design decision that was consciously made and explained at the time we made the new feature. If we protect each policy with a sector from the influence of others, that is effectively the "enable" method in the Python script and disables all policy interactions, which causes its own set of severe problems (for instance, a carbon tax may do nothing, if it was relying on a flexibility policy to enable RE deployment). We liked the current methodology because it strikes a balance between still allowing policy interactions within each sector, where the policy interactions are most important, but eliminates many (perhaps 90+%) of the cases where two overlapping policies allow a third one to effectively take over the diagram.
The protected pieces of the graphed metric are defined in the list of variables for the wedge diagram on the Output Graphs tab of WebAppData. They must sum to the total metric being graphed - in this case, total CO2e emissions. The emissions from each sector are calculated in the model and do sum to total emissions. This allows sectors to be used as protection boundaries. There is no such thing as "emissions from the carbon tax" - policies affect emissions from each sector. Policies don't have their own associated emissions, because they are not elements of the physical energy system. So there is no existing boundary that circumscribes the effects of the carbon tax to which we could apply protection. And in any case, the issue you are seeing is not particular to the carbon tax. It would happen whenever you have two policies whose effects on a given sector heavily overlap, along with a third non-overlapping policy affecting that sector.
I am understandably hesitant to change a methodology we only recently overhauled after extensive discussion and testing, due to a behavior that was known and disclosed at the time. Nonetheless, I'm very open to ideas for improvements. So far, neither of us has devised a better approach.
The newer updates for the wedge diagram are great but still pose an issue when the carbon tax is used.
As an example, test out the 1.5 scenario for Virginia on the staging server. There is a $325 carbon tax in 2050 used to approximate estimated permit prices in RGGI in 2050 under the VCEA. You'll see that around 2040 the carbon free electricity standard starts to shrink and goes almost to zero by 2050, replaced by the transmission and storage policies. You'll also see that the electricity carbon tax has a value of 0. What's actually happening is that in the later years when the carbon tax is really high, the CES under disable becomes slack and the carbon tax takes over and vice versa.
The problem, I believe, is that right now they are handled under different sectors, so when the CES is turned off and emissions are still really low, our methodology is splitting the reductions among the remaining power sector policies, but is not including the power sector carbon tax as part of this.
I think the solution here is to allocate each piece of the carbon tax to the appropriate sector so it gets included within the sectoral calculations. If that's all that is required, it is a simple fix.
This is a pretty high priority fix given that it affects any policy package with a carbon price.