CLM5.0 at f02_g16: glc2lnd mapping missing, lsmpft dimension mismatch.

[bowen]

Hi community,

I'm attempting to run a I2000Clm50Sp simulation at 0.23x0.31 (f02_g16) resolution (for an urban-focused study). I've made a surface dataset at the desired resolution with mksurfdata ("surfdata_0.23x0.31_hist_78pfts_CMIP6_simyr2000_..."), and the domain files are ATM_DOMAIN_FILE=domain.lnd.fv0.23x0.31_gx1v6.100517.nc, LND_DOMAIN_FILE=domain.lnd.fv0.23x0.31_gx1v6.100517.nc.

Here are some issues I've encountered:

1) The model (I2000Clm50Sp) would fail building with error "Need to provide valid mapping file between glc and lnd in xml variable glc2lnd_smapname". I'm currently circumventing the problem by using I2000Clm50SpGs (stub land ice). Is there a better solution?

2) The model (I2000Clm50SpGs) execution fails and log files indicate "mismatch of input dimension 79 with expected value 17 for variable lsmpft". I suspect surface data with 16 PFTs is expected here, but it seems "mksurfdata.pl -res 0.23x0.31" generates dataset with 78 PFTs by default. Should I make some new surfdata, or change the settings in the model?

I'm currently using CESM2.1.3, CLM5.0.30, running on Cheyenne. Log file: /glade/scratch/bowen/i.e213.I2000Clm50SpGs.f02_g16.timetest/run/cesm.log.3508992.chadmin1.ib0.cheyenne.ucar.edu.200805-113159.

Any help is appreciated!

Bowen

 

[oleson]

I don't see a glc2lnd_smapname file for that resolution in the inputdata repository, so I guess it's not supported. Other user have done what you have done, selected the stub land ice (Gs).
You can run mksurfdata.pl with the "-no-crop" option to get a 16 pft dataset, which is what an SP compset expects.

 

[bowen]

Thank you Keith! That helps a lot. I think the input data is now correct.

One followup question: The model has a new error: MPT ERROR: xxx received signal SIGSEGV(11). I've attached the log files. Do you have any advice on how to solve this?

Thanks,
Bowen

 

[oleson]

The cesm log file has this:

488:MPT: #6 0x0000000000582b04 in histfilemod_mp_hfields_write_ ()
488:MPT: at /glade/u/home/bowen/CESM2.1.3/components/clm/src/main/histFileMod.F90:3044
488:MPT: #7 0x0000000000573c9e in histfilemod_mp_hist_htapes_wrapup_ ()
488:MPT: at /glade/u/home/bowen/CESM2.1.3/components/clm/src/main/histFileMod.F90:3553
488:MPT: #8 0x0000000000502789 in clm_driver_mp_clm_drv_ ()
488:MPT: at /glade/u/home/bowen/CESM2.1.3/components/clm/src/main/clm_driver.F90:1177
488:MPT: #9 0x00000000004ef26b in lnd_comp_mct_mp_lnd_run_mct_ ()
488:MPT: at /glade/u/home/bowen/CESM2.1.3/components/clm/src/cpl/lnd_comp_mct.F90:456

Line 3044 of histFileMod.F90 is:

hist1do(beg1d_out:end1d_out) = histo(beg1d_out:end1d_out,1)

I believe errors associated with this line of code can occur if you are requesting subgrid output for history field variables that are only available at the gridcell level.
It looks like you are requesting landunit level output in your second history file stream. There are three variables in that request that are only available at gridcell level: EFLX_DYNBAL, FSDS, AND RH.
You can find out at which level variables are available at by grepping for the variable, e.g.,

this%eflx_dynbal_grc(begg:endg) = spval
call hist_addfld1d (fname='EFLX_DYNBAL', units='W/m^2', &
avgflag='A', long_name='dynamic land cover change conversion energy flux', &
ptr_lnd=this%eflx_dynbal_grc)

This indicates that EFLX_DYNBAL is a gridcell level variable.

I think that if you remove EFLX_DYNBAL, FSDS, and RH from hist_fincl2, you'll be able to run.