E3SM-Project / E3SM-Project/E3SM

atmsrf inputdata has bogus values

Open
#2,803 13 comments 0 reactions 0 assignees View on GitHub
Atmosphere bug ELM
Dominant language
Fortran
Stars
440
Forks
481
Avg merge
4d 6h
Merged PRs (30d)
36

Description

It appears that both the raw data used to generate the atmsrf files used by the atmosphere model have some bogus values for soil moisture in them. The tool to interpolate this data to a new grid is in `components/cam/tools/mkatmsrffile`, and the README describes the purpose:

> Atmospheric drydeposition at the surface depends on certain surface
> properties including soil and land use properties. In most cases
> these calculations can be handled in the land model and passed to he
> atmosphere through the coupler. This is the default namelist setting
> drydep_method='xactive_lnd'. However with modal areosols this method
> is not adequate and we must recalculate these fields in the atmosphere
> (see subroutine interp_map in mo_drydep.F90). For unstructured grids
> it was determined to create this offline interpolation tool rather
>than generalize the subroutine interp_map.

The code to interpolate the raw data (which I am still working on figuring out how to build and run) reads in data from `inputdata/atm/cam/chem/trop_mozart/dvel/clim_soilw.nc` and `inputdata/atm/cam/chem/trop_mozart/dvel/regrid_vegetation.nc` and creates an atmsrf file with variables for soil moisture (`soilw` in the file) and land use fraction for different "classes" (`landuse_fraction` in the file). It's not really clear to me what these are used for or what these variables actually are (there are no attributes associated with the variables in the files, and no documentation), but it's clear there is a problem with the soil moisture variables. The raw data in the input `clim_soilw.nc` file has bogus values for December (note numbers in title of each panel indicate min and max values):
![Screen Shot 2019-03-14 at 12 04 42 PM](https://user-images.githubusercontent.com/15826727/54384425-6c9c7900-4651-11e9-8dfe-93a7f244a548.png)
December has a stripe of values of 1e21, while the rest of the data lands between 0 and 0.5. This propagates to the actual input data used for our supported resolutions as well. For example, the atmsrf file for ne30 (https://svn-ccsm-inputdata.cgd.ucar.edu/trunk/inputdata/atm/cam/chem/trop_mam/atmsrf_ne30np4_110920.nc):
![Screen Shot 2019-03-14 at 12 04 57 PM](https://user-images.githubusercontent.com/15826727/54384565-be450380-4651-11e9-8487-aa73ae2ce425.png)
(NOTE that missing data is plotted in the second plot using lowest contour interval as opposed to white because of limitations in matplotlibs plotting of unstructured data). I'm not sure yet if the `soilw` variable is being used by the model, but it's definitely bogus in December. The other variable (`landuse_fraction`) appears to be reasonable. I'm tagging with both the atmosphere and land labels, in case anyone on the land team knows anything about where these come from or what they should look like.

Contributor guide

Open the contributing guide

Research direction

Start with the README and the interpolation tool in components/cam/tools/mkatmsrffile, then inspect inputdata/atm/cam/chem/trop_mozart/dvel/clim_soilw.nc and regrid_vegetation.nc. Compare December soilw values with other months and trace how they appear in the supported atmsrf output, including atmsrf_ne30np4_110920.nc. Done means the source and generated files no longer contain the reported bogus December values and the affected data is verified.

Written by the indexing model from the issue text.

Assessment

Tech stack
fortran
Domain
data
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.