This is unintuitive and not user friendly, and tripped me up at first. But the alternative is less desirable.
Let's say I prescribe an ozone forcing time series and override the internally calculated ozone forcing. That's not an unreasonable thing to do as you may not like the way FaIR calculates ozone, or want to use the actual AR6 time series, or the output from a particular Earth System model. So I prescribe my time series in f.forcing. Then, as usual, I want to sample from the forcing uncertainty distribution of +/- 50% around the best estimate ozone forcing as in IPCC AR6. Usually, this would involve setting forcing_scaling for ozone in species_configs to a number between 0.5 and 1.5. If the species was emissions or concentration driven, it would calculate the unscaled forcing, then scale it, and put the result in f.forcing. However, for forcing-driven species, currently the FaIR code ignores this scaling.
The alternative is that FaIR picks up the scaling and self-modifies it. f.forcing is prescribed on input, but after the call to f.run(), the forcing is scaled, so that f.forcing is overwritten in the output. If I wanted to compare the forcing of the scenario before and after running the model, I'd get different answers. I think this is a less good option.
Therefore, to introduce uncertainty into forcing-driven time series, the scaling has to happen on input, i.e. if you want to run different configs with different scale factors (the usual thing for probabilistic ensembles), you have to scale it yourself outside the FaIR code. All operational examples with solar and volcanic forcing already do this. This is ugly and puts more burden on the user, but is the lesser of two evils. However, the problem is that there is no user communication that the scaling is silently ignored, so FaIR should check that for any forcing-prescribed species, if the forcing_scale value is not 1, a warning is raised.
This is unintuitive and not user friendly, and tripped me up at first. But the alternative is less desirable.
Let's say I prescribe an ozone forcing time series and override the internally calculated ozone forcing. That's not an unreasonable thing to do as you may not like the way FaIR calculates ozone, or want to use the actual AR6 time series, or the output from a particular Earth System model. So I prescribe my time series in
f.forcing. Then, as usual, I want to sample from the forcing uncertainty distribution of +/- 50% around the best estimate ozone forcing as in IPCC AR6. Usually, this would involve settingforcing_scalingfor ozone inspecies_configsto a number between 0.5 and 1.5. If the species was emissions or concentration driven, it would calculate the unscaled forcing, then scale it, and put the result inf.forcing. However, for forcing-driven species, currently the FaIR code ignores this scaling.The alternative is that FaIR picks up the scaling and self-modifies it.
f.forcingis prescribed on input, but after the call tof.run(), the forcing is scaled, so thatf.forcingis overwritten in the output. If I wanted to compare the forcing of the scenario before and after running the model, I'd get different answers. I think this is a less good option.Therefore, to introduce uncertainty into forcing-driven time series, the scaling has to happen on input, i.e. if you want to run different
configswith different scale factors (the usual thing for probabilistic ensembles), you have to scale it yourself outside the FaIR code. All operational examples with solar and volcanic forcing already do this. This is ugly and puts more burden on the user, but is the lesser of two evils. However, the problem is that there is no user communication that the scaling is silently ignored, so FaIR should check that for any forcing-prescribed species, if the forcing_scale value is not 1, a warning is raised.