Meteorology and Emissions input to WRF-CMAQ coupled model

CMAQ CMAQ-PREP
1

I have questions relating to input for my application with WRF-CMAQ coupled model. The MCIP files in the benchmark run are set to ‘BUFFERED’ presumably to provide them as static files. For my application, it is not necessary to set to time-varying files I guess (since this is the coupled version)?

Further, I 've got emissions file, including one that has been processed as point emissions across vertical layers by SMOKE. I am unsure how to specify this in the runscript, as it appears the benchmark runscript does not envisage pre-processing of point emissions, rather prefers treating plume rise, etc. inline. Could one specify this as a second emissions file just as is done for rwc in the benchmark case (which is an area source). Would the model recognize the point emissions across layers if done this way? My point emissions are a collection of industrial sources, so not keen about various stack groups and emission stream labels.

2

See “buffered” in the I/O API manuialhttps://cjcoats.github.io/ioapi/LOGICALS.html and https://cjcoats.github.io/ioapi/BUFFERED.html#buf

3

@bambila1 -

Please also read CMAQ/CMAQ_UG_ch13_WRF-CMAQ.md at main · USEPA/CMAQ · GitHub.

In this design note that CMAQ always needs meteorological information from MCIP to drive the chemistry transport calculations. So in lieu of actual physical MCIP files on disk, CMAQ makes use of the neat “BUFFERED” file functionality in I/O API, that @cjcoats posted about, to pass meteorological information from WRF to CMAQ while the model is running. Here the MCIP files are written in memory and read by CMAQ as needed.

Optionally, the WRF-CMAQ coupled model can produce MCIP like outputs (GRIDCRO & METCRO) during the runs if requested (namelist option wrf_cmaq_option = 3). Other options do exist please see Table 13.6 of the above link posted.

As to your second question: is your emission file gridded already? If so than you certainly could specify another gridded file, but it doesn’t sound like it is…?

4

To add to @fsidi’s comment, if your point source emissions file is a 3D gridded file, you can certainly specify it as an additional gridded emissions stream by increasing N_EMIS_GR by 1 and then specifying GR_EMIS_#, GR_EMIS_LAB_#, and GR_EM_SYM_DATE_# for that file. You can freely mix 2D and 3D gridded emission input files.

5

I already have the point emissions as a 3D gridded file, so Christian’s direction should be sufficient. In that regard, is there a convention for setting the environment variable? I do not see any other place that they are called in the benchmark runscript. For example the second emissions file in the benchmark run has
setenv GR_EMIS_LAB_002 GRIDDED_RWC
setenv GR_EM_SYM_DATE_002 F

So for my case will be okay to do as follows:

setenv GR_EMIS_LAB_002 GRIDDED_PT
setenv GR_EM_SYM_DATE_002 F

?

6

Yes, that should work. The purpose of the label is to refer to this specific emission file if you want to implement any specific emission scaling instructions in the EmissCtrl file. If you don’t intend to implement any emissions scaling for this particular file, the choice of this label doesn’t really matter. Otherwise, you need to make sure the label you select matches between the run script and the EmissCtrl file for the instructions you’d like to implement.

One exception where labels matter even when using an unmodified EmissCtrl file is the section where pcSOA is “switched off” for fire emissions since it is intended to be applied only to anthropogenic sources. That section lists several commonly-used labels for fire emission streams, but if one of your input files were to contain fires but you used a custom label, you’d have to edit this section to disable pcSOA for your fire stream or you’d have to use one of the recognized labels. But since you said your point source file represents industrial sources, you probably do not want to switch off pcSOA, so any label will do in the run script.

This is the relevant section from the EmissCtrl file:

! However, the added pcSOA is probably inappropriate for Fire sources, especially
! in its current configuration. This pathway should be zeroed out for all fire
! and wood-burning related sources.
‘EVERYWHERE’, ‘PT_FIRES’ ,‘ALL’ ,‘PCVOC’ ,‘GAS’ ,0.0 ,‘MASS’,‘o’,
‘EVERYWHERE’, ‘PT_RXFIRES’ ,‘ALL’ ,‘PCVOC’ ,‘GAS’ ,0.0 ,‘MASS’,‘o’,
‘EVERYWHERE’, ‘PT_AGFIRES’ ,‘ALL’ ,‘PCVOC’ ,‘GAS’ ,0.0 ,‘MASS’,‘o’,
‘EVERYWHERE’, ‘PT_OTHFIRES’ ,‘ALL’ ,‘PCVOC’ ,‘GAS’ ,0.0 ,‘MASS’,‘o’,
‘EVERYWHERE’, ‘PT_FIRES_MXCA’,‘ALL’ ,‘PCVOC’ ,‘GAS’ ,0.0 ,‘MASS’,‘o’,
‘EVERYWHERE’, ‘GR_RES_FIRES’ ,‘ALL’ ,‘PCVOC’ ,‘GAS’ ,0.0 ,‘MASS’,‘o’,