Clone wiki


Simulation of N2O Production and Transport in North America Compared to Tower Measurements

table of contents


This project attempts to answer a question,

How skillfully do currently-available N2O emission inventories, when processed by a regional-scale environmental model (CMAQ), model N2O concentrations observed in North America in 2008?

after it

  1. Justifies modeling N2O.
  2. Assembles best-available emission inventories (EIs) for N2O over a North American spatial domain (AQMEII-NA) for 2008.
  3. Augments (with N2O) artifacts from a previously-made CMAQ run over {AQMEII-NA, 2008}:
    1. boundary and initial conditions
    2. emissions
  4. Builds CMAQ-5.0.1 on the HPCC cluster at EPA and verifies the build with the CMAQ-5.0.1 benchmark.
  5. Runs CMAQ-5.0.1 over {AQMEII-NA, 2008} with N2O-augmented inputs.
  6. Compares model-estimated N2O concentrations to
    1. 2008 N2O observations at the relevant locations/gridcells.
    2. estimates made using other methodologies, e.g., Miller et al 2012 in the Journal of Geophysical Research.

project components

Subprojects providing code or data to this project include

how to improve?

components of a model run

This project attempts to model (using CMAQ) a given atmospheric chemical species (N2O) over a given spatiotemporal domain ({AQMEII-NA, 2008}). But what "goes into" a "CMAQ run"? (Which is actually a CCTM run, but since most of the community says "CMAQ run," I will too.) To a first approximation, a CMAQ run involves feeding four sets of inputs,

  1. meteorology (met)
  2. emissions inventories (EIs)
  3. initial conditions (ICs)
  4. boundary conditions (BCs)

defined for the given species of interest over a given spatiotemporal domain, to an executable instance of a particular CMAQ version built with defined properties (i.e., a given configuration, including

  1. the version of the code
  2. sets of dependencies (such as tools (e.g., compilers) and libraries), each of which has its specific version
  3. the processes modeled, and (where there is a choice) the implementation of the process (e.g., a specific chemical mechanism)

) to produce output: notably, timestep-average concentrations for the species of interest over the spatiotemporal domain. We can therefore vary one or more of the following six aspects

  1. (input) met
  2. (input) EIs
  3. (input) ICs
  4. (input) BCs
  5. (executable) CMAQ version
  6. spatiotemporality: a triple of (horizontal, vertical, temporal) domains

(or their subcomponents) to obtain new output, by "rerunning the model." Note however that

  • each of the input components must be defined over or for a given spatiotemporality (about which the executable must be aware)
  • the input components must broadly agree about the species of interest, the dynamics of which the executable's chemical mechanism must be able to compute

This gives us 7-9 potential degrees of freedom:

  1. (frame) spatiotemporality (a triple)
  2. (frame) species
  3. (input) met
  4. (input) EIs
  5. (input) ICs
  6. (input) BCs
  7. (executable) CMAQ version

For various reasons, we will likely constrain

  • the horizontal aspect of the spatiotemporality
  • the temporal aspect of the spatiotemporality
  • the species computed

That leaves us with six likely degrees of freedom:

  1. (frame) vertical layers
  2. (input) met
  3. (input) EIs
  4. (input) ICs
  5. (input) BCs
  6. (executable) CMAQ version

There follow some examples of how these could potentially usefully be varied.

example: 35 vertical layers

Newer meteorology (e.g., newer versions of WRF) compute more layers of atmosphere, producing more realistic dynamics. Fortunately, other new tools/inventories allow us to compute more-layered BCs and ICs (also presumably better). (Unfortunately, for any given hardware, increasing vertical layers will increase runtime.) An upcoming phase of this project should exploit already-available inputs and verify their veridicality.

example: upgrade CMAQ

Initially we will use CMAQ version=5.0.1, but recently CMAQ version=5.0.2 became available. It probably won't make much difference, but it should have some improvements, and running latest available release of any software is generally preferable.

example: include new EPIC data

Suppose you get new EPIC emissions from agricultural soils over {CONUS, 2008}, and you want to "rerun the model" with this new input. (Note that CONUS is a spatial subset of AQMEII-NA.) In terms of this overall project, this represents updating one EI component: the other run components are unchanged. Given the structure of the project, you would need to

  1. Assimilate the CONUS EPIC emissions into the AQMEII ag-soil emissions.
  2. Assimilate the AQMEII ag-soil emissions into the entire N2O emissions.
  3. Rerun the model with the new emissions.

Given the structure of the project's code, the above goals require (minimally) one to

  1. Clone subproject=regrid_utils, and edit (if necessary) to adapt the code to your platform.
  2. Clone and rerun subproject=AQMEII_ag_soil to generate new ag-soil N2O (similar to that previously generated). More detailed directions are available in the subproject's README.
  3. Clone and rerun subproject=AQMEII-NA_N2O_integration to generate a new N2O EI for the domain, including the new ag-soil N2O. More detailed directions are available in the subproject's README.
  4. Rerun the old model (to be described here) with the new emissions.

example: improve BC/ICs


example: improve marine EI