E3sm: atmsrf inputdata has bogus values

Created on 14 Mar 2019  Â·  13Comments  Â·  Source: E3SM-Project/E3SM

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
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
(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.

Atmosphere Land bug

All 13 comments

Is it still true that "with modal areosols this method is not adequate"? @polunma @huiwanpnnl ?

I don't believe these files (clim_soilw_file, drydep_srf_file, and depvel_lnd_file) are used when drydep_method='xactive_lnd'.

It appears that the default in F compsets is drydep_method='xactive_atm'. I'm not sure how much this matters, but I can confirm that the input file is being used; a simple test in which I supply an atmsrf file in which all of the values have been zeroed is not BFB.

During our meeting, @polunma said the soil moisture is not used but land use from this file is.

Should we remove the soil moisture from the file and the hard-coded .false. setting to use this from the code then? It seems dangerous to leave obviously wrong data sitting around in these inputdata files (at least the ones we make moving forward), and hard-coded false logicals in the code.

I have confirmed that soilw is not used when drydep_method='xactive_lnd',
which is the default for the F compsets in CESM2.

On Thu, Mar 21, 2019 at 9:13 AM Robert Jacob notifications@github.com
wrote:

During our meeting, @polunma https://github.com/polunma said the soil
moisture is not used but land use from this file is.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/E3SM-Project/E3SM/issues/2803#issuecomment-475270304,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI6KppQpEdl2ATPfwh0lPuEoSzMZqzVLks5vY6GcgaJpZM4b1A5H
.

We should not include an input file in the namelist if it is not needed /
used. Dry dep has become convoluted and needs to be cleaned up.

On Thu, Mar 21, 2019 at 9:38 AM Francis Vitt fvitt@ucar.edu wrote:

I have confirmed that soilw is not used when drydep_method='xactive_lnd',
which is the default for the F compsets in CESM2.

On Thu, Mar 21, 2019 at 9:13 AM Robert Jacob notifications@github.com
wrote:

During our meeting, @polunma https://github.com/polunma said the soil
moisture is not used but land use from this file is.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/E3SM-Project/E3SM/issues/2803#issuecomment-475270304,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI6KppQpEdl2ATPfwh0lPuEoSzMZqzVLks5vY6GcgaJpZM4b1A5H
.

Was it hard coded? I thought it was a namelist paramater which we always set to false but could be set to true.

drydep_method = xactive_atm for our F cases though by default. Is there any reason we can't use xactive_lnd instead and avoid using the drydep file altogether?

Is there documentation for the various drydep_methods and when they are supposed to be used?

From cime/src/drivers/mct/cime_config/namelist_definition_drv_flds.xml#L65

  <entry id="drydep_method">
    <type>char</type>
    <category>dry-deposition</category>
    <group>drydep_inparm</group>
    <valid_values>xactive_lnd,xactive_atm,table</valid_values>
    <desc>
      Where dry deposition is calculated (from land, atmosphere, or from a table)
      This specifies the method used to calculate dry
      deposition velocities of gas-phase chemical species.  The available methods are:
      'table'       - prescribed method in CAM
      'xactive_atm' - interactive method in CAM
      'xactive_lnd' - interactive method in CLM
    </desc>
  </entry>

drydep_method = xactive_atm is also the choice in our v1 DECK water cycle runs.

seq_drydep_mod.F90 is in the coupler (cime/src/drivers/mct/shr) because its shared by the land and atmosphere models. The drydep_method is set by the drv_flds_in namelist file read by that routine.

If either xactive_atm or xactive_lnd are used, then mo_chemini will call dvel_inti_xactive in mo_drydep.F90

In that routine, do_soilw is a local logical variable set by this line.
do_soilw = .not. dyn_soilw .and. (has_drydep( 'H2' ) .or. has_drydep( 'CO' ))
dyn_soilw is also not a namelist. Its hardcoded to be FALSE. not.FALSE is TRUE. E3SM doesn't have H2 or CO in its drydep list so the result of that logical expression is FALSE and the bad values aren't read.

E3SM does use the fraction_landuse in the atmsrf file (there are only 2 fields in that file, fraction_landuse and soilw). @brhillman is fraction_landuse ok? That's a 2d, time-invariant field for each of 11 classes.

@rljacob fraction_landuse does appear to be "reasonable". That is, I didn't see any totally wacky values like I saw in soilw, but I don't think we have any tests to validate, and I'm not sure where exactly this data comes from (there is no documentation in the raw data files used to build the atmsrf files).

Was this page helpful?
0 / 5 - 0 ratings