jrissman
commented
3 years ago Mapping subscript elements to mean something else is not officially supported in the EPS. Remapping subscript elements is prone to causing bugs because it can be difficult to know all the places where an existing mapping involves structural assumptions or other input data in the model. For example, every industrial process emissions policy not only has its own marginal abatement cost schedule (PERAC) and which pollutants it targets, but also has its own costs and its own assignment of the spending on those costs to various ISIC codes. Everything has to change in concert, and it's easy for a person adapting the model to miss one place something needs to be updated or to misunderstand something. Remapping is risky and often unsafe software design.
If there is a feature you need, it is usually better to decide to support the feature explicitly, rather than rely on mapping.
I like your idea to add a N2O abatement policy for the Chemicals industry, the industry that encompasses nitric and adipic acid production. It would be a worthwhile addition to the model. (Agricultural N2O abatement is already part of the agriculture policies.)
I feel we should add this new process emissions policy in the same manner as other process emissions policies. This would be relatively straightforward to implement. It would be the cleanest way to program the needed feature and will not increase the model complexity or chances of creating bugs.
Remapping things in some subscripts is easier than others.
I made a doc page providing advice about how easy or hard it is to map the elements of certain subscripts, along with advice about limits that must be observed: https://us.energypolicy.solutions/docs/remapping.html
Those mappings are not officially supported, but the doc page does provide a sense of where it is easier and where it is hard. That doc page notes that power plant types have "good" remapping capability (the main constraint being that fuel-using plant types should be mapped onto fuel-using plant types, and non-fuel-using plant types should be mapped onto non-fuel-using plant types). I am unaware of any issues with "mapping power plant fuels/fuel prices onto the power plants themselves." If you have encountered a problem doing this, can you please open a different GitHub issue for it and describe the limitation you have encountered?
The variable Fraction of Process Emissions Reductions by Policy is calculated based on user settings, so it cannot be turned into an input variable. There would be no point, anyway. It is used as a check to ensure that reductions do not exceed total process emissions (of a given pollutant for a given industry).
In contrast, the variable Fraction of Process Emissions Reductions by Pollutant could involve pollutant assignments made in input data. It might be better programming style to do it that way. I would still discourage people from changing the assignments because of the difficulty in remapping any process emissions policy, but it would make such remapping more possible than it is today. I'm open to making these assignments via an input data variable.
So in summary, the work tasks I see for this GitHub issue are:
- Add a new industrial process emissions abatement policy targeting N2O in the chemicals industry.
- Use an input variable to do the policy-to-pollutant mappings used in
Fraction of Process Emissions Reductions by Pollutant
robbieorvis
Adipic and Nitric Acid producers emit a lot of N2O in the production process. In China, for instance, the EPA Non-CO2 report estimates there are more than 300 MMT CO2e of potential N2O emissions reductions in 2050 from the Adipic and Nitric Acid industry alone
Currently, these emissions reductions are grouped in with the F-gas policies in PERAC, because these industries are tiny in the US. However, given their role in other countries, we should consider adding in this policy lever or using the alternative below.
It might make sense to move the variables Fraction of Process Emissions Reductions by Pollutant and Fraction of Process Emissions Reductions by Policy to an input data variable, with separate CSVs for each industrial policy, and one dimension covering industries and another covering pollutants. This would provide a lot of flexibility in modifying how the process emissions policies work internally (and allow for regional flexibility). If we had this structure, I could just collapse two of the F-gas levers (for instance combining the recovery/recycling and inspection/maintenance/retrofit levers) in the input data and repurpose one to cover N2O mitigation in industry, which would avoid the need to modify the model structure (or even add a new policy in this instance).
(Also, generally speaking, I think there are multiple places where mappings are hard coded in Vensim but could be handled externally through an input data variable, such as mapping power plant fuels/fuel prices onto the power plants themselves. Generally, this would allow for a lot more flexibility when deploying the model to a new region in the future).