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

The fill value of anomaly forcing of precipitation

Status
Not open for further replies.

Dong Peng

Dong Peng
Member
Hi @oleson , I'm currently checking the NetCDF file for the anomaly forcing. I found that the fill value for precipitation is set to 1 (with units of mm/s). The file path for the anomaly forcing I’ve checked is /inputdata/atm/datm7/anomaly_forcing/CMIP6-SSP5-8.5/af.allvars.CESM.SSP5-8.5.2015-2100_c20220628_classic.nc. Additionally, I noticed that there are no values less than 0. Given this, I wanted to confirm: does this mean that drought conditions were not considered in this scenario?
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
A file with that name doesn't exist in our inputdata on glade or in the repository here:


There is a file with a similar name: af.allvars.CESM.SSP5-8.5.2015-2100_c20220628.nc

Precipitation in that file has a fill value of 1.e36:

double pr(time, lat, lon) ;
pr:_FillValue = 1.e+36 ;
pr:units = "mm/s" ;
pr:mode = "time-dependent" ;
pr:long_name = "atmospheric rain, after rain/snow repartitioning based on temperature scale factor" ;
pr:historical_source_files = "b.e21.BHIST.f09_g17.CMIP6-historical.004.clm2.h0.RAIN.185001-201412.nc" ;
pr:scenario_source_files = "b.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.201501-206412.ncb.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.206501-210012.nc"

The units are misnamed, they should be unitless as in the issue I filed here:


It is a multiplicative factor, so there shouldn't be any negative values.
 
Vote Upvote 0 Downvote

Dong Peng

Dong Peng
Member
A file with that name doesn't exist in our inputdata on glade or in the repository here:


There is a file with a similar name: af.allvars.CESM.SSP5-8.5.2015-2100_c20220628.nc

Precipitation in that file has a fill value of 1.e36:

double pr(time, lat, lon) ;
pr:_FillValue = 1.e+36 ;
pr:units = "mm/s" ;
pr:mode = "time-dependent" ;
pr:long_name = "atmospheric rain, after rain/snow repartitioning based on temperature scale factor" ;
pr:historical_source_files = "b.e21.BHIST.f09_g17.CMIP6-historical.004.clm2.h0.RAIN.185001-201412.nc" ;
pr:scenario_source_files = "b.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.201501-206412.ncb.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.206501-210012.nc"

The units are misnamed, they should be unitless as in the issue I filed here:


It is a multiplicative factor, so there shouldn't be any negative values.
Hi Olson, I am not sure the files are the same one. The below post is the story that I got the file from the pub/olson. I am sure the _classic files has the fill value with 1 rather than 1.e36, could you please check it again?

Anomaly forcing run adds extra streams at runtime, causing an error
 
Vote Upvote 0 Downvote

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Oh, you are talking about a file I created back in June. You indicated that the file was ok, but now it is not? Those files are long gone.
So, I recreated it and put it on the ftp site. It checks out fine here:

double pr(time, lat, lon) ;
pr:_FillValue = 1.e+36 ;
pr:units = "mm/s" ;
pr:mode = "time-dependent" ;
pr:long_name = "atmospheric rain, after rain/snow repartitioning based on temperature scale factor" ;
pr:historical_source_files = "b.e21.BHIST.f09_g17.CMIP6-historical.004.clm2.h0.RAIN.185001-201412.nc" ;
pr:scenario_source_files = "b.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.201501-206412.ncb.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.206501-210012.nc"
 
Vote Upvote 0 Downvote

Dong Peng

Dong Peng
Member
Oh, you are talking about a file I created back in June. You indicated that the file was ok, but now it is not? Those files are long gone.
So, I recreated it and put it on the ftp site. It checks out fine here:

double pr(time, lat, lon) ;
pr:_FillValue = 1.e+36 ;
pr:units = "mm/s" ;
pr:mode = "time-dependent" ;
pr:long_name = "atmospheric rain, after rain/snow repartitioning based on temperature scale factor" ;
pr:historical_source_files = "b.e21.BHIST.f09_g17.CMIP6-historical.004.clm2.h0.RAIN.185001-201412.nc" ;
pr:scenario_source_files = "b.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.201501-206412.ncb.e21.BSSP585cmip6.f09_g17.CMIP6-SSP5-8.5.103.clm2.h0.RAIN.206501-210012.nc"
Thanks, Oleson. I think those files are still good. At first, I thought the unit was the mm/s, and the fill value with 1 could cause some issues, but now I realize the unitless precipitation scale factor with 1 as the fill value is okay. I know the _fillvalue is 1e36, but when I read it into the Matlab matrix, the value in the ocean or somewhere that should be NaN is filled with 1. If I am not misunderstanding, is the precipitation parameter times the GSWPv3 precipitation rather than plus? And for the temperature and humidity parameters, is it a + rather than *?
 
Vote Upvote 0 Downvote

oleson

Keith Oleson
CSEG and Liaisons
Staff member
You can see how the anomaly forcing is applied by searching for "anomaly" in:

components/cdeps/datm/datm_datamode_clmncep_mod.F90
 
Vote Upvote 0 Downvote
Status
Not open for further replies.
Top