The current implementation of scaling to a given GMST timeseries causes problems if the global mean temperature anomaly predicted by METEOR is very small, because it is the denominator the scaling (line 1052-1056 in meteor_interface.py commit 706a94a):
temp_scaling = np.where(
annual_temp_prediction_gm_anomaly.values != 0,
temperature_input_anomaly.values / annual_temp_prediction_gm_anomaly.values,
1.0,
)
This can cause really large anomalies in the gridded fields after scaling, if the predicted anomaly is small and/or there is a slight mis-match between the magnitude of the GMST timeseries and the meteor prediction at a given time, and could be an issue for scenarios where the temperature anomaly crosses zero relative to the baseline at the beginning of the simulation ie. for overshoot.
Probably we need a better scaling function which can appropriately deal with anomalies near zero.
The current implementation of scaling to a given GMST timeseries causes problems if the global mean temperature anomaly predicted by METEOR is very small, because it is the denominator the scaling (line 1052-1056 in meteor_interface.py commit 706a94a):
temp_scaling = np.where(
annual_temp_prediction_gm_anomaly.values != 0,
temperature_input_anomaly.values / annual_temp_prediction_gm_anomaly.values,
1.0,
)
This can cause really large anomalies in the gridded fields after scaling, if the predicted anomaly is small and/or there is a slight mis-match between the magnitude of the GMST timeseries and the meteor prediction at a given time, and could be an issue for scenarios where the temperature anomaly crosses zero relative to the baseline at the beginning of the simulation ie. for overshoot.
Probably we need a better scaling function which can appropriately deal with anomalies near zero.