Anomaly forcing running with a weird trend

[jinmuluo]

What version of the code are you using?
ctsm5.1.dev163-219-gbedf4fb6b


Describe your problem or question:
Hi,

I am trying to use the ssp3-7.0 anomaly forcings to drive my model further, it was successfully done without any technical problems but the result looked a little weird. I'm not sure if that pattern is very common for all anomaly-forcing run, or if I did anything wrong in my case, anyway, any comments are very appreciated!

How I set up my case:
/glade/u/home/jinmuluo/LNDATM-IN/CaseSetUpAnomaly.sh

Result with a weird decreased trend at the beginning of the simulation:

 

[slevis]

My first guess: Your anomaly simulation used initial conditions from a land simulation driven with GSWP3 or a similar obs-based dataset. If so, then the shift that you see represents CAM's temperature bias. You would not see the shift if the initial conditions came from a land simulation driven with CAM datm files.

 

[slevis]

I'm rethinking my response because the whole idea behind using anomaly forcing is to avoid CAM's bias. But maybe you're applying the anomaly on top of a different obs-based dataset? One way or another, there's something not smooth in the transition that you're making from the "historical" to the "anomaly" simulation.

 

[jinmuluo]

I'm rethinking my response because the whole idea behind using anomaly forcing is to avoid CAM's bias. But maybe you're applying the anomaly on top of a different obs-based dataset? One way or another, there's something not smooth in the transition that you're making from the "historical" to the "anomaly" simulation.

Hi Sam,

The initial files I used were from a spin-up case by GSWP3 (1801~2014), I continued the run of future simulation (2014~2100) and only used the GSWP3 2005 to 2014 as the based forcing. I think it shouldn't had such a large unsmooth period like I had?

best,

 

[oleson]

Looking at your atm log file here:

/glade/derecho/scratch/jinmuluo/archive/AnomalyForcingCLMMESOCOSM/logs/atm.log.6429270.desched1.241025-164913.gz

It looks like the simulation starts off by reading the last 12 months of the anomaly forcing file, e.g.,

(shr_strdata_readstrm) reading file lb: /glade/p/cesmdata/cseg/inputdata/atm/datm7/anomaly_forcing/CMIP6-SSP3-7.0/af.allvars.CESM.SSP3-7.0.2015-2100_c20220628.nc 1020
(shr_strdata_readstrm) reading file ub: /glade/p/cesmdata/cseg/inputdata/atm/datm7/anomaly_forcing/CMIP6-SSP3-7.0/af.allvars.CESM.SSP3-7.0.2015-2100_c20220628.nc 1021

instead of the first 12 months.
I think the problem is that the anomaly forcing file begins in 2015 and you are starting the simulation in 2014, so it's going to the end of the file to get the first year of data. I think you should start the simulation in 2015 (Jan 1). Your historical should have run through the end of 2014.
Your cooling in the beginning of the simulation is probably due to the fact that anomaly forcing for 2100 is being applied to 2014, and then in 2015 it is using anomaly forcing in 2015 correctly

 

[jinmuluo]

Looking at your atm log file here:

/glade/derecho/scratch/jinmuluo/archive/AnomalyForcingCLMMESOCOSM/logs/atm.log.6429270.desched1.241025-164913.gz

It looks like the simulation starts off by reading the last 12 months of the anomaly forcing file, e.g.,

(shr_strdata_readstrm) reading file lb: /glade/p/cesmdata/cseg/inputdata/atm/datm7/anomaly_forcing/CMIP6-SSP3-7.0/af.allvars.CESM.SSP3-7.0.2015-2100_c20220628.nc 1020
(shr_strdata_readstrm) reading file ub: /glade/p/cesmdata/cseg/inputdata/atm/datm7/anomaly_forcing/CMIP6-SSP3-7.0/af.allvars.CESM.SSP3-7.0.2015-2100_c20220628.nc 1021

instead of the first 12 months.
I think the problem is that the anomaly forcing file begins in 2015 and you are starting the simulation in 2014, so it's going to the end of the file to get the first year of data. I think you should start the simulation in 2015 (Jan 1). Your historical should have run through the end of 2014.
Your cooling in the beginning of the simulation is probably due to the fact that anomaly forcing for 2100 is being applied to 2014, and then in 2015 it is using anomaly forcing in 2015 correctly

Hi Keith,

Thank you so much for your explanation, that's very useful!