# Meteorology and Emissions input to WRF-CMAQ coupled model

**URL:** https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279
**Category:** CMAQ-PREP
**Tags:** cmaq
**Created:** [May 24, 2022, 6:48pm UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279 "2022-05-24T18:48:55Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![bambila1](https://avatars.discourse-cdn.com/v4/letter/b/3e96dc/32.png) [@bambila1](https://forum.cmascenter.org/u/bambila1)
#### Post date: [May 24, 2022, 6:48pm UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279/1 "2022-05-24T18:48:55Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![cjcoats](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@cjcoats](https://forum.cmascenter.org/u/cjcoats)
#### Post date: [May 24, 2022, 8:30pm UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279/2 "2022-05-24T20:30:20Z")

</div>

See “buffered” in the I/O API manuial[https://cjcoats.github.io/ioapi/LOGICALS.html](https://cjcoats.github.io/ioapi/LOGICALS.html) and [https://cjcoats.github.io/ioapi/BUFFERED.html#buf](https://cjcoats.github.io/ioapi/BUFFERED.html#buf)

---

<div class="post-metadata">

### Author: ![fsidi](https://avatars.discourse-cdn.com/v4/letter/f/7feea3/32.png) [@fsidi](https://forum.cmascenter.org/u/fsidi)
#### Post date: [May 24, 2022, 8:52pm UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279/3 "2022-05-24T20:52:54Z")

</div>

@bambila1 -

Please also read [CMAQ/CMAQ\_UG\_ch13\_WRF-CMAQ.md at main · USEPA/CMAQ · GitHub](https://github.com/USEPA/CMAQ/blob/main/DOCS/Users_Guide/CMAQ_UG_ch13_WRF-CMAQ.md).

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…?

---

<div class="post-metadata">

### Author: ![hogrefe.christian](https://avatars.discourse-cdn.com/v4/letter/h/74df32/32.png) [@hogrefe.christian](https://forum.cmascenter.org/u/hogrefe.christian)
#### Post date: [May 24, 2022, 9:16pm UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279/4 "2022-05-24T21:16:56Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![bambila1](https://avatars.discourse-cdn.com/v4/letter/b/3e96dc/32.png) [@bambila1](https://forum.cmascenter.org/u/bambila1)
#### Post date: [May 24, 2022, 11:43pm UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279/5 "2022-05-24T23:43:38Z")

</div>

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

?

---

<div class="post-metadata">

### Author: ![hogrefe.christian](https://avatars.discourse-cdn.com/v4/letter/h/74df32/32.png) [@hogrefe.christian](https://forum.cmascenter.org/u/hogrefe.christian)
#### Post date: [May 25, 2022, 12:00am UTC](https://forum.cmascenter.org/t/meteorology-and-emissions-input-to-wrf-cmaq-coupled-model/3279/6 "2022-05-25T00:00:52Z")

</div>

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’,
