Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

FSDS ATM FORCING DATA AND FSDS OUTPUT

Mesmer

Nsassila
New Member
HI, i want to ask, why when i am running my case in clm5.0 the values of FSDS in output are different respected the values of total solar radiation that im putting in input??
 

Mesmer

Nsassila
New Member

running CLM over a single-point test​


im running clm over a single point test ok.

the five variables that im putting in input are : incident solar radiation(FSDS, short wave incident radiation), atm Temperature, relative humidity, wind, precipitation.

my problem is this: after running the model, in output there are two variables that suppose to be the incident radiation , (FSDS or SWdown) there are the same and they contain the same values, but the values are not equal to the one i put in input. it is because there is a factor that change my input variable FSDS that i put in input or the variables are different though they have the same name.


In input im putting the FSDS that is the total incident radiation (short wave)

in output data , it supposes to be the same values because the name of the variables are the same

this is the name of the variable in the output data : atmospheric incident solar radiation from CLM History file information

FSDS (W/m^2) or SWdown(W/m^2)

thank you i think it is clear
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
FSDS in the history file should have the same values as the shortwave radiation you are using as your forcing for a single-point simulation if you are running the model at a time-step that corresponds to your forcing data. E.g., if your forcing data is at half-hourly temporal resolution and the model is run at a half-hourly timestep (dtime=1800), then FSDS should have the same values as the forcing data.
Maybe your forcing data is being interpolated by the datm?
The "tintalgo" for the forcing data should be set to "nearest" in your datm_in.
E.g., here is a typical datm_in for the single-point simulations we run here (this is for the tower site "IT-PT1"):

&shr_strdata_nml
datamode = "CLMNCEP"
domainfile = "/glade/work/oleson/PLUMBER2/input_files/IT-PT1/domain.lnd.fv0.9x1.25_IT-PT1.nc"
dtlimit = 1.5, 1.5, 1.5
fillalgo = "nn", "nn", "nn"
fillmask = "nomask", "nomask", "nomask"
fillread = "NOT_SET", "NOT_SET", "NOT_SET"
fillwrite = "NOT_SET", "NOT_SET", "NOT_SET"
mapalgo = "nn", "nn", "nn"
mapmask = "nomask", "nomask", "nomask"
mapread = "NOT_SET", "NOT_SET", "NOT_SET"
mapwrite = "NOT_SET", "NOT_SET", "NOT_SET"
readmode = "single", "single", "single"
streams = "datm.streams.txt.CLM1PT.CLM_USRDAT 2002 2002 2004",
"datm.streams.txt.presaero.clim_2000 1 2000 2000",
"datm.streams.txt.topo.observed 1 1 1"
taxmode = "extend", "extend", "extend"
tintalgo = "nearest", "linear", "lower"
vectors = "null"

If you still have problems, please attach your lnd_in, datm_in, and log files.
 

Mesmer

Nsassila
New Member
thank u very much it is working now, the problem was on the setting of dtlimit, taxmode, tintalgo there were another kind of setting.
Greatttt
 

Zh Chen

chen
New Member
FSDS in the history file should have the same values as the shortwave radiation you are using as your forcing for a single-point simulation if you are running the model at a time-step that corresponds to your forcing data. E.g., if your forcing data is at half-hourly temporal resolution and the model is run at a half-hourly timestep (dtime=1800), then FSDS should have the same values as the forcing data.
Maybe your forcing data is being interpolated by the datm?
The "tintalgo" for the forcing data should be set to "nearest" in your datm_in.
E.g., here is a typical datm_in for the single-point simulations we run here (this is for the tower site "IT-PT1"):

&shr_strdata_nml
datamode = "CLMNCEP"
domainfile = "/glade/work/oleson/PLUMBER2/input_files/IT-PT1/domain.lnd.fv0.9x1.25_IT-PT1.nc"
dtlimit = 1.5, 1.5, 1.5
fillalgo = "nn", "nn", "nn"
fillmask = "nomask", "nomask", "nomask"
fillread = "NOT_SET", "NOT_SET", "NOT_SET"
fillwrite = "NOT_SET", "NOT_SET", "NOT_SET"
mapalgo = "nn", "nn", "nn"
mapmask = "nomask", "nomask", "nomask"
mapread = "NOT_SET", "NOT_SET", "NOT_SET"
mapwrite = "NOT_SET", "NOT_SET", "NOT_SET"
readmode = "single", "single", "single"
streams = "datm.streams.txt.CLM1PT.CLM_USRDAT 2002 2002 2004",
"datm.streams.txt.presaero.clim_2000 1 2000 2000",
"datm.streams.txt.topo.observed 1 1 1"
taxmode = "extend", "extend", "extend"
tintalgo = "nearest", "linear", "lower"
vectors = "null"

If you still have problems, please attach your lnd_in, datm_in, and log files.
Hi, Oleson.
I read more datm_in about single-point, I want to ask:
(1)the "datm.streams.txt.CLM1PT.CLM_USRDAT 2002 2002 2004"means forcing data the start, end and align year separately is 2002,2002 and 2004, some times why the align year could more than start?
(2)The "datm.streams.txt.presaero.clim_2000 1 2000 2000" start and end year are always 2000 no matter the "datm.streams.txt.CLM1PT.CLM_USRDAT" start and end year is, and align is 1 means equal to the start year? Should not it be the same of the two streams start, align and end the year?
Because I read the aerosoldep_WACCM.ensmean_monthly_hist_1849-2015_0.9x1.25_CMIP6_c180926.nc file of the datm.streams.txt.presaero.clim_2000, the data time is 1849 to 2015.
(3)how to understand that "datm.streams.txt.topo.observed” align, start and end year is 1?
Thanks!
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
(1) Actually, the order is align, start, end
(2) The I2000 compset (which I believe you are referring to) only uses one year of the aerosol deposition file by default (year 2000).
(3) The topo file is static in time and just has a time dimension of 1. It will just be read in at the beginning of a model simulation

double time(time) ;
time:long_name = "time" ;
time:units = "days since 0001-01-01 00:00:00" ;
time:calendar = "noleap" ;

data:

time = 0 ;
}
 
Top