I have some concerns about the vertical resolution of CMAQ.
Is there a recommended value for the first layer of CMAQ model?
Or, is there any value that is not recommended to use?
I searched in several articles for the first height adopted for the models, but most articles only report the amount of Eta levels used.
Does anyone have suggestions about best practices in defining the first vertical layer height, especially for population exposure assessment?
Thank you in advance.
Your vertical layering should match that used by your WRF runs. That being said, meteorologists are often less interested in what happens at or near the surface (and are using simplifications for the surface interaction, anyway), and so frequently use fewer layers than they ought to use for near-surface transport etc. You’d do better, I think, if you used layers of thickness 20-30 M for the first 200-300 meters of modeled atmosphere (but at the cost of added compute-time and data-storage, of course.)
Be aware that the available met models “do violence” to the underlying terrain, frequently by 3DX or 5DX smoothing. 3*DX smoothing with DX=15KM, by the way, leads to terrain-height errors as large as 300 meters in Appalachia, with corresponding errors in surface temperature, etc.
Of course, I think you could improve this situation by adding a good sub-grid scale parameterization for terrain height into the relevant air quality model processes – especially emissions and dry deposition. Doing so (again at 15KM) saw local changes to O3 as large as 10 PPB, as I documented two decades ago.
Thank you very much for your explanation. I was concerning about that, because I did some simulations assuming the first layer with a height of 4 meters. I had successful runs, with good-reasonable well agreement with observations. However, most articles adopt 20 meters or more, then I started to think that what I did it was a problem regarding the CMAQ performance.
Unless you are using an urban canopy and/or vegetation canopy parameterization, you may have problems with a 4-m first layer depth (even if your statistics appear to be improved). You need to be careful using very thin layers near the ground because the layers will start intersecting with trees and buildings, depending on the location of your domain. In that scenario, you are introducing roughness elements that compete with the roughness length that is assumed for each land use type. In addition, you may introduce errors into the calculations of the 2-m temperature and mixing ratio and the 10-m wind speed and direction because (I believe) most of the routines assume that the mid-point of your lowest layer is near or above 10 meters.
There is no real guidance on first layer thickness or number of layers; most of that is driven by the application, as well as balancing your computational needs. For example, if you are interested in long-range transport and stratospheric-tropospheric exchanges, then you may need a higher model top and more layers (and thinner layers) near the tropopause. If you are primarily interested in population exposure, you may compromise some of the depth of the layers aloft to increase the resolution near the surface. Typically we use 35-45 layers for our different simulations here. I agree with @cjcoats that you want to use a layer configuration in CMAQ that matches what you use in WRF, and CMAQ (via MCIPv5.0+) now restricts you to use the same vertical layer structure that was used in WRF. Our typical first layer is about 20 m (10 m mid-layer) or 40 m (20 m mid-layer), depending on the application.
As an aside, I disagree with @cjcoats statement that “meteorologists are often less interested in what happens at or near the surface”–that is simply not true. Obviously we make forecasts for the people, and the people live near the surface. In addition, the notion that “met models ‘do violence’ to the underlying terrain” is a bit harsh and misleading. Yes, the terrain in the model will differ from the actual values as a result of smoothing, but that smoothing is necessary to maintain stability in the advection equations used in the met models for terrain-following surfaces. You may explore how to compensate for that, but we have accepted that these differences exist and that we probably have bigger issues to address more immediately.
Terrain-smoothing leads to systematic surface-temperature errors which then cause errors in, e.g., biogenic emissions.
Met models (e.g., ECMWF) that use a 3-D surface drag formulation instead of surface similarity based on roughness length regularly show more skill than the alternatives; however, they are not available to us for air quality work. Absent that, there are a number of processes that show improvement when one introduces a sub-grid scale terrain parameterization into the air quality model.
Dear Tanya and Carlie,
Thank you very much for your explanation
That was very enlightening and helpful
I thought my questions would be related to the question raised here. In case the vertical grids of different CMAQ input files are not matched, what tool is recommended to convert the 42 vertical layers of ancillary bi-directional ammonia flux files (needed for input into CMAQ) to match the 34 used in MCIP output files?
The 42 layers of CMAQ ancillary input file ( us1_2016_cmaq12km_time20160102) looks like this in the header:
:NLAYS = 42 ; :VGTYP = 2 ; :VGTOP = 63.f ; :VGLVLS = 0.22f, 0.23f, 0.24f, 0.25f, 0.26f, 0.27f, 0.28f, 0.29f, 0.3f, 0.31f, 0.32f, 0.33f, 0.34f, 0.35f, 0.36f, 0.37f, 0.38f, 0.39f, 0.4f, 0.41f, 0.42f, 0.43f, 0.44f, 0.45f, 0.46f, 0.47f, 0.48f, 0.49f, 0.5f, 0.51f, 0.52f, 0.53f, 0.54f, 0.55f, 0.56f, 0.57f, 0.58f, 0.59f, 0.6f, 0.61f, 0.62f, 0.63f, 1.f ;
and the 34 layers of MCIP output look like this:
:NLAYS = 34 ; :VGTYP = 7 ; :VGTOP = 5000.f ; :VGLVLS = 1.f, 0.995f, 0.989f, 0.983f, 0.976f, 0.968f, 0.959f, 0.95f, 0.94f, 0.929f, 0.916f, 0.902f, 0.887f, 0.871f, 0.853f, 0.833f, 0.811f, 0.787f, 0.76f, 0.731f, 0.699f, 0.663f, 0.624f, 0.581f, 0.534f, 0.482f, 0.429f, 0.375f, 0.322f, 0.268f, 0.214f, 0.161f, 0.107f, 0.054f, 0.f ;
I see the VGTYP are also different in the two, and I wasn’t sure which I/O API command to use for this purpose?
As @cgnolte said, these are the E2C_CHEM files which contain EPIC information needed by CMAQ when using the bi-directional NH3 flux option. The “layers” in these E2C_CHEM files represent the 42 crop types (21 different crops x 2 for rainfed vs. irrigrated) used by EPIC driven through FEST-C, not atmospheric layers. Therefore, you should not attempt to interpolate the E2C_CHEM “layers” to the vertical layers used in MCIP.
The 21 crops are “HAY”, “ALFALFA”, “OTHER_GRASS”, “BARLEY”, “EBEANS”, “CORNG”, “CORNS”, “COTTON”, “OATS”, “PEANUTS”, “POTATOES”, “RICE”, “RYE”, “SORGHUMG”, “SORGHUMS”, “SOYBEANS”, “SWHEAT”, “WWHEAT”, “OTHER_CROP”, “CANOLA”, “BEANS”.
Just out of curiosity, is there any vertical layer interpolation tool for CMAQ input/output files?
Not that will be useful in this case. However, you may find the source codes useful for developing your own:
There is M3Tools program presterp to interpolate from MM5 nonhydrostatic sigma-levels to pressure-levels (see https://cjcoats.github.io/ioapi/PRESTERP.html). However, it requires file
PRES_CRO_3D as input; this file comes from the MM5 I/O API module
MCPL (see https://cjcoats.github.io/ioapi/MCPL.html) rather than EPA’s MCIP ;-( The MMP* routines in that module can serve as examples of such interpolation-code, if you wish.