The Meteorology-Chemistry Interface Processor (MCIP) for the CMAQ modeling system: updates through MCIPv3.4.1

The Community Multiscale Air Quality (CMAQ) modeling system, a state-of-the-science regional air quality modeling system developed by the US Environmental Protection Agency, is being used for a variety of environmental modeling problems including regulatory applications, air quality forecasting, evaluation of emissions control strategies, process-level research, and interactions of global climate change and regional air quality. The MeteorologyChemistry Interface Processor (MCIP) is a vital piece of software within the CMAQ modeling system that serves to, as best as possible, maintain dynamic consistency between the meteorological model and the chemical transport model (CTM). MCIP acts as both a post-processor to the meteorological model and a pre-processor to the emissions and the CTM in the CMAQ modeling system. MCIP’s functions are to ingest the meteorological model output fields in their native formats, perform horizontal and vertical coordinate transformations, diagnose additional atmospheric fields, define gridding parameters, and prepare the meteorological fields in a form required by the CMAQ modeling system. This paper provides an updated overview of MCIP, documenting the scientific changes that have been made since it was first released as part of the CMAQ modeling system in 1998.


Introduction
The Community Multiscale Air Quality (CMAQ) modeling system (Byun and Schere, 2006) simulates atmospheric processes and air quality (including gas-phase chemistry, heterogeneous chemistry, particulate matter, and airborne toxic pollutants) over a broad range of spatial and temporal scales Correspondence to: T. L. Otte (otte.tanya@epa.gov)using a comprehensive computational framework based on first-principles solutions.The CMAQ modeling system is considered to be at the state-of-the-science of Eulerian (gridded) air quality modeling.It was first released as a community model in 1998, and in just over ten years it has developed a diverse and growing worldwide community of a few thousand users (Fig. 1).It is widely used for a variety of retrospective, forecasting, regulatory, climate, atmospheric process-level, and emissions control applications for local, state, and national government agencies, at academic institutions, and in private industry.
There are three primary components of offline air quality modeling systems: the meteorological fields, the emissions inputs, and the chemical transport model (CTM).Here, offline modeling refers to when there is no feedback from the atmospheric chemistry in the CTM to the meteorological simulations, as would occur with the impacts of particulate matter on radiation, clouds, and precipitation.In the CMAQ modeling system, the meteorological fields are acquired from prognostic, regional-scale Eulerian meteorological models.Because it uses a generalized vertical coordinate system (Byun, 1999), the CTM can process meteorological fields from models with different vertical coordinate systems (e.g., time-independent sigma-pressure, time-varying sigmapressure, height, among others).However, each meteorological model's horizontal and vertical coordinates must be properly transformed to the CTM's coordinates in order to maintain mass consistency, which is critical for air quality modeling.In addition, each meteorological model (and some physics options within those models) generates its own suite of geospatial and prognostic fields that need to be converted into a standardized suite of fields and a common file format that is expected by the CMAQ modeling system.Therefore it is desirable to have an intermediate software program as part of the CMAQ modeling system to serve as a conduit to prepare the meteorological fields for use in the CTM.The Meteorology-Chemistry Interface Processor (MCIP) is a critical component of the CMAQ modeling system that post-processes the meteorological model output fields and pre-processes them for the emissions and the CTM.MCIP ingests the meteorological model fields from multiple models in their native output formats, performs horizontal and vertical coordinate transformations, diagnoses additional atmospheric fields, defines gridding parameters, and prepares the output in a format that is common to the CMAQ modeling system.MCIP is used in offline modeling applications with the CMAQ modeling system.The output from MCIP is a suite of model-ready meteorological fields that are input for emissions processing and for the CTM.
MCIP is designed to maximize physical, spatial, and, temporal consistency between the meteorological fields and the CTM.In this manner, MCIP is sensitive to the horizontal staggering and vertical coordinate systems of the input meteorological models, and it is tailored to internally adapt to those details.In addition, MCIP is designed to maximize the use of the prognostic fields directly from the meteorological model wherever possible.However, MCIP is also set up to necessitate minimal modifications in the input meteorological model (with regard to required output fields, prescribing mandatory physics options, or altering physical constants) to accommodate users with a variety of meteorological modeling applications and CMAQ users who acquire their meteorological fields from another source (i.e., users with a specific interest in only air quality modeling who collaborate or contract with a partner who provides meteorological model fields).MCIP is designed to limit the burden on the user community by keeping it as flexible and adaptable as pos-sible.Lastly, MCIP is meant to be a transparent software program such that there is no need to name the input model source a priori.MCIP can adapt to and generate fields for various Eulerian meteorological models with regular limitedarea grids.In order to minimize the effort of software maintenance, particularly as scientific improvements are developed and implemented, there is only one instantiation of MCIP in the CMAQ modeling system rather than separate versions of MCIP for each meteorological model.MCIP is specifically designed to dynamically determine as much information about the incoming meteorological data sets as possible (e.g., domain sizes, projections, available input fields) to minimize the amount of user input and the potential for user errors.The CMAQ modeling system (including its emissions processing component) uses output from MCIP without specifying the source model for the incoming meteorological data.
The purpose of this paper is to describe the scientific and logistical aspects of MCIP.The fundamental scientific equations in the original MCIP documentation (Byun et al., 1999) are still applicable.However, because the CMAQ modeling system has been under continuous development, earlier documentation of MCIP does not reflect the current state of the CMAQ modeling system or the current science.For example, additional meteorological models are now supported in MCIP, and MCIP has been considerably streamlined with regard to user options and input needs since its original release.This article provides updated information regarding the current processing in MCIP.Additional detailed information regarding the timeline of changes to MCIP is provided as part of the official releases of MCIP.

Meteorological input
The community release of MCIP can ingest and process meteorological fields from the fifth-generation Pennsylvania State University/National Center for Atmospheric Research Mesoscale Model (MM5) (Grell et al., 1994) and from the Weather Research and Forecasting (WRF) Model's Advanced Research WRF (ARW) core (Skamarock et al., 2008).Other meteorological models have been coupled with the CMAQ modeling system via MCIP or software that either mimics or was adapted from MCIP (see Sect. 8), but the community release of MCIP is restricted to using MM5 and WRF-ARW data sets at this time.The meteorological input can be ingested by MCIP on the Lambert conformal, polar stereographic, and Mercator projections; Lambert conformal is the most widely used projection in the CMAQ modeling community.Latitude-longitude grids (e.g., in the WRF Nonhydrostatic Mesoscale Model, NMM, core) are currently not supported in MCIP because substantial changes would be required in the CMAQ modeling system to account for the absence of the map-scale factors with latitude-longitude grids, and the governing equations in the CTM would need to be recast without a dependency on map-scale factors.
The required meteorological input fields in MCIP are used to define the physical, dynamic, and thermodynamic states of the troposphere and lower stratosphere for the emissions and the CTM in CMAQ.These fields include geospatial information, prognostic state variables, and several nearsurface fields to sufficiently describe the atmospheric influence on the production, dispersion, transport, and deposition of chemical constituents, particularly within the planetary boundary layer (PBL) where the human and ecological populations can be affected by exposure (prolonged or acute) to these species.The physical description of the meteorological modeling domain (map projection, horizontal extent and grid spacing, vertical layer structure, and model top) is ingested by MCIP.The gridding properties of the meteorological model define the maximum extent of the air quality simulation domain, and the CTM inherits this information from the meteorological model via MCIP.
Within MCIP, there is a capability to generate meteorological fields on a horizontal subset (i.e., "window") of the meteorological model's simulation domain.Windows are typically used in the CMAQ modeling system to remove the influences of the meteorological model's lateral boundary conditions (generally on the order of five grid cells around the perimeter of the domain), to limit the CTM simulation to a focal area within an oversized meteorological domain, or to increase efficiency by reducing the computational area, particularly to test scientific changes to the CTM.The options to specify a window and/or change a window definition in MCIP are run-time input.
Another option in MCIP is to specify a vertical subset of the meteorological model's computational layers to be used in the CTM.This technique, commonly called "layer collaps-ing", is typically used to increase efficiency in the CTM by decreasing the number of computational cells for chemical transport and vertical mixing.Layer collapsing is performed in MCIP as a final step before the output is created; all of the vertical computations in MCIP otherwise include the full vertical extent of the meteorological model fields.The layer fields are collapsed using simple vertical interpolation of the meteorological fields on the two layers that bound the desired output layer.In principle, the computational layers for the CTM can be specified in MCIP to have nearly any distribution between the surface and the top of the model.The exception is that MCIP output layers may not be specified to be closer to the ground or closer to the model top than the lowest and highest meteorological model layers, respectively, because additional assumptions regarding the stability at the bottom and/or top of the atmosphere would be required, and those assumptions would be difficult to generalize in a scientifically meaningful way.It is recommended, however, that when layer collapsing is used in MCIP that the CTM have common layer interfaces with the meteorological model to minimize interpolation.Layer collapsing is commonly used throughout the CMAQ community for all ranges of applications (except two-way-coupled meteorology-chemistry modeling which inherently requires all layers), and the layers are typically collapsed preferentially near the top of the atmosphere, leaving the near-surface meteorological conditions nearly intact for the CTM.It is also advisable to preserve vertical layers near the tropopause to properly handle exchanges between the troposphere and stratosphere.Layer collapsing will ensure mass conservation only when a CTM layer is comprised of no more than two meteorological model layers and when the layer interfaces of the CTM layers are coincident with layer interfaces from the meteorological model's vertical structure.
MCIP was originally developed and released in 1998 to support MM5 version 2 (MM5v2) formatted data sets.In MCIP version 2.0, which was released in 2001, MCIP was expanded to support output fields from MM5 version 3 (MM5v3), which has different dynamic assumptions, vertical coordinate, and file format than MM5v2 and has been the primary input data source for CMAQ over the past several years.Beginning with MCIP version 3.0 (released in 2005), MCIP was also upgraded and expanded to support output fields from WRF-ARW.Although the MM5 and WRF models are closely related and contain many of the same physics packages, the WRF model uses different state equations, fields, horizontal and vertical coordinate systems, and file formats than MM5.Therefore, significant changes were required to MCIP to ingest and prepare WRF model output for the CMAQ system.In addition, MCIP was altered to prepare to move the computation of dry deposition velocities from MCIP to the chemical transport model in the CMAQ system where bidirectional surface fluxes (i.e., both deposition and evasion) could be computed as needed for various chemical species (see Sect. 5.2).The most recent release Fig. 2. Graphical illustration of grid cells in an X-Y plane and the placement of the scalars ("h", shown in light blue) and the u-and vcomponents of the wind ("u" and "v", shown in yellow and red, respectively) on the (a) Arakawa B, (b) Arakawa C and (c) Arakawa E grids (based on Arakawa and Lamb, 1977).
of MCIP, version 3.4.1,became available in 2008 as companion software to CMAQ version 4.7.The following subsections describe caveats of using MM5v3 and WRF-ARW model fields in MCIP.

Special information for MM5v3 model input
Because the CMAQ modeling system was first developed for MM5v2 fields, there are few restrictions with using MM5v3 fields in MCIP.MM5 uses Arakawa B horizontal staggering (Fig. 2a) so the horizontal wind components are defined at cell corners and all other prognostic fields are defined at the cell centers.The CMAQ CTM uses Arakawa C horizontal staggering (Fig. 2b), where the horizontal wind components are on perpendicular cell faces and all other prognostic fields are defined at the cell centers.Because there is a difference in the physical locations of the wind components between the MM5 and CMAQ computational domains, interpolating the raw MM5v3 wind components in MCIP from the cell corners to the cell faces is necessary to use them in CMAQ.
The only required input to MCIP from MM5v3 is the model output file (MMOUT).This file contains all of the geospatial and dynamic meteorological fields to be prepared for the emissions processing and the CTM.MM5 output in MMOUT must be captured hourly, at most, because the CTM expects meteorological fields resolved at no coarser than hourly temporal spacing.An optional but recommended file that contains the two-dimensional geospatial fields (TER-RAIN) can be ingested by MCIP specifically to access the fractional land use arrays that are used in MM5 for the Pleim-Xiu land-surface model (LSM) (Xiu and Pleim, 2001) but are not included in the MMOUT file.Fractional land use can be used in the CTM to refine the calculations of the nocturnal vertical mixing in urban areas and to apply the bidirectional surface flux calculations in the CTM.When the satellite cloud processing option is used (see Sect. 5.4), preprocessed files that contain the satellite fields can also be processed by MCIP.Several restrictions apply to the satellite processing option, and the default setting is that it is not used in MCIP or in the CTM.

Special information for WRF-ARW input
Here, the linkage in MCIP only refers to the WRF-ARW core; linkage to the WRF-NMM core via MCIP is not a publically available product.Like CMAQ, WRF-ARW uses an Arakawa C-staggered horizontal grid, so horizontal interpolation of the WRF output fields is generally not required in MCIP for CMAQ.The exception is that the plume rise calculations in the emissions processor still expect wind components on the cell corners regardless of the input meteorological model, so wind components are interpolated to the Arakawa B grid to satisfy this requirement.
To use WRF fields, it is required that users add the following variables to the WRF output (i.e., history) file via the WRF Registry (WRF variable names are given in parentheses): friction velocity (UST), albedo (ALBEDO), and roughness length (ZNT).Monin-Obukhov length (inverse of RMOL), leaf-area index (LAI), and canopy water (CAN-WAT) should also be added to the output fields, but they can be computed in MCIP if they are unavailable in the output.If the Pleim-Xiu LSM is used in the WRF model, the timevarying vegetation fraction (VEGF PX), aerodynamic resistance (RA), and surface resistance (RS) should also be added to the output file.In addition, it is recommended but not required that fractional land use (LANDUSEF) be added to the WRF history file to refine the calculations of the nocturnal vertical mixing in urban areas and to apply the bidirectional surface flux calculations in the CTM.Unlike MM5, there is no auxiliary file to be input with the WRF model output ("wrfout") file because all of the required input fields are contained in this file as long as the fields are selected to be part of the history file via the WRF Registry.
The WRF model fields must originate from WRFv2.0 or newer; earlier versions of the WRF model are now obsolete.The WRF model output fields must be from simulations that use that Eulerian mass core; beginning with WRFv3.0, the other dynamics options within WRF-ARW were removed.The WRF model output must be in the netCDF-based input/output applications programming interface (I/O API) format, which is the default.For WRF fields prior to v3.0 (when this was an option), the non-hydrostatic dynamics option must be used for the simulations because the internal equations in MCIP that compute the vertical velocity are developed from the non-hydrostatic WRF model equations.WRF model output must be captured hourly, at most, because the CTM expects meteorological fields resolved at no coarser than hourly temporal spacing.
Most of the microphysics schemes that are available in the WRF model are compatible with CMAQ.The hydrometeor species must be delineated into at least two components (cloud water mixing ratio and rain water mixing ratio) to be used properly in the CTM.Microphysics schemes that predict mixed-phase hydrometeors (i.e., also including ice and snow mixing ratios) and graupel can also be used by the CTM and properly processed by MCIP.However, the Ferrier microphysics scheme, which only generates a single lumped hydrometeor output field, cannot be used with the CTM, and it is rejected by MCIP; an algorithm to partition the hydrometeors from the Ferrier scheme may be considered for implementation into MCIP at a later time.
To maximize the consistency between the meteorological model and CTM, particularly in an offline modeling system where there is no feedback from the air quality to the meteorology, it is desirable to use the same model algorithms to describe PBL processes.Using the Asymmetric Convective Model version 2 (ACM2) (Pleim, 2007a, b) for the PBL in WRF is advantageous because the ACM2 is the default PBL scheme to compute stability and vertical mixing in the CTM.In cases where other PBL models are used in WRF, MCIP includes algorithms to compute PBL heights and nearsurface fields that are required for the CTM.One additional caveat regarding PBL schemes in WRF is that higher-order PBL schemes (e.g., with prognostic turbulent kinetic energy, TKE) can be processed by MCIP so that the TKE field is passed on to the CTM.However, modifications to the CTM would be required so that the TKE field can be used and the PBL processes are better reflected.
As with MM5, using the Pleim-Xiu LSM in the WRF model is useful to couple with the CTM because many of the internal calculations of dry deposition velocities are tailored to fields that originate from that scheme.Using the Pleim-Xiu LSM is not a requirement; fields from any LSM in WRF can be accepted in MCIP.In fact, additional work in MCIP has been done recently to better link with the NOAH LSM (Chen and Dudhia, 2001).However, additional modifications can be introduced in MCIP to improve the coupling with fields from the NOAH LSM and from other LSMs.
In the current MCIP release, the urban model in WRF has only been minimally linked to the CTM.Additional modifications to the CTM would be required to properly treat the mixing and near-surface fields from WRF in the CTM.In addition, a linkage with the urban canopy model, which is new in WRFv3.1 (released April 2009) and can include prognostic model layers within the urban canopy and much closer to the ground, will require greater testing in MCIP and through the CTM before it could be publically released.

User input
MCIP is designed to minimize the required user input and determine as much information as possible from the incoming data set to reduce the potential for user errors.In addition, MCIP accepts all data-specific changes as run-time modifications to the software (which is dynamically allocatable, where appropriate) so that one executable can apply the same scientific calculations to an unlimited number of gridded domains over various spatial and temporal intervals with multiple sources of meteorological model input.The input meteorological model (currently either MM5 or WRF-ARW) is determined by reading the input fields at run time.The types of user input that can be provided are partitioned into three categories: file names and locations, run control definitions, and grid subset (i.e., "window") definitions.All other information related to the meteorological model fields (including geospatial information and availability of various fields due to changes in physics options) is dynamically determined at run time in MCIP from the input meteorological files.
The user input is read into MCIP via Fortran "namelists" (currently "filenames", "userdefs", and "windowdefs"; see Table 1).Two properties of Fortran namelists are that the variables in a particular namelist can be in any order, and not all of the variables that are part of the namelist need to be specified.In MCIP, there are currently 23 user-definable fields.However, only four of the run-time variables are required: the input meteorological file names ("file mm"), the start and end dates for MCIP processing ("mcip start" and "mcip end"), and the meteorological processing interval ("intvl").The latter of the required input variables can be used to create MCIP output at a coarser temporal frequency than the input meteorological fields; this can be particularly helpful for testing sensitivities to the temporal interval of meteorological fields in the CTM.The remaining fields have reasonable default values associated with them.

Derived fields
It is well-known that mass conservation is a very important property in CTMs such as the air quality component of CMAQ (e.g., Byun, 1999;Jöckel et al., 2001;Stohl et al., 2004;Lee et al., 2004).In order to maintain mass consistency in the meteorological fields for chemical transport, the continuity equation in the CMAQ modeling system is cast in terms of a Jacobian-weighted density.Thus the transport is accomplished with species and atmospheric fields coupled with a vertical Jacobian (for vertical coordinate transformation) and density, and scaled by the map-scale factor to adjust www.geosci-model-dev.net/3/243/2010/Geosci.Model Dev., 3, 243-256, 2010 for the grid-cell volume.Byun (1999) provides a detailed description of the governing equations and the importance of the Jacobian and density as they apply to the CMAQ modeling system.The Jacobian and density are not included in the suite of meteorological output fields from models such as MM5 and WRF.However, it is important that these fields (and particularly the Jacobian) be derived carefully and with respect to the input model's governing equations and vertical coordinate.The computation of the derived fields, such as the density and Jacobian, occurs in MCIP for the CMAQ modeling system.In addition, the vertical velocity in the generalized coordinate system is reconstructed to conserve mass, and it is provided as part of the MCIP output.Byun (1999) provides general guidance on computing these derived fields for common vertical coordinate systems in Eulerian meteorological modeling.The following sections briefly describe the details of the calculations of the density, Jacobian, and contravariant vertical velocity (i.e., the transformed vertical velocity in CMAQ's generalized coordinate system) for MM5 and WRF-ARW.

MM5v3
MCIP is currently set up to process fields from MM5v3.The processing of MM5v2 fields, which included different dy-namic assumptions and a different vertical coordinate, was removed in MCIP version 3.3 (released in 2007).The assumptions and computations for MM5v2 fields are covered in Byun et al. (1999), and the following equations only apply to MM5v3 which could be processed using the public release of MCIP starting in 2001.
The state equations in the non-hydrostatic MM5v3 (Grell et al., 1994) are based on a constant reference state and perturbations from that state: where α represents the pressure, temperature, or density in space and time; α 0 is the reference state, which is a function only of the vertical; and α is the local perturbation in space and time.
Although density is one of the base variables in MM5v3, it is not part of the output suite in the model, and it must be computed in MCIP for the CTM.The density for MM5v3 data sets, ρ MM5 , is computed in MCIP using the ideal gas law: where P 0 is the base-state (or reference) pressure, P is the pressure deviation from the base-state (or perturbation) pressure, R d is the dry gas constant, and T v is the virtual temperature.In this density calculation in MCIP, R d is set to the value that is used in MM5, 287.04 J kg −1 K −1 , to allow the density used in the CTM to most closely reflect the actual values from MM5.The vertical coordinate in MM5v3, σ , is time-invariant, terrain-following, and a function of the reference pressure: where P t is the pressure at the top of the model, P s (x,y) is the surface pressure, and P * 0 (x,y) is the pressure in the model's column.
The Jacobian, J MM5 , for MM5v3's vertical coordinate is: where P * 0 (x,y) is as defined above, g is the gravitational constant (set to 9.81 m s −2 to match the value used in MM5), and ρ 0 (z) is the reference density.In this vertical coordinate from MM5v3, J MM5 is time-invariant but spatially varying, and ρ J MM5 , which is coupled with the species for temporal interpolation in the CTM, is temporally varying.
The contravariant vertical velocity, ξ , which is used in the CTM for mass conservation, is computed in MCIP based on the vertical coordinate of the incoming meteorological model.For MM5v3, the contravariant vertical velocity is: where u and v are the horizontal wind components interpolated to the scalar points (see Fig. 2) and to layer interfaces, w is the vertical component of the wind, and m is the mapscale factor.A more complete explanation of this calculation can be found in Byun et al. (1999).

WRF-ARW
The vertical coordinate in the WRF-ARW core (hereafter, WRF) is terrain-following, based on dry hydrostatic pressure, and alternatively called a mass coordinate: In Eq. ( 6), p h is the hydrostatic component of pressure, and the other terms are analogous to the terms in Eq. ( 3), except that the basic form uses the hydrostatic pressure rather than a reference pressure.The denominator of Eq. ( 6) is the mass of dry air in the column, µ d .Unlike in MM5v3, the WRF vertical coordinate, η, is time-varying, so the layer heights in the CTM also change as a function of both time and space.
The prognostic equations in WRF can be cast in terms of a reference state (which is in hydrostatic balance) and a perturbation from that state: where β represents total pressure, geopotential, or inverse dry density; β and μd denote reference values; and β and µ d are local perturbations in space and time.
While inverse density can be output from WRF via the Registry file, the density and its components are not part of the WRF history file as a default.Therefore, it is advantageous to compute density within MCIP using the appropriate fields from the default WRF output rather than insist that users modify WRF to generate additional three-dimensional output fields.The density for WRF, ρ WRF , is computed using the ideal gas law and using the components of the algorithm as they appear in the WRF model: where P is computed in the numerator from the reference and perturbation, T is the temperature (derived from pressure and potential temperature), R v is the moist gas constant, and q is the water vapor mixing ratio.In this density calculation in MCIP, R d and R v are set to 287.0 J kg −1 K −1 and 461.6 J kg −1 K −1 , respectively, to match the values used in WRF-ARW.The inverse of the results from Eq. ( 9) were compared to having inverse density directly output in the WRF history file, and this reconstruction of density was consistent to six decimal places (or machine precision).
Because WRF-ARW is based on a mass-conserving set of equations, the Jacobian, J WRF , could easily be computed from one of the WRF-ARW state equations: where φ is the total geopotential, and α d is the inverse dry density (i.e., ρ −1 WRF ).Using the definition of the Jacobian and combining that with Eq. (10), For WRF-ARW-based meteorological fields, the Jacobian is time-varying, and ρ J WRF is constant through the column because µ d g does not have a vertical dependency.The contravariant vertical velocity, ξ , which is used in the CTM for mass conservation, is computed in MCIP based on the vertical coordinate of the incoming meteorological model.For WRF-ARW, the contravariant vertical velocity, ξ , is estimated from the standard coordinate transformation given in Byun et al. (1999): www.geosci-model-dev.net/3/243/2010/Geosci.Model Dev., 3,[243][244][245][246][247][248][249][250][251][252][253][254][255][256]2010 where ξ = 1 − η is the generalized vertical coordinate in the CTM based on the WRF coordinate, V ξ is the horizontal wind vector on the prognostic layers, and h T is the height of the prognostic layer.Specifically for WRF-ARW, the first term on the right-hand side drops out of Eq. ( 13) because the values of ξ , which range between 1 and 0, are time-invariant.Adapting Eq. ( 13) for WRF reduces to: This formulation for the contravariant vertical velocity is included in the MCIP output and coupled with ρ J WRF , and it can be used directly for vertical transport in the CTM for certain advection schemes.

Internal scientific computations
Two of the primary scientific objectives in MCIP are to minimize the calculations of atmospheric fields and to use the input meteorological fields in as pure of a form as possible to maintain consistency between the meteorological and air quality models.However, there are some atmospheric fields that are particularly relevant to air quality modeling in addition to those described in Sect.4, and it is impractical to require all meteorological model users to generate such specialized fields.Therefore, in some circumstances it is necessary to augment the meteorological model output fields with using internal algorithms in MCIP.

Cloud fields
It is uncommon for meteorological models to generate the full suite of specific cloud and moisture fields that are required as input for the CTM.Therefore, MCIP is used to diagnose some additional cloud-related fields from meteorological state variables for use in the CTM.MCIP diagnoses for each horizontal grid cell the cloud coverage, cloud base and top, and the average liquid water content in the cloud using a series of simple algorithms based on a relative humidity threshold.These cloud algorithms are described in detail in Byun et al. (1999).The MCIP-derived cloud fields are then used in the CTM for photolysis calculations.

Supplemental PBL fields
The CTM requires several near-surface fields, many of which are now routinely available in MM5 and WRF output files.However, MCIP is designed to fill in the gaps when all of the required data are not available.Some of the fields that can be computed, if necessary, in MCIP are Monin-Obukhov length, PBL heights (particularly if they are not defined under the stable regime or if the values are less than the height of the lowest model layer), 2-m temperatures and 10-m wind components, and the convective velocity scale.Some of these near-surface fields are also used in the emissions processing for plume-rise calculations, biogenic emissions calculations, and temperature-dependent emissions from mobile sources.Others are used in the CTM for the near-surface vertical mixing and for the dry deposition velocity calculations (see Sect. 5.3) and to characterize the evolution of the PBL.

Dry deposition velocities
Chemical dry deposition velocities can be computed in MCIP using the "M3Dry" model.M3Dry uses an electrical resistance analog model (Pleim et al., 2001).Where possible, the atmospheric and boundary layer resistances are used directly from the meteorological model; otherwise those resistances are estimated from the meteorological model's atmospheric near-surface fields and surface-layer parameters (e.g., friction velocity, Monin-Obukhov length).Canopy resistance is a parallel combination of surface resistances (leaf cuticle and ground) and stomatal resistance.Surfaces resistances are scaled by solubility and chemical reactivity of each chemical species.
The algorithms in M3Dry make use of surface and surfacelayer parameters generated by an LSM within the meteorological model, if available, such as leaf-area index, fractional vegetation coverage, canopy water content, bulk stomatal conductance, aerodynamic conductance, and roughness length.This ensures consistent treatment of meteorological (heat and moisture) and chemical surface fluxes and simplifies the dry deposition calculations.Also, when the Pleim-Xiu LSM is used in MM5 or WRF, surface flux errors can be controlled by a soil moisture indirect nudging scheme (Pleim and Xiu, 2003).Thus, the resulting bulk stomatal conductance should be more accurate than a stand-alone parameterization, which should result in more accurate estimates of dry deposition of chemical species that have a significant stomatal deposition pathway.
Although recommended, using the Pleim-Xiu LSM in the meteorological model is not required for MCIP or the CTM.When near-surface fields are unavailable in the meteorological model output, they are calculated internally in MCIP; however, the algorithms are likely to be unrelated to the LSM and other parameterizations in the meteorological model, which can result in an additional source of inconsistency.As of the current release of MCIP, some preliminary connections have also been made in MCIP to tailor M3Dry for use with the NOAH LSM, particularly for WRF, because the NOAH LSM is more commonly used throughout the WRF modeling community.Additional work is needed in MCIP, particularly in M3Dry, to be fully consistent with NOAH LSM fields when they are available.In general, it is recommended that modifications be introduced into MCIP to adapt the M3Dry model for the fields that are available from and the algorithms that are part of whichever LSM was used in the meteorological model.
Computation of the dry deposition velocities for the CMAQ system has historically been a part of MCIP because of the access to the relevant meteorological fields.However, because of the need to compute bidirectional fluxes of some chemical species (e.g., ammonia and mercury) the dry deposition velocity calculations are being transferred into the CTM.Starting with CMAQv4.7 (released in December 2008), the chemical dry deposition velocities can be computed within the CTM, and all of the necessary meteorological fields are now either directly output by MCIP or can be derived in the CTM.

Using satellite observations for photolysis
A fairly new user option in MCIP is to ingest fields from the Geostationary Operational Environmental Satellite (GOES) to adjust the clear-sky photolysis rates in CMAQ following Pour-Biazar et al. (2007).In this method, the cloud information that is derived from meteorological model output is replaced with the satellite observations from GOES in MCIP.When and where GOES observations are available, MCIP outputs the GOES-based (observed) cloud fraction.The GOES cloud top temperature is used to identify the cloud top.The surface temperature and mixing ratio from the meteorological model are used to calculate the lifting condensation level, which becomes the cloud base height.When the GOES cloud processing option is invoked in MCIP, the GOES-based cloud properties are used directly in the calculation of the photolysis rates in the CTM.At time periods and at locations where GOES data are not available, the cloud fields are prescribed using the default method (Sect.5.1).
Currently the option to use satellite processing in MCIP requires additional preprocessing software and data sets that are freely available from and maintained by the University of Alabama at Huntsville (see http://satdas.nsstc.nasa.gov).The satellite processing is currently also restricted to GOES-East (i.e., the eastern United States), and it has only been adapted for fields from MM5 at this time; a future release of MCIP may include the adaptations to the WRF model.In addition, the use of the satellite observations in MCIP for CMAQ can create inconsistencies in the representation of clouds with respect to the dynamic fields simulated by MM5 (e.g., temperature, precipitation, humidity).

Geospatial and meteorological output
MCIP creates several output files that are used as part of the downstream processing in the emissions and the CTM.Most of the MCIP output files are created using the Models-3/Environmental Design Support System (EDSS) I/O API, which is available freely from http://www.baronams.com/products/ioapi and distributed under the GNU General Public License and the GNU Lesser General Public License.The Models-3/EDSS I/O API typically builds its data and meta-data using network Common Data Form (netCDF) structures, and it is the file format that is common to the CMAQ modeling system as well as the Multiscale Air Quality Simulation Platform (MAQSIP) (Mathur et al., 2005).By using netCDF as an underlying format in the I/O API, the MCIP files can generally be used in the suite of post-processing and visualization routines that are built on the netCDF.It should be noted that the Models-3/EDSS I/O API is a different format than the WRF I/O API, even though both are built upon netCDF.
As of the current release of MCIP, there can be up to eight output files in Models-3/EDSS I/O API format (see Table 2).Each file includes fields that have common temporal, horizontal, and vertical dimensions, and each file name contains three parts to represent each of those components, respectively.Not all of the output files listed in Table 2 are generated for each input meteorological model.
Another file that is generated by MCIP is a text-based grid description file ("GRIDDESC") that is used to communicate domain and projection parameters to other elements of the CMAQ modeling system that use the I/O API.In addition, the text-based "mmheader" file (which contains the MM5v3 user options) is generated by MCIP when MM5v3 fields are processed in MCIP, largely because MM5v3 is stored in its own independent binary format.However, "mmheader" is not generated for files from the WRF model because those files are written in an independent I/O API that is also built on netCDF, and the header information (i.e., user options within the WRF model simulation) can easily be accessed using the netCDF utility command "ncdump".A final output file from MCIP is a text-based log file that contains some background information about the MCIP run, including which internal options were used (i.e., whether certain variables were found in the meteorological model output or if those fields were computed internally in MCIP), as well as a sample of the input and output fields for a user-defined grid cell.
MCIP creates a standard suite of static, time-invariant (Table 3) and dynamic, time-varying (Table 4) output fields.In addition, some optional output fields that can enhance the scientific computations in the air quality model are generated if there are enough supporting data in the meteorological model output files to make them available.For example, if fractional land use data are part of the meteorological model output, they are processed in MCIP and provided to the CTM to enhance the estimation of nocturnal vertical mixing in urban areas and to contribute more specificity to the calculation of bidirectional surface fluxes of various species.Likewise, the number of dynamic hydrometeor species provided in the MCIP output is a function of the explicit moist physics scheme used in the input meteorological model, and CMAQ is designed to use the available hydrometeors.Similarly, cloud transmissivity is only included in the MCIP output when the user option for processing GOES-East fields (refer to Sect.5.4) is employed.Metadata that describe the input meteorological data source are also part of the MCIP output files as of MCIP version 3.3 (released in 2007).These metadata improve traceability of input meteorological fields, including which version of MCIP was used to create the files, which meteorological model and version (e.g., MM5v3.7.4 or WRFv3.0.1) provided the input data, the initial time for the meteorological model simulation, the physics and data assimilation options used in the meteorological model, source of land use data, and other information regarding the input fields that otherwise could not be extracted from viewing the MCIP output alone.These metadata, which are part of the I/O API header of the MCIP output files, can be particularly helpful in determining the lineage of the MCIP files, as well as to distinguish MCIP files that are by-products of sensitivity testing of various meteorological model options in the CMAQ modeling system.

Program distribution and technical support
MCIP is part of the community-based CMAQ modeling system.The CMAQ user community includes several Federal and state agencies with regulatory authority over environmental concerns in the United States, private institutions, and various research institutions world-wide (see Fig. 1).As in many other modeling systems, the CMAQ system (including MCIP) is undergoing continuous development to keep pace  Formal support for MCIP is also provided by the CMAS Center.Training on the use of MCIP is part of the comprehensive CMAQ system training that is offered in-residence or on-site for a fee by the CMAS Center.Community support and trouble-shooting problems with MCIP is accomplished in a variety of mechanisms including the interactive user e-mail distribution for the Models-3 Technical Support Forum ("m3user") at University of North Carolina at Chapel Hill, the on-line software bug reporting management site ("bugzilla"), and through direct contact with the software developers.As a result of continued user feedback on MCIP and the needs of the CMAQ user community, the quality and robustness of MCIP have improved in each public release.

Program extensions
The core software from MCIP has been used directly or adapted in several other air quality modeling applications to either (1) link another meteorological model to the CMAQ modeling system, or (2) link MM5 or the WRF model fields to another CTM.Some of the extensions of MCIP in other air quality applications include: -Linking the Eta Model (Black, 1994) with the CTM using the preprocessor to CMAQ ("PREMAQ") for the United States' twice-daily operational National Air Quality Forecasting Capability (NAQFC) (Otte et al., 2005).The core of PREMAQ (including many of the internal calculations and the output functions) is based on MCIP.PREMAQ was tailored to the Eta Model for the file formats, output fields, and horizontal and vertical grids.
-Linking the WRF-NMM (Janjic et al., 2001) to CMAQ with PREMAQ for the NAQFC (Lee et al., 2007) where the operational WRF-NMM was interpolated to a Lambert conformal domain prior to PREMAQ processing.As in the Eta Model linkage using PREMAQ, the core of the PREMAQ code originated from MCIP, and PRE-MAQ was tailored for the WRF-NMM analogously to the changes in the vertical grid structure that were required for the Eta Model.Because the operational WRF-NMM fields were interpolated from their native latitude-longitude grid to be ingested by PREMAQ, this precludes the adaptation of this instantiation of PRE-MAQ into MCIP for community distribution.
-Linking the WRF-NMM in its raw form (rotated latitude-longitude domain and Arakawa E staggering; see Fig. 2) with the CTM in the WRF-CMAQ Interface Processor (WCIP) (Byun et al., 2006).WCIP was developed using MCIP as baseline software that was modified for the WRF-NMM gridding and mapping systems.Substantial changes are also required to the CTM to adapt to the WRF-NMM gridding and mapping, so the changes in WCIP have not been included in the community releases of MCIP and CMAQ.
-MCIP was modified and adapted to use internal WRF fields as part of a two-way ("online") coupled WRF-CMAQ model (Pleim et al., 2008).In the online model, feedbacks occur from the CTM to WRF, and there is no need for an intermediate MCIP step.However, there is still a need to translate meteorological fields and develop the diagnostic fields that are required for coordinate transformations, so MCIP was reduced to a suite of tailored subroutines that are inserted into WRF.That adaptation of MCIP as "aqprep" will be made publically available in 2011 as part of a major update to the CMAQ system.
-MCIP was used "as is" to provide input to National Research Council -Canada's Modular Air Quality Model (MAQM) (Jiang et al., 2008).MAQM is another stateof-the-science Eulerian air quality modeling system.
-MCIP was adapted to process fields from Environment Canada's Global Environmental Multiscale (GEM) model (Côté et al., 1998) for use in CMAQ (Smyth et al., 2006).Changes to MCIP to support GEM were not contributed back to the CMAQ developers for inclusion in the released code.
-MCIP was modified to link the Regional Atmospheric Modeling System (RAMS) (Pielke et al., 1992) to CMAQ (Sugata et al., 2000).These changes included modifying the RAMS postprocessor in addition to modifying MCIP.Because the linkage with RAMS involved modifications to upstream codes that are outside the CMAQ system, these modifications were not included in the community release of MCIP.
Several other linkages that use MCIP directly to link other international meteorological models to CMAQ have also been discussed but have not been published.There are places in the MCIP software that are designated for extensions to additional meteorological models, if desired.Community-based contributions to and extensions of using MCIP to couple with other meteorological models are welcomed.

Future outlook
The CMAQ modeling system is a dynamic and evolving air quality modeling system that is under continuous development to reflect the state of the science and expanding applications.As MCIP is a key component of that system, it, too, must adapt to the state-of-the-science.For example, the dry deposition velocity calculations that have been included in MCIP since the CMAQ modeling system was publically released are being transitioned to the CTM to facilitate and further scientific development.While it has been convenient to include those calculations in MCIP as preprocessing for the CTM, it has become necessary to compute dry deposition velocities in conjunction with dry evasion (or emissions) for some species (e.g., ammonia and mercury) in a more comprehensive bidirectional surface flux algorithm.Hence, those calculations will be removed from MCIP in the next major release.
In addition, as new science is added to the WRF model, MCIP must be modified to adapt to those changes.Additional output fields may be created with new science modules, and those fields should be considered for use in the CTM, as appropriate.For example, the urban model in WRF creates additional near-surface fields that could be relevant for defining the atmospheric states in the urban zones with finer granularity, and special treatment of those fields in MCIP and the CTM would be warranted.Advances in some of the existing options in WRF (e.g., the Pleim-Xiu LSM) may induce analogous changes in the MCIP to keep the meteorological fields consistent in the CTM.Additional land use classification schemes, such as the National Land Cover Database (NLCD), are being introduced into WRF, and modifications to properly process fields from alternate databases will be needed in MCIP.
Lastly, additional changes to MCIP are introduced as warranted by the CMAQ user community.Corrections and minor modifications to the software are made when problems are found (either by the developers or the users).Extended capabilities in MCIP are considered when they are contributed by the user community, e.g., the satellite processing option (Sect.5.4).Currently there is no formal process by which suggestions and extensions are submitted and/or approved; it is entirely ad hoc between the users and the developers.Approval for the user-requested changes is based on the developers' priorities, the level-of-effort required for implementation, the potential applicability throughout the user community, as well as the scientific credibility of the suggestions.As with any community model, suggestions and contributions from the user community for MCIP are always welcomed by the US EPA for consideration and inclusion in future releases of the software package.

Fig. 1 .
Fig. 1.Number of users registered with the Community Modeling and Analysis System (CMAS) Center (by country) as of Fall 2008.Image courtesy of the CMAS Center.

Table 2 .
Files that are output by MCIP.The relative locations of the fields can be obtained from Fig. 2a (dot points and cross points) and Fig. 2b (cell faces and cross points).time-invariant fields at cell centers ("cross" points) I/O API GRIDCRO3D a 3-D time-invariant fields at cell centers ("cross" points) time-varying fields at cell corners ("dot" points) and on cell faces I/O API GRIDDESC Grid description (projection, size, grid spacing) Text mmheader a Contents of MM5 header Text mcip.logFeedback to the screen from MCIP execution Text a Files are only created for MM5-based input fields.

Table 1 .
User-definable run-time input for MCIP.Reasonable default values are provided in MCIP for all variables except the input file names ("file mm"), the start and end times ("mcip start" and "mcip end"), and the processing interval ("intvl").
windowdefs Row coordinate of lower-left corner of cropped domain ncolsin windowdefs Number of columns in cropped domain (i.e., window) nrowsin windowdefs Number of rows in cropped domain (i.e., window)

Table 3 .
Time-invariant fields that are output by MCIP.Only output if fractional land use fields are provided in the meteorological input file.b Output for XX land use categories from 01 to NN, where NN is the number of categories in the classification system used by the meteorological model.c Only output for models with time-invariant reference layer heights (e.g., currently only for MM5 and not WRF). a

Table 4 .
Time-varying fields that are output by MCIP.
state-of-the-science and its evolving applications.Prior to 2002, the US Environmental Protection Agency (EPA) developed, released, maintained, and supported all of the elements of the CMAQ system.Since 2002, the Community Modeling and Analysis System (CMAS) Center (www.cmascenter.org)has formally released the CMAQ system (including MCIP) to the user community.The primary development of CMAQ (including MCIP) is the responsibility of the US EPA.MCIP releases to the community are not necessarily coupled to CMAQ releases except when there are synergistic scientific updates between the software packages.MCIP is typically released on an annual basis or whenever significant changes are warranted (e.g., to adapt to changes in the input meteorological models).Minor releases to correct software errors or to extend capabilities also occur at nonstandard intervals.Most of the formal testing of the MCIP releases is typically performed by the developers.However, experienced CMAQ users have been invited to participate in beta-testing of MCIP for major software updates.(Beta testing opportunities are open to any users who express interest in participating in the process and getting a first look at the upcoming changes to the software.)MCIP can be freely downloaded from the CMAS Center.The most recent release, MCIP version 3.4.1,was made available in December 2008 as companion software with the CMAQv4.7 package.
a Only output if fields are available from land-surface model in input meteorological model fields.b Only output if satellite data processing is invoked (requires US domain and additional software from University of Alabama at Huntsville).c Optional output controlled by run-time user option that generates fields for 31 species.d Only available if output by meteorological model.www.geosci-model-dev.net/3/243/2010/Geosci.Model Dev., 3, 243-256, 2010 with the