In EPS 3.4, we have certain control settings set via input data, plus an associated policy lever that reverses the default behavior. Examples include the settings for whether a carbon tax affects process emissions, whether a carbon tax affects non-CO2 emissions, and whether a carbon tax includes a border adjustment.
In 3.4, we subscripted the control setting for whether a carbon tax affects process emissions by industry category, and it is enabled by default for some industries and disabled by default for other industries. Therefore, a policy lever that reverses the behavior of the default setting makes no conceptual sense, because the default setting varies by subscript element. Instead, it is clearer and simpler to have the web app adjust the control setting directly (just as we do for the GRA settings). There is no need for a policy that reverses a control setting's behavior, as this simply adds excess complexity.
You can migrate the FoPITY schedules now used on the policy levers to the control settings themselves. (Or eliminate in cases where we don't need the ability to have a control setting value change in the middle of a run.)
Remember that any non-zero values in a control setting must be added to BAU.cin.
--
Additionally, the control settings are inconsistent in their nomenclature. For some of them, 0 means to exempt something and 1 means to include that thing, while for other settings, 0 means do not include that thing and 1 means to include it. Rename the control settings for consistency (so, any control settings that now "exempt" something would instead "include" that thing). Updating the 0 and 1 default settings so that this renaming operation does not change the model's behavior. Here are some examples of control settings with inconsistent naming:
BEPEfCT Boolean Exempt Process Emissions from Carbon TaxBENCEfCT Boolean Exempt Non CO2 Emissions from Carbon TaxBDCTBA Boolean Disable Carbon Tax Border AdjustmentBRCToEP Boolean Rebate Carbon Tax on Exported Products
In EPS 3.4, we have certain control settings set via input data, plus an associated policy lever that reverses the default behavior. Examples include the settings for whether a carbon tax affects process emissions, whether a carbon tax affects non-CO2 emissions, and whether a carbon tax includes a border adjustment.
In 3.4, we subscripted the control setting for whether a carbon tax affects process emissions by industry category, and it is enabled by default for some industries and disabled by default for other industries. Therefore, a policy lever that reverses the behavior of the default setting makes no conceptual sense, because the default setting varies by subscript element. Instead, it is clearer and simpler to have the web app adjust the control setting directly (just as we do for the GRA settings). There is no need for a policy that reverses a control setting's behavior, as this simply adds excess complexity.
You can migrate the FoPITY schedules now used on the policy levers to the control settings themselves. (Or eliminate in cases where we don't need the ability to have a control setting value change in the middle of a run.)
Remember that any non-zero values in a control setting must be added to BAU.cin.
--
Additionally, the control settings are inconsistent in their nomenclature. For some of them, 0 means to exempt something and 1 means to include that thing, while for other settings, 0 means do not include that thing and 1 means to include it. Rename the control settings for consistency (so, any control settings that now "exempt" something would instead "include" that thing). Updating the 0 and 1 default settings so that this renaming operation does not change the model's behavior. Here are some examples of control settings with inconsistent naming:
BEPEfCT Boolean Exempt Process Emissions from Carbon TaxBENCEfCT Boolean Exempt Non CO2 Emissions from Carbon TaxBDCTBA Boolean Disable Carbon Tax Border AdjustmentBRCToEP Boolean Rebate Carbon Tax on Exported Products