Get the output of MCIP without reducing dimension?

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 2BTRIM + 2NTHIK + 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, but I can’t find a solution.
Thank you.

Best regards,
Gwang-Jin

@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

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

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.

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)

@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

1 Like

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), 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] 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…

1 Like

@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)

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

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.

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 (218.4 KB)
GRIDDESC.txt (200 Bytes)

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.

1 Like

Thank you for kind explanations and enabling me to use m3cple. I’ve obtained the extended and layered point emission.