Testing CLM w/ data atmosphere vs coupled

[hayesdev]

Hello all,

I am running an offline SLIM simulation using atmospheric data from a coupled slim-cam simulation. (SLIM is a simple land model that couples in place of CLM... see Home · ESCOMP/SimpleLand Wiki.) Both the offline and the coupled simulations have the exact same land surface and will function as control runs for a series of offline vs coupled perturbation simulations.

I want to make sure that the offline and coupled control simulations indeed have the same atmospheric conditions at each time step.

If an offline simulation (OFF) is getting atmospheric data from a previously-run coupled simulation (CPL) and they both have the same surface, I’d expect for atmosphere-related output variables (like Thref) to be the same and for land-related variables (like Ts) to be different. In other words, taking the difference between land history output, I’d expect Thref=0 and Ts to be non-zero.

However, when I run the coupled and offline for a year, I find that differenced Thref isn’t exactly zero and that the first time step (month) has a large difference.

Main Questions

1. Am I correct in my assumption that Thref should be zero?
   1. Is nearly zero good enough to indicate the atmospheric conditions are the same?
2. Is Thref a good metric for double checking offline vs coupled atmosphere? Or is there a different variable I should look at?
   1. How do I test/confirm that the atmospheric data is the same between both? (When the offline has no atmosphere CAM output)
3. Should I expect the first time step to be starkly different? Is there a way to correct for this/do I need to?
4. Is it reasonable to expect the offline and coupled simulations to behave exactly the same given the same land surface and data atmosphere? Or will there always be slight differences?

Compsets:
CPL Compset = 2000_CAM50_CLM50%BGC_CICE_DOCN%SOM_SROF_SGLC_SWAV
OFF Compset = 2000_DATM%CPLHIST_CLM50%BGC_CICE_DOCN%SOM_SROF_SGLC_SWAV

XML changes:
Here are the xml settings that I used for the offline run:

DATM_CPLHIST_YR_ALIGN="1"​

DATM_CPLHIST_YR_START=1​

DATM_CPLHIST_YR_END=1​

RUN_STARTDATE="0001-01-01"​

Screenshots of the difference of the OFF-CPL run are attached, the first time step being very different in Thref and the second time step being less-so.

Any guidance appreciated! Thanks

 

[oleson]

First of all, I'm not familiar with SLIM, but I assume that it operates similarly to CLM with respect to atmospheric forcing.
Forcing the model with coupler history output is not going to result in OFF-CPL differences of zero, even for the forcing variables. Typically, coupler history output is at a time resolution coarser than the time step of the model run. For example, the model is typically run at 1/2 hour resolution, the coupler history output for solar, precipitation, and the other forcings are at 1 hour or 3 hour depending on the forcing. These are then interpolated to the model time step. This should result in similar forcing in OFF and CPL mode, but the differences will not be zero.
Is Thref similar to the 2-m reference height history variable in CLM, which is TSA? TSA is not strictly a forcing variable because it is essentially interpolated from the forcing temperature and the canopy air temperature (at least in CLM, I'm not sure if SLIM has a vegetation canopy).
If you want to see what the differences in forcing are, you could difference the forcing history variables from the SLIM history files in the OFF and CPL simulations. Typical forcing variables include TBOT, QBOT, FSDS, FLDS, RAIN, SNOW, ... I assume these would be available in a SLIM simulation as well?

 

[hayesdev]

Thank you for the insight and feedback, it's been very helpful.

However, I've now run into a problem when my OFF simulation resubmits. For the first iteration of the run, it runs perfectly fine for any amount of years, but fails immediately after resubmission. I'm not entirely sure what's at fault. I've run successfully for 1, 5, and 10 years up until the resubmit, so it doesn't seem to be a problem of the atmospheric data itself. I've attached my log files for a run that failed on the resubmit after year 1.

Any idea what might be going on? Let me know if you need any other information. Thanks again!

 

[oleson]

Unfortunately, I don't recognize that module that is throwing the error:

ERROR in mml_main.F90 at line 1147

Maybe it is a SLIM module? Maybe you can get help from the SLIM group.