Spin-up shut-down problem and low resolution of TOTECOSYSC,NEE, GPP results

[syang]

Dear all,

Firstly, I successfully run the case I2000CLm50BgcCruGs with the default GSWP3v1 forcing data and the surface data which was created by CLM tools with default grids and maps. However, the output files have very low resolution for some variables (e.g., TOTECOSYSC, NEE, GPP, see attached Fig1 below). It looks like some big pixels overlap the smaller pixels in the region. Then, I used my own forcing data (0.05x0.05 degree) and I substitute the variables (PCT_PFT, PCT_CROP, PCT_NAT_PFT...) with my own higher resolution data in surface map. However, the big pixels problem is still there (see Fig2). I totally have no idea what caused these "big pixels".

Secondly, since the above case did not run the spin-up, I tried the spin-up for the case. I used the same compset (I2000CLm50BgcCruGs) and set CLM_BLDNML_OPTS with "-bgc bgc -crop" and CLM_ACCELERATED_SPINUP="on", simulating 100 years from 2000. However, when the model run to the fifth year, it shuts down with the error: "capping procedure failed (negative mass remaining)" (see log file).

To sum up, I have two questions here. 1)why the results of TOTECOSYSC, NEE, GPP have such big pixels and how to fix it?. 2)why the spin-up shuts down and how to fix it? I am stuck to this step and I really appreciate it if anyone can help me with this. THANKS!!!

 

[sacks]

Regarding (1): I'm not sure, but my first guess is that you're seeing artifacts from the interpolation of out-of-the-box initial conditions at coarser resolution. By default, CLM will start with spunup initial conditions, typically at about 1 degree resolution. These initial conditions then get interpolated to the model resolution using a nearest-neighbor interpolation. Therefore, it is not surprising to see blocky state variables in a very high resolution run until the model has run long enough to re-spin-up under the new conditions. (I'm not sure if this can explain the blockiness in fluxes like NPP, but it seems a likely explanation for TOTECOSYSC.) If you do "./xmlquery CLM_FORCE_COLDSTART=on", my guess is that you won't see this blockiness, as long as you are also using high-resolution atmospheric forcing data.

Regarding (2): It looks like there are roundoff-level issues in the snow capping. To work around this issue: In the CTSM source code you should see a file src/biogeophys/SnowHydrologyMod.F90. Around line 3282, you should see a line, real(r8), parameter :: min_snow_to_keep = 1.e-9_r8 ! fraction of bottom snow layer to keep with capping. Try changing that parameter to 1.e-3_r8. There isn't really a need for that parameter to be as small as it is, and I think making it larger will solve your problem. Please reply to let us know if that solves the problem; if so, we will make that change in the CTSM repository for the future. However, the fact that you're running into this problem might indicate a problem with your forcing data: It should be very unusual to hit this snow capping limit, at least with the default snow parameters (with a 12-layer snow pack, which is the default in CLM5). I would be concerned that your forcing data has bad values of rain and/or snow in some grid cells, or possibly incorrect units, so that it is generating very large amounts of precipitation in one time step. So I recommend also checking that your precipitation values are reasonable.

I am going to move this thread to the land model forums in case you need further support.

 

[syang]

Regarding (1): I'm not sure, but my first guess is that you're seeing artifacts from the interpolation of out-of-the-box initial conditions at coarser resolution. By default, CLM will start with spunup initial conditions, typically at about 1 degree resolution. These initial conditions then get interpolated to the model resolution using a nearest-neighbor interpolation. Therefore, it is not surprising to see blocky state variables in a very high resolution run until the model has run long enough to re-spin-up under the new conditions. (I'm not sure if this can explain the blockiness in fluxes like NPP, but it seems a likely explanation for TOTECOSYSC.) If you do "./xmlquery CLM_FORCE_COLDSTART=on", my guess is that you won't see this blockiness, as long as you are also using high-resolution atmospheric forcing data.

Regarding (2): It looks like there are roundoff-level issues in the snow capping. To work around this issue: In the CTSM source code you should see a file src/biogeophys/SnowHydrologyMod.F90. Around line 3282, you should see a line, real(r8), parameter :: min_snow_to_keep = 1.e-9_r8 ! fraction of bottom snow layer to keep with capping. Try changing that parameter to 1.e-3_r8. There isn't really a need for that parameter to be as small as it is, and I think making it larger will solve your problem. Please reply to let us know if that solves the problem; if so, we will make that change in the CTSM repository for the future. However, the fact that you're running into this problem might indicate a problem with your forcing data: It should be very unusual to hit this snow capping limit, at least with the default snow parameters (with a 12-layer snow pack, which is the default in CLM5). I would be concerned that your forcing data has bad values of rain and/or snow in some grid cells, or possibly incorrect units, so that it is generating very large amounts of precipitation in one time step. So I recommend also checking that your precipitation values are reasonable.

I am going to move this thread to the land model forums in case you need further support.

Thank you for your relpy. I run the spinup again with default GSWP data and the blocky issue is gone. For (2), I will try this method to see what happend and let you know then.

 

[syang]

Regarding (1): I'm not sure, but my first guess is that you're seeing artifacts from the interpolation of out-of-the-box initial conditions at coarser resolution. By default, CLM will start with spunup initial conditions, typically at about 1 degree resolution. These initial conditions then get interpolated to the model resolution using a nearest-neighbor interpolation. Therefore, it is not surprising to see blocky state variables in a very high resolution run until the model has run long enough to re-spin-up under the new conditions. (I'm not sure if this can explain the blockiness in fluxes like NPP, but it seems a likely explanation for TOTECOSYSC.) If you do "./xmlquery CLM_FORCE_COLDSTART=on", my guess is that you won't see this blockiness, as long as you are also using high-resolution atmospheric forcing data.

Regarding (2): It looks like there are roundoff-level issues in the snow capping. To work around this issue: In the CTSM source code you should see a file src/biogeophys/SnowHydrologyMod.F90. Around line 3282, you should see a line, real(r8), parameter :: min_snow_to_keep = 1.e-9_r8 ! fraction of bottom snow layer to keep with capping. Try changing that parameter to 1.e-3_r8. There isn't really a need for that parameter to be as small as it is, and I think making it larger will solve your problem. Please reply to let us know if that solves the problem; if so, we will make that change in the CTSM repository for the future. However, the fact that you're running into this problem might indicate a problem with your forcing data: It should be very unusual to hit this snow capping limit, at least with the default snow parameters (with a 12-layer snow pack, which is the default in CLM5). I would be concerned that your forcing data has bad values of rain and/or snow in some grid cells, or possibly incorrect units, so that it is generating very large amounts of precipitation in one time step. So I recommend also checking that your precipitation values are reasonable.

I am going to move this thread to the land model forums in case you need further support.

Hi Bill,

I changed the parameter from 1.e-9 to 1.e-3 and then the problem is solved! The case run successfully now!

Thank you

 

[sacks]

Thanks for letting me know. I have opened an issue: Need to increase min_snow_to_keep · Issue #1425 · ESCOMP/CTSM

 

[sacks]

This is fixed in ctsm5.1.dev053.

 

[CGL]

Thanks for letting me know. I have opened an issue: Need to increase min_snow_to_keep · Issue #1425 · ESCOMP/CTSM

Hi,sacks! I'm very confuse about the output of TOTECOSYSC variable.
I set the " CLM_ACCELERATED_SPINUP=on", but I can't find the TOTECOSYSC variable in CLM.h0* file so that I can't use the SpinupStability_v10.ncl to calculate the state.
But, I find the TOTECOSYSC variable in the other case whose " CLM_ACCELERATED_SPINUP=Off". Any suggsetion?

 

[slevis]

During spinup, you need
hist_empty_htapes = .false.
in the case's user_nl_clm to enable all the fields to appear in your history files.