ERROR: (shr_dmodel_readstrm) ERROR in data sizes

[B.S.Wei]

Dear All,

I am currently running CLM5 for my region using GSWP3v1 forcing data. I have successfully created the domain and surface datasets at a 0.5x0.5 resolution and built the model without issues. However, when I submit the case, an error occurs. Could anyone provide guidance on how to resolve this problem?

I would greatly appreciate any help or suggestions you can offer.

Thank you in advance!
Best regards,
Belasoviet
-Campset: I2000Clm50BgcCropGs

./xmlchange STOP_N=1
./xmlchange DIN_LOC_ROOT=/home/phouta/cesm/inputdata
./xmlchange ATM_DOMAIN_FILE=domain.lnd.TRSR_0.5_noocean.250221.nc
./xmlchange RUN_REFDATE=2010-01-01
./xmlchange RUN_STARTDATE=2010-01-01
./xmlchange DATM_CLMNCEP_YR_START=2010
./xmlchange DATM_CLMNCEP_YR_END=2010
./xmlchange ATM_DOMAIN_PATH=/home/phouta/cesm/inputdata/share/domains
./xmlchange LND_DOMAIN_FILE=domain.lnd.TRSR_0.5_noocean.250221.nc
./xmlchange LND_DOMAIN_PATH=/home/phouta/cesm/inputdata/share/domains
echo "fsurdat = '/home/phouta/cesm/inputdata/lnd/clm2/surfdata_map/surfdata_TRSR_0.5_78pfts_CMIP6_simyr2000_c250221.nc'" >> user_nl_clm
echo "mapalgo = 'nn','nn','nn','nn','nn'" >> user_nl_datm
echo "use_init_interp = .true." >> user_nl_clm
echo "hist_fincl1 = 'TLAI', 'QRUNOFF'" >> user_nl_clm
echo "check_dynpft_consistency = .false." >> user_nl_clm
./xmlchange DIN_LOC_ROOT_CLMFORC=/home/phouta/cesm/inputdata/lmwg/atm_forcing.datm7.GSWP3.0.5d.v1.c170516
echo "hist_nhtfrq = -24" >> user_nl_clm

 

[oleson]

There seem to be some mismatches in your surface dataset and domain file. Surface dataset has lsmlon=19, lsmlat=13. While domain file has 18 and 13.
Also, you should not be using domain.lnd.TRSR_0.5_noocean.250221.nc as the domain file in your datm.streams files. You should be using the default GSWP3 domain file.

 

[B.S.Wei]

Dear Oleson,
thank for your replied!
Base on your suggestion earlier, I have change domain file to default GSWP3 and I masked the file by using ncl_scripts. But I am still facing a problem when I submit case (ERROR: (shr_ncread_domain) ERROR var does not exist frac). Do you have any ideas about this?
Thank you!

 

[oleson]

I think the error is saying that the variable "frac" does not exist on the domain file you are using:

fatmlndfrc = '/home/phouta/cesm/inputdata/share/domains/domain.lnd.360x720_TRSR.c170606.nc'

 

[B.S.Wei]

Thank you for your response!
I am so confusing about how to do regional running by using the default GSWP3 forcing data. Previously, I created the domain and surface data by using tools in clm5 (mkmapdata, gen_domain_files, mksurfdata_map) but it had a problem with data sizes. After that I used a domain file from the default GSWP3 and it's still error with "frac" does not exist. So my question are :

1. Do I need to create the domain and surface data by using (tools/site_and_regional) instead of clm tools?
2. If I use the default GSWP3 domain data, where can I get surface data from? Since The error above I used surfdata_360x720cru_78pfts_simyr2000_c170428.nc and I masked it together with domain file by using ncl_scripts.
If none of the above reasons apply, could you please provide me with the flow step for running the model in my region using GSWP3 forcing data?

thank you!

 

[oleson]

There are two different domain files here. There is one that is used by the land model in conjunction with the surface dataset. The domain file and surface dataset that you are using now appear to be:

fatmlndfrc = '/home/phouta/cesm/inputdata/share/domains/domain.lnd.360x720_TRSR.c170606.nc'
fsurdat = '/home/phouta/cesm/inputdata/lnd/clm2/surfdata_map/surfdata_TRSR_05_38.5-104.5_32-95.5_360x720cru_78pfts_simyr2000_c170428.nc'

Those two appear to have matching lat/lon dimensions, which is good. E.g., the domain file has:

nj = 13 ;
ni = 18 ;

and the surface dataset has:

lsmlat = 13 ;
lsmlon = 18 ;

The current error you are getting is that the domain file doesn't have "frac" on it.

The previous domain file you were using:

fatmlndfrc = '/home/phouta/cesm/inputdata/share/domains/domain.lnd.TRSR_0.5_noocean.250221.nc'

had "frac" on it and dimensions of:

ni = 18 ;
nj = 13 ;

So it seems like you could use that as long as the lat/lons match between the domain file and the surface dataset.

The other domain file is the one that describes the atmospheric forcing grid (GSWP3). I'm not sure what version of the model you are using but the default domain file for that is probably:

domain.lnd.360x720_gswp3.0v1.c170606.nc

That is a global 0.5 degree grid and matches the global 0.5 GSWP forcing data. That is what I meant when I said you should use the default domain file in your datm.streams files. That should come out of the box.

If you want to subset the GSWP3 forcing data to something that is close to your region, you would need to subset both that domain file and all of the forcing files as well, i.e., Precip, Solar, TPQW. The advantage of that is that the model might run faster, however, I think the model will run with the default global forcing data as well.
Sorry for any confusion.

 

[B.S.Wei]

Dear Oleson,
I really appreciate for your response,

Sorry that I keep asking the related question again. But after I run the model in global data (domain.lnd.360x720_gswp3.0v1.c170606.nc), I am still facing the error with "frac" does not exist. Now I am working an other way to run the model.

Currently, I am trying to resample the data to my region with 0.125 resolution and I created the domain, surface dataset by using clm tools. I have successfully built the case but it's still error when I submitted. The error is about forrtl: error (65): floating invalid. So, my question are :

Q1: Is the error caused by my campset selection? (If I choose another campset, it will have more chances of success, am I right?) # Current Campset: I2000Clm50BgcCropGs.

Q2: Is that issue related to the model version? # Note: I am using CLM5.0.1

My current error logfile is included below. Thank you so much!

Best wish,
Belasoviet

 

[oleson]

1. I doubt the current problem is related to the compset. It's more likely a problem of not providing valid values for some or all of the atmospheric forcing variables. This could be due to either bad/unrealistic values of forcing data in the files or incorrect mapping of the forcing data to the model grid.
2. If you can run CLM5.0.1 (I'm not sure what that is exactly, what is the output of git describe in your top-level checkout of clm?) with the default atmospheric forcing, then I doubt the current problem is due to the model version.