ERROR: (shr_dmodel_readstrm) ERROR in data sizes

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

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.

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!

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'

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!

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.

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

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.

Dear Keith,
Apologies for reaching out again, but I truly need your help.

I am currently trying to generate surface data using mksurfdata_map with CLM5.0.34. However, I encountered the following error:
ERROR in mksurfdata_map: 34304 and after I check lai data, I found that (phouta@localhost pftcftdynharv.0.05x0.05.LUH2.histsimyr2005.c190116]$ ncdump -h mksrf_lai_histclm52deg005_earthstatmirca_2005.c190119.ncncdump: mksrf_lai_histclm52deg005_earthstatmirca_2005.c190119.nc: NetCDF: HDF error).
I have a few questions:
Q1.Could this error be due to an issue with my data download?
Q2.How can I successfully generate surface data using CLM5.0.34? I was able to generate data with CLM5.0.1, but the case submission failed with the error mentioned above.
Q3.If possible, could you provide surface data for both crop and no-crop cases at 0.125° resolution? For example:

• ftp://ftp.cgd.ucar.edu/pub/oleson/surfdata_0.125x0.125_hist_16pfts_Irrig_CMIP6_simyr2000_c230311.nc
• Surface data for 78 PFTs

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

I would greatly appreciate your support.

@B.S.Wei I have a few initial thoughts:
- You said you generated surface data with CLM5.0.1. Was the resolution coarser? As a sanity check, I suggest that you return to CLM5.0.1 and generate the data that you generated before, so that you can start from a baseline that works. This usually makes troubleshooting easier.
- Another thought when I see inexplicable netcdf errors: Try "ncdump -k" on the file to find out the netcdf version of the file. Maybe you need to update to cdf5 by typing "nccopy -c cdf5 <file.nc> <file_cdf5.nc>"
- Is the resolution possibly too high for your computer, and you are seeing a manifestation of memory problems? If so, you need to ask for help from the team that manages your computer.

Also I'm copying some 0.125x0.125 files that I see in our /inputdata/.../surfdata directories to our anonymous ftp site under ...pub/slevis/for_bswei/.

Each file takes about 15' to copy.

slevis said:

@B.S.Wei I have a few initial thoughts:
- You said you generated surface data with CLM5.0.1. Was the resolution coarser? As a sanity check, I suggest that you return to CLM5.0.1 and generate the data that you generated before, so that you can start from a baseline that works. This usually makes troubleshooting easier.
- Another thought when I see inexplicable netcdf errors: Try "ncdump -k" on the file to find out the netcdf version of the file. Maybe you need to update to cdf5 by typing "nccopy -c cdf5 <file.nc> <file_cdf5.nc>"
- Is the resolution possibly too high for your computer, and you are seeing a manifestation of memory problems? If so, you need to ask for help from the team that manages your computer.

Click to expand...

Dear slevis,
Thank you so much for your responds!

Base on your solution above, I can solve my problem by: Running the tools with (./mksurfdata.pl -r usrspec -usr_gname $GRIDNAME -usr_gdate $CDATE -hirespft -crop) but not this (./mksurfdata.pl -r usrspec -usr_gname $GRIDNAME -usr_gdate $CDATE -hirespft -crop). I think you are right! Maybe the resolution possibly too high for your computer and that's why I cannot generate a high resolution of pft.

Everything runs smoothly during the initial steps (e.g., Case_setup, Case_build, etc.) after generating my surface data. However, I encounter an error when I attempt to submit the case using case_submit. The specific error message is: ERROR: too much NH4 uptake predicted by FUN.

1. Could my surface data or domain file have been incorrectly generated?
I suspect there might be an issue with how my surface data or domain file was generated. Could this be a potential source of error in my model setup?

2.Could the error be caused by my forcing data?
I am using GSWPv3 data, which I resampled to a resolution of 0.125° x 0.125°. Could there be an issue with how the forcing data was processed or resampled that might be causing errors in my simulation?

My current error logfile is included below

I would greatly appreciate your support.

You can try to troubleshoot as follows:
- Set up a simulation with no changes of your own. That simulation should run without errors.
- Then start making your changes one by one until you discover which of your changes is responsible for the errors that you see.