Welcome to the new DiscussCESM forum!
We are still working on the website migration, so you may experience downtime during this process.

Existing users, please reset your password before logging in here: https://xenforo.cgd.ucar.edu/cesm/index.php?lost-password/

Modifying the clm.i. file

Dear Sam,

Thank you for your reply.

I've already quite thoroughly implemented both of your suggestions. I've taken the formulation of the snow layer data (DZSNO, ZSNO, ZISNO) from CLM routine snowdp2lev. I've made H2OSNO consistent with SNOWDP, and have used an arbitrary value of .05 for SNOWAGE, where SNOWDP > 0.

I've also retained the representation of data/missing values depending on data and column type, for both snow and soil data.

I've made an assumption that the column types (land, glacier, lake, wetland) in a particular gridcell will not change over time. If this is incorrect it may be the source of my problem.

In regards to RTMVOLR, my question should have been expressed as -- Why is RTM initialized for one case (my constructed IC), but not for the other (Spun-up Model output IC)? I've looked in the model code, and in the parameter files to see what "turns on" initialization of RTM, but couldn't find it. I was hoping someone had that answer, since it's my only clue as to why my CLM IC is causing CAM to bomb after initialization.

Otherwise, I'm clueless.


Dan Paolino


If you used the same surface dataset in both runs, then you correctly assumed that the gridcells, landunits, columns, and pfts should have remained the same.

Regarding RTM, the subroutine initialize includes these lines:

#if (defined RTM)
! Initialize river routing model

if (masterproc) write(6,*)'Attempting to initialize RTM'
call Rtmlandini()
if (masterproc) write(6,*)'Successfully initialized RTM'

If you see this text in the clm.log file in one run and not the other, this suggests that RTM is defined in one and not the other. I assume that you tried the two runs in exactly the same way and that both clm.i files contained exactly the same RTMVOLR info. If so, I cannot explain the difference in what you see in the clm.log file...

My next suggestion involves running the clm in offline mode to debug this problem. Debugging is much easier in offline mode. You could even run on a single processor and place "write statements" in key locations in order to follow exactly what the model does with your new initial data, where it fails, and how that compares with the run that works. Problems are usually harder to diagnose in coupled mode in my experience.