# Get the output of MCIP without reducing dimension? **URL:** \ **Category:** MCIP\ **Created:** [March 9, 2022, 9:12am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088 "2022-03-09T09:12:12Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![gwangjin](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/gwangjin/32/1336_2.png) [@gwangjin](https://forum.cmascenter.org/u/gwangjin)\ **Post date:** [March 9, 2022, 9:12am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/1 "2022-03-09T09:12:12Z")
Hello, I am using WRF-Chem model. To obtain 3D layered point emission, I have to input meteorological data to SMOKE. I ran MCIP with my WRF output for SMOKE input. And I found that the output MCIP domain dimensions are reduced by 2_BTRIM + 2_NTHIK + 1 (I set BTRIM = 0). Then the output SMOKE dimensions cannot match with the input WRF dimensions of nested domains. This is my problem. Is there any way to get the output of MCIP without reducing dimension? I read [https://forum.cmascenter.org/t/can-mcip-generate-same-domain-row-and-column-but-not-reduced-wrf-domain/2236](https://forum.cmascenter.org/t/can-mcip-generate-same-domain-row-and-column-but-not-reduced-wrf-domain/2236), but I can’t find a solution. Thank you. Best regards, Gwang-Jin ---
**Author:** ![tlspero](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tlspero](https://forum.cmascenter.org/u/tlspero)\ **Post date:** [March 9, 2022, 6:50pm UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/2 "2022-03-09T18:50:27Z")
@gwangjin – I think you can maximally use the WRF-Chem data with MCIP with the way you are set up (BTRIM=0), but the dimensions will differ because of the methods used by WRF and SMOKE to count the dimensions. (Whether it’s a good idea to maximally use the WRF domain in SMOKE is a different conversation.) To start, the apparent reduction by 2BTRIM + 2NTHIK + 1 is going to result in a reduction of 3 when BTRIM is set to 0. NTHIK is the thickness of the boundary perimeter used in the SMOKE and CMAQ domains. While NTHIK can be flexible because of the way it is coded, in practice, NTHIK is 1. So, 2(0) + 2(1) + 1 = 3. As it turns out, by reducing the dimension by 3, you will actually use all of the WRF domain. Here is why. In WRF, the lateral boundary cells (i.e., the picture frame with boundary forcing around the perimeter of the domain) are included as part of the full domain dimensions. That is, when you visualize any of the fields on 2D horizontal surfaces, the outermost grid cells around the perimeter of the domain are boundary cells, and those cells are strongly influenced by the information in the wrf\_bdy files. Boundary-condition-influenced cells are just part of the main WRF output. However, unlike WRF, CMAQ (and SMOKE) do not include the boundary cells as part of the “main” domain dimensions. When you omit the one-cell picture frame (which is two cells in each dimension), then those data are used to populate the CMAQ boundary files. The data are still in play for CMAQ; they are just _only included in the boundary files_ rather than both the main domain and the boundary files. So that’s two of the three. What about the leftover 1? Well…in WRF, there are really two sets of dimensions in the output: the “unstaggered” and the “staggered” dimensions; you can see this with ncdump -h wrfout, and look at the netCDF dimensions and the global attributes. The “staggered” dimensions are one greater than the “unstaggered” dimensions, and the difference refers to whether you are counting with cell centers or cell faces. In a staggered grid, like the Arakawa C staggered grid used by both WRF and CMAQ, some variables are geolocated at cell centers (most mass and moisture variables), while others are on cell faces (like component winds). In SMOKE and CMAQ, the convention is to use the number of cell centers (or the smaller of the two numbers) to define the grid dimensions. In WRF, either could be used. With MCIP, I use the larger of the two numbers (the staggered number), which reflects the convention that was used by MM5 (the predecessor to WRF). For a long time, MCIP handled both MM5 and WRF data, so it was easier to keep the convention for grid sizes consistent between the models within MCIP. Hope this helps. –Tanya ---
**Author:** ![tlspero](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tlspero](https://forum.cmascenter.org/u/tlspero)\ **Post date:** [March 9, 2022, 7:05pm UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/3 "2022-03-09T19:05:22Z")
Here is a visual of the cell faces vs. cell centers with boundaries. This should illustrate where we get a difference of 3 in the dimensions. ![image](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/2X/c/c2b61e505dec752d3551ad287a9b85d38a1cf7db.png) In this simple example, the dimensions from WRF (as reflected in MCIP) would be taken from the staggered domain, so they would show up as 6 x 5 (nx x ny), where all of the green and gray cells contribute to the full domain. If the same coverage were used in SMOKE or CMAQ, then this is 3 x 2 (nx x ny), where the green cells are the main domain dimensions, and the gray cells are part of the boundaries. ---
**Author:** ![gwangjin](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/gwangjin/32/1336_2.png) [@gwangjin](https://forum.cmascenter.org/u/gwangjin)\ **Post date:** [March 14, 2022, 1:25am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/4 "2022-03-14T01:25:04Z")
Thank you for kind explanation. I understand why MCIP reduced output dimensions. If I do not use nested domains in WRF, I can simply solve the problem by extend the dimension of WRF domain by 2 in WRF namelinst.input. But for nested domains, I think it would be impossible the problem. It would be spatial non-matching problem. Is there another way to obtain layered point emission without MCIP output in SMOKE? I hope that it would be possible to get the layered point emission only with eta\_levels. Or, is it possible to merge SMOKE results obtained from different GRIDDESC? (e.g. point source with 118 x 118 and area source with 120 x 120) ---
**Author:** ![tlspero](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tlspero](https://forum.cmascenter.org/u/tlspero)\ **Post date:** [March 14, 2022, 12:48pm UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/5 "2022-03-14T12:48:12Z")
@gwangjin – I think it will depend on whether you want 118x118 or 120x120. If you want the smaller of the two domains, then you probably could use some of the m3tools to appropriately select the subset of 120x120 that overlaps with 118x118…maybe m3wndw? If you want the larger of the two domains, then you probably could also use some of the m3tools to get you to the larger of the domains, but you would assume that there are no point sources in the outer ring. I’m going to tag Carlie Coats here (@cjcoats) to see if he has any suggestions on how to proceed with your issue. –Tanya ---
**Author:** ![cjcoats](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@cjcoats](https://forum.cmascenter.org/u/cjcoats)\ **Post date:** [March 14, 2022, 3:45pm UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/6 "2022-03-14T15:45:28Z")
Getting SMOKE’s _LAYPOINT_ program to run with eta-levels is going to be problematic; I think it requires sigma-style vertical levels but that’s a B.H.Baek question. For getting full-WRF-grid I/O API output, there is M3Tools program _wrftom3_ (see [https://www.cmascenter.org/ioapi/documentation/all\_versions/html/WRFTOM3.html](https://www.cmascenter.org/ioapi/documentation/all_versions/html/WRFTOM3.html)), but I think that _LAYPOINT_ requires various “derived” variables not in a normal WRF output (and which require "halo"ed data to compute). An alternative hack is to take the _GRIDDESC_ file that comes from MCIP, use an editor to add the WRF full-grids (change the numbers of rows and columns as appropriate, and subtract the cell-size from the SW-corner `XORIG` and `YORIG` to get the full-grid SW-corner), and then run M3Tools program _m3cple_ (see [[Programs M3CPLE and M3INTERP](https://www.cmascenter.org/ioapi/documentation/all_versions/html/M3CPLE.html)] Note that _m3cple_ will “extend by constant” on the new cells – the output column-1 values will duplicate the input column-1 values, for example, which will degrade the accuracy a bit for point-sources in the full-WRF grid but not in the MCIP-output grid… ---
**Author:** ![FengLiu](https://avatars.discourse-cdn.com/v4/letter/f/49beb7/32.png) [@FengLiu](https://forum.cmascenter.org/u/FengLiu)\ **Post date:** [March 15, 2022, 7:05pm UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/7 "2022-03-15T19:05:17Z")
@gwangjin - Hi, I would suggest you use EPA\_ANTHRO\_EMIS tool that allows users to create WRF-Chem compatible hourly anthropogenic emission input files from Sparse Matrix Operator Kernel (SMOKE) Modeling System netcdf output. Please find more details at [WRF-Chem Tools for the Community | Atmospheric Chemistry Observations & Modeling (ACOM)](https://www2.acom.ucar.edu/wrf-chem/wrf-chem-tools-community) One more question for you: Your WRF outputs processed by MCIP is based on WRF runs without chemistry, and you will run WRF with turning on chemistry (WRF-Chem) again after you get emissions from SMOKE, am I right? Thanks, Feng ---
**Author:** ![gwangjin](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/gwangjin/32/1336_2.png) [@gwangjin](https://forum.cmascenter.org/u/gwangjin)\ **Post date:** [March 16, 2022, 2:57am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/8 "2022-03-16T02:57:43Z")
Yes, you are right. I think that my process is not optimal. I hope there would be a way to obtain layered 3 dimensional point emission from SMOKE without MCIP. ---
**Author:** ![gwangjin](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/gwangjin/32/1336_2.png) [@gwangjin](https://forum.cmascenter.org/u/gwangjin)\ **Post date:** [March 16, 2022, 6:00am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/9 "2022-03-16T06:00:50Z")
I would like to obtain 120x120. So I changed the numbers of rows and columns and `XORIG` and `YORG` in GRIDDESC. But when I use _m3cple_, > setenv INFILE /work/gwangjin/local/smoke\_v481/data/run\_capss2018/output/cmaq.saprc99pm/pgts3d\_l.point.20181103.4.Cheongju30\_5km.capss2018.ncf > setenv OUTFILE /work/gwangjin/local/smoke\_v481/data/run\_capss2018/output/cmaq.saprc99pm/pgts3d\_l.point.20181103.4.Cheongju30\_5km.capss2018\_out.ncf > setenv GRIDDESC /work/gwangjin/local/smoke\_v481/data/run\_capss2018/output/cmaq.saprc99pm/GRIDDESC > setenv PROMPTFLAG NO > m3cple N I obtained 118x118. > ncdump -h pgts3d\_l.point.20181103.4.Cheongju30\_5km.capss2018\_out.ncf > netcdf pgts3d\_l.point.20181103.4.Cheongju30\_5km.capss2018\_out { > dimensions: > TSTEP = UNLIMITED ; // (95 currently) > DATE-TIME = 2 ; > LAY = 17 ; > VAR = 45 ; > ROW = 118 ; > COL = 118 ; Where did I mistake? I attached my GRIDDESC and m3cple log file. Thank you. [m3cple\_log.txt](https://forum.cmascenter.org/uploads/short-url/sEwIc6OSsrXl7j86MUcMUh5haf2.txt) (218.4 KB) [GRIDDESC.txt](https://forum.cmascenter.org/uploads/short-url/cggfQt9KVVpVA9i5cg37Lh93HhT.txt) (200 Bytes) ---
**Author:** ![cjcoats](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@cjcoats](https://forum.cmascenter.org/u/cjcoats)\ **Post date:** [March 16, 2022, 10:16am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/10 "2022-03-16T10:16:07Z")
Not **change** the existing grid in `GRIDDESC`: **add** new named grids corresponding to the expanded cross and dot grids (and make sure you keep track of those names). _m3cple_ (like all of the M3Tools programs) is an **interactive** tool and needs that prompt-interaction: **_never_ set `PROMPTFLAG` to `NO` for M3Tools programs.** I wish that I had never agreed to OAQPS demand for that unneeded functionality for use in SMOKE. When you do that, you will be asked for the name of the output grid for interpolation (or (the default) `SAME` for no-interpolate): respond with the GRIDDESC-name of that new expanded grid. ---
**Author:** ![gwangjin](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/gwangjin/32/1336_2.png) [@gwangjin](https://forum.cmascenter.org/u/gwangjin)\ **Post date:** [March 17, 2022, 2:10am UTC](https://forum.cmascenter.org/t/get-the-output-of-mcip-without-reducing-dimension/3088/11 "2022-03-17T02:10:38Z")
> [@gwangjin](#): > > m3cple Thank you for kind explanations and enabling me to use `m3cple`. I’ve obtained the extended and layered point emission.