Bottom layer specific humidty sent from the atmosphere model is less than zero

[MrIgnition]

I am running CLM5 with my own atmospheric forcing. A temporally downscaled dataset from daily to sub-daily. After running the case I got this error.


There will be a total of 1 history tapes

History tape 1 write frequency is MONTHLY
All fields on history tape 1 are grid averaged
Number of time samples on history tape 1 is 2
Output precision on history tape 1 = 2

hist_htapes_build hist tape = 1 written with dov2xy= T
hist_htapes_build Successfully initialized clm2 history files
------------------------------------------------------------
Successfully initialized the land model
begin initial run at:
nstep= 0 year= 2012 month= 1 day=
1 seconds= 0

************************************************************

dtime_sync= 1800 dtime_clm= 1800 mod = 0
ENDRUN:
ERROR:
lnd_import ERROR: Bottom layer specific humidty sent from
the atmosphere model is less than zero


I have scanned through the entire dataset on this specified time-step year 2012, month 1 and day 1 but there is no value less than zero.

1. Could it be that the value is in other timesteps in other files within the stream?
2. Could it be that "Bottom layer specific humidity" as mentioned here does not refer to the raw value coming from the forcing?

If (2) is true kindly help point out where to trace it.

Thanks in advance.

 

[MrIgnition]

I am running CLM5 with my own atmospheric forcing. A temporally downscaled dataset from daily to sub-daily. After running the case I got this error.


There will be a total of 1 history tapes

History tape 1 write frequency is MONTHLY
All fields on history tape 1 are grid averaged
Number of time samples on history tape 1 is 2
Output precision on history tape 1 = 2

hist_htapes_build hist tape = 1 written with dov2xy= T
hist_htapes_build Successfully initialized clm2 history files
------------------------------------------------------------
Successfully initialized the land model
begin initial run at:
nstep= 0 year= 2012 month= 1 day=
1 seconds= 0

************************************************************

dtime_sync= 1800 dtime_clm= 1800 mod = 0
ENDRUN:
ERROR:
lnd_import ERROR: Bottom layer specific humidty sent from
the atmosphere model is less than zero


I have scanned through the entire dataset on this specified time-step year 2012, month 1 and day 1 but there is no value less than zero.

1. Could it be that the value is in other timesteps in other files within the stream?
2. Could it be that "Bottom layer specific humidity" as mentioned here does not refer to the raw value coming from the forcing?

If (2) is true kindly help point out where to trace it.

Thanks in advance.

Here are the log files...

 

[oleson]

The error seems to be coming from here in src/cpl/lnd_import_export.F90:

if ( atm2lnd_inst%forc_q_not_downscaled_grc(g) < 0.0_r8 )then
call endrun( sub//' ERROR: Bottom layer specific humidty sent from the atmosphere model is less than zero' )
end if

That variable is the specific humidity from the datm forcing file.
It should be coming from the TPQW file that is being read in.
What does your TPQW streams file look like (e.g., datm.streams.txt.CLMGSWP3v1.TPQW)? I would expect it to have something like this in it:

QBOT shum

where QBOT is the variable name on the forcing file.
Have you checked the last time slice of the last forcing file? Sometimes that value is needed for interpolation to get the model started, although I don't see any evidence of that in your atm log file.

 

[MrIgnition]

Thanks for the suggestions. I have checked my stream file "datm.streams.txt.CLMGSWP3v1.TPQW)" and it is attached here. There is consistency in the stream file variable names and forcing file variable names.

Here is my file header:
dimensions:
time = UNLIMITED ; // (124 currently)
LONGXY = 1440 ;
LATIXY = 720 ;
scalar = 1 ;
variables:
double time(time) ;
time:standard_name = "time" ;
time:units = "days since 2011-1-1 00:00:00" ;
time:calendar = "proleptic_gregorian" ;
time:axis = "T" ;
double Humid(time, LATIXY, LONGXY) ;
Humid:standard_name = "specific_humidity" ;
Humid:long_name = "Near-Surface Specific Humidity" ;
Humid:units = "1" ;
Humid:cell_methods = "time: mean" ;
double EDGEE(scalar) ;
double EDGEN(scalar) ;
double EDGES(scalar) ;
double EDGEW(scalar) ;
double Temp(time, LATIXY, LONGXY) ;
Temp:standard_name = "air_temperature" ;
Temp:long_name = "Near-Surface Air Temperature" ;
Temp:units = "K" ;
Temp:cell_methods = "time: mean" ;
double ps(time, LATIXY, LONGXY) ;
ps:standard_name = "surface_air_pressure" ;
ps:long_name = "Surface Air Pressure" ;
ps:units = "Pa" ;
ps:cell_methods = "time: mean" ;
double rlds(time, LATIXY, LONGXY) ;
rlds:standard_name = "surface_downwelling_longwave_flux_in_air" ;
rlds:long_name = "Surface Downwelling Longwave Radiation" ;
rlds:units = "W m-2" ;
rlds:cell_methods = "time: mean" ;
double sfcWind(time, LATIXY, LONGXY) ;
sfcWind:standard_name = "wind_speed" ;
sfcWind:long_name = "Near-Surface Wind Speed" ;
sfcWind:units = "m s-1" ;
sfcWind:cell_methods = "time: mean" ;

and attached is my streams file.

I initially thought something was wrong with my "time: units" attribute in the NetCDF. I changed it from hours to days but it still didn't flow.

 

[oleson]

Your forcing files seem to be 1440X720, but your domain file name (listed in your user_datm.streams.txt.... file) implies 388X402. I think that domain file should have the same lat/lon dimensions as the forcing file unless I'm missing something.

 

[MrIgnition]

Your forcing files seem to be 1440X720, but your domain file name (listed in your user_datm.streams.txt.... file) implies 388X402. I think that domain file should have the same lat/lon dimensions as the forcing file unless I'm missing something.

I just didn't change the name. My domain file is exactly the same spatial dimension as my forcing file. Please have a look.

netcdf domain.lnd.388x402_RCP26_6hrly_25km.c210623 {
dimensions:
ni = 1440 ;
nj = 720 ;
nv = 4 ;
variables:
double lon(ni) ;
lon:standard_name = "longitude" ;
lon:long_name = "Longitude" ;
lon:units = "degrees_east" ;
lon:axis = "X" ;
double lat(nj) ;
lat:standard_name = "latitude" ;
lat:long_name = "Latitude" ;
lat:units = "degrees_north" ;
lat:axis = "Y" ;
double xc(nj, ni) ;
xc:long_name = "longitude of grid cell center" ;
xc:units = "degrees_east" ;
xc:mode = "time-invariant" ;
double yc(nj, ni) ;
yc:long_name = "latitude of grid cell center" ;
yc:units = "degrees_north" ;
yc:mode = "time-invariant" ;
double xv(nv, nj, ni) ;
xv:long_name = "longitude of grid cell vertices" ;
xv:units = "degrees_east" ;
xv:mode = "time-invariant" ;
double yv(nv, nj, ni) ;
yv:long_name = "latitude of grid cell vertices" ;
yv:units = "degrees_east" ;
yv:mode = "time-invariant" ;
int mask(nj, ni) ;
mask:long_name = "domain mask" ;
mask:units = "unitless" ;
mask:mode = "time-invariant" ;
double area(nj, ni) ;
area:long_name = "area of grid cell in radians squared" ;
area:units = "area" ;
area:mode = "time-invariant" ;

 

[oleson]

Ok. At this point I guess I would try printing some output from lnd_import_export to find out what gridcell has the problem and trace the error back from there.
The only other thing I can think of is related to this datm code in cime/src/components/data_comps/datm/datm_comp_mod.F90:

!--- specific humidity ---
tbot = a2x%rAttr(ktbot,n)
pbot = a2x%rAttr(kpbot,n)
if (sshum > 0) then
e = datm_shr_esat(tbot,tbot)
qsat = (0.622_R8 * e)/(pbot - 0.378_R8 * e)
if (qsat < a2x%rAttr(kshum,n)) then
a2x%rAttr(kshum,n) = qsat
endif
else if (srh > 0) then
e = avstrm%rAttr(srh,n) * 0.01_R8 * datm_shr_esat(tbot,tbot)
qsat = (0.622_R8 * e)/(pbot - 0.378_R8 * e)
a2x%rAttr(kshum,n) = qsat
if(wiso_datm) then
! isotopic forcing
! For tracer specific humidity, lnd_import_mct expects a delta, so
! just keep the delta from the input file - TW
a2x%rAttr(kshum_16O,n) = avstrm%rAttr(srh_16O,n)
a2x%rAttr(kshum_18O,n) = avstrm%rAttr(srh_18O,n)
a2x%rAttr(kshum_HDO,n) = avstrm%rAttr(srh_HDO,n)
end if
else if (stdew > 0) then
if (tdewmax < 50.0_R8) avstrm%rAttr(stdew,n) = avstrm%rAttr(stdew,n) + tkFrz
e = datm_shr_esat(avstrm%rAttr(stdew,n),tbot)
qsat = (0.622_R8 * e)/(pbot - 0.378_R8 * e)
a2x%rAttr(kshum,n) = qsat
else
call shr_sys_abort(subname//'ERROR: cannot compute shum')
endif

If the humidity being read in is greater than the qsat calculated from tbot and pbot, and the qsat calculation is negative for some reason, then the specific humidity would be set to the negative qsat. However, I'm not sure if it's possible to end up with a negative qsat under any conditions.

 

[MrIgnition]

SOLVED!!!
The problem was from qsat calculation coming from pbot and tbot as mentioned. Specifically from my pbot values.
Since pbot is not a required variable for my simulation as standard pressure can be assumed, I turned off pbot from my forcing by excluding it from the streamfile.

Now it works.

The major lesson learned here is how sensitive clm5 can be to poor intervariable correlation as a result of temporal downscaling.
I obviously had a pbot value that was not consistent/realistic with the state of the atmosphere as supplied by the rain, solar, temp, specific humidity, wind and long wave.

Thanks for your support!

 

[Xiaoyu yu]

Hello,
I want to run CLM5 with historical data of CMIP6 from 1980 to 2014 by using CESM2.2. I only care about the physical properties of snow and runoff at daily scale. Because of the large volume of 6-hourly CMIP6, is it practicable to run CLM5 with daily atmosphere data of CMIP6 (precip, solar, temp, specific humidity, wind and long wave)? Do I need to change some parameters related to time step?
Any suggestions will be appreciated! Thanks in advance.

 

[oleson]

We don't have any experience with running CLM forcing with daily data so I'm not sure if/how you could modify the datm to do this.

 

[Xiaoyu yu]

We don't have any experience with running CLM forcing with daily data so I'm not sure if/how you could modify the datm to do this.

Thanks for your reply. I think I will try the 6-hourly CMIP6 data instead.