Hello everyone,
I have replaced the default GSWP3 forcing data with other 3-hour forcing (CMFD) and run the compset I2000Clm50Sp sucessfully by using cesm2.2.0. However, some errors came up when I tried to replaced it with hourly ERA5 data.
It works with the following three steps:
(1) Setup the case using GSWP3 forcing and modify files;
(2) create a new domain file which is matched with atm forcing;
(3) modify the three stream files (attached below);
(4) make a regional domain (with 'frac' variable) and change the "LND_DOMAIN_FILE" and "ATM_DOMAIN_FILE" to run at reginal scale.
I only run two months (Jan and Feb in 1980) to test the forcing. After submitting the case, the errors in cesm.log file showed:
The processes in atm.log file showed:
It seemed that there was some errors in Solar stream of ERA5 forcing, but I have checked the data, and didnt find any errors in the value or spatial variation of Solar data. Is it because of reading data in hour step or the large amount of data? I don't know how to find the exact problems in the data. Does anyone know how to fix it?
Any suggestions will be appreciated! Thanks in advance.
I have replaced the default GSWP3 forcing data with other 3-hour forcing (CMFD) and run the compset I2000Clm50Sp sucessfully by using cesm2.2.0. However, some errors came up when I tried to replaced it with hourly ERA5 data.
It works with the following three steps:
(1) Setup the case using GSWP3 forcing and modify files;
(2) create a new domain file which is matched with atm forcing;
(3) modify the three stream files (attached below);
(4) make a regional domain (with 'frac' variable) and change the "LND_DOMAIN_FILE" and "ATM_DOMAIN_FILE" to run at reginal scale.
I only run two months (Jan and Feb in 1980) to test the forcing. After submitting the case, the errors in cesm.log file showed:
Code:
NetCDF: HDF error
pio_support::pio_die:: myrank= -1 : ERROR: ionf_mod.F90: 272 :
NetCDF: HDF error
The processes in atm.log file showed:
Code:
(datm_comp_run) atm: model date 19800131 79200s
(shr_dmodel_readstrm) file ub: /scratch01/yuxy/inputdata/ERA5/Solar_test/clmforc.GSWP3.c2011.0.5x0.5.Solr.1980-01.nc 744
(shr_dmodel_readstrm) file ub: /scratch01/yuxy/inputdata/ERA5/Precip_test/clmforc.GSWP3.c2011.0.5x0.5.Prec.1980-01.nc 744
(shr_dmodel_readstrm) file ub: /scratch01/yuxy/inputdata/ERA5/TPHWL_test/clmforc.GSWP3.c2011.0.5x0.5.TPQWL.1980-01.nc 744
(datm_comp_run) atm: model date 19800131 81000s
(datm_comp_run) atm: model date 19800131 82800s
(shr_dmodel_readstrm) close : /scratch01/yuxy/inputdata/ERA5/Solar_test/clmforc.GSWP3.c2011.0.5x0.5.Solr.1980-01.nc
It seemed that there was some errors in Solar stream of ERA5 forcing, but I have checked the data, and didnt find any errors in the value or spatial variation of Solar data. Is it because of reading data in hour step or the large amount of data? I don't know how to find the exact problems in the data. Does anyone know how to fix it?
Any suggestions will be appreciated! Thanks in advance.
Attachments
-
atm.log.41118.230405-095954.txt358.3 KB · Views: 6
-
cpl.log.41118.230405-095954.txt65.2 KB · Views: 1
-
lnd.log.41118.230405-095954.txt148.5 KB · Views: 2
-
cesm.log.41118.230405-095954.zip89.7 KB · Views: 2
-
user_nl_clm.txt1.6 KB · Views: 3
-
user_nl_datm.txt2.1 KB · Views: 6
-
user_datm.streams.txt.CLMGSWP3v1.Solar.txt705 bytes · Views: 10