You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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_scaling
for ozone inspecies_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 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.forcing
is prescribed on input, but after the call tof.run()
, the forcing is scaled, so thatf.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.The text was updated successfully, but these errors were encountered: