I am using IOAPI to regrid and interpolate MCIP files. The MCIP files are produced by processing WRF output files.
There is a problem with the land use values. Land use is an index, not a continuous parameter (like temperature for example) and when it is interpolated by IOAPI, it takes wrong values. If a regridded cell takes values from cells with different land use classes, the resulting value is something between the values of the cells before regridding, something that is away from reality.
Is there a way to fix this? Is it possible for the regridded cell to take a land use values in a different way, like “dominant neighbour” for example?
If you intend to use the MCIP files to run CMAQ, you should run WRF on the correct domain and then process those files through MCIP. Interpolating existing MCIP files to a new domain will not only introduce issues with the land use index variables (and any soil index variables you may have), but will also not be mass conservative for the 3D meteorological fields.
I am using MCIP files for another CTM, that uses UTM projection, not included in WRF. So, the regridding is needed. That’s the reason I am using MCIP and IOAPI and I wanted to know if there is a way to bypass values interpolation for terrain parameters.
Thanks for clarifying the background for your question. If I understand the situation correctly, your CTM (presumably neither CMAQ nor CAMx) can only operate on a UTM projection, but WRF does not support this projection. If so, which meteorological models or tools are usually being used to prepare input meteorology for that CTM?
@cjcoats would have to answer whether it’s possible to use I/O API tools to apply nearest-neighbor rather than distance-weighted interpolation to certain index-based fields (land use, soil type) when using these tools to interpolate your MCIP files from the native WRF projection to UTM. Doing so would obviously introduce inconsistencies between the various fields, but it seems you are willing to accept dynamic inconsistencies in your application.
If this cannot be done with I/O API tools, one potential solution (if this really is the path you’d like to proceed on) would be to write your own custom Fortran program to find the closest WRF-projection grid cell for each target grid UTM cell using I/O API projection functions, read in the land use index values for the relevant grid cells from the original MCIP files, and then overwrite the (interpolated) index values in the UTM MCIP files with these nearest neighbor index values.
It almost works: land use category by rights is an INTEGER not a REAL – M3Tools program m3cple does bilinear interpolation for REAL variables, and “what is the input value at the output-grid cell-center” for INTEGER variables.
If those variables had been INTEGER, it would have been easy – but the programmers who wrote the code are still trying to optimize for 1985-vintage Crays, for which INTEGER arithmetic is slower than REAL. (What can we do to bring programming for the environmental modeling community up to at least the year 2000??)
For a “roll your own” code, m3cple (for which the source is distributed as part of the I/O API) would be a good starting point – you’d just need to special-case the interpolation code so that it recognizes land-use type and mimic’s the INTEGER-variable computation for that variable only.
Or write a single-variable land-use-type-only code, and then m3merge its output with the rest of the variables from your m3cple run into a new file that has everything “correct”.
Oh, by the way, “IOAPI” is incorrect. It is “Input/Output Applications Programming Interface” which abbreviates to “I/O API”…
My CTM is Episode-CityChem. The procedure for the meteorological files is this:
WRF → 25h files → MCIP → I/O API → WRF4CC → CityChem
WRF4CC is a preprocessor, that takes the I/O API output files (must be in UTM grid) , interpolates meteorological values for the layers of CityChem (not the same with the layers of WRF) and gives the proper format for CityChem. It is created by the the developer of CityChem.
Regarding land use, until now we were bypassing I/O API, by introducing the relevant MCIP file into QGIS, regridding without interpolation, and overwriting on the I/O API output file. This is done by another member of my team, and is more time consuming, so I wanted to know if there is a more straight way through I/O API. Beyond land use, I discovered that there is also an issue with roughness height, although not so big, because roughness height is not an index like the land use classes.
I tried this for a beginning:
I altered the land use class within the MCIP file, from a float to an integer. I get an error message “ERROR: variable [name of the variable]”. It’s probably the error message from the m3cple code, around line 500. The parameter is printed in the netcdf file, but without values.
I have looked all over the m3cple.f90 code. There is no INTEGER-variable computation in there, beyond the copy case, which is not what I want, because I want to change the grid. Is it maybe in a subroutine, that has to be called?
The three big problems I see here:
- Wind components
- Land use type
- Roughness length and related variables
All of these are either non-linear or integer-computation problems; wind fields also suffer from the directionality-problem (the UTM grid-directions are not the same as the WRF-grid ones, so a cell-dependent rotation is also needed).
For land-use type, you’d really be better off to go back to the original (very high resolution) foundation data, and re-compute for your own grid. Note that I/O API routine GRID2XY from MODULE MODGCTP can easily do the spatial computations you need; all that’s left is using the result and adding up the numbers of foundation-grid land-use types over each UTM-grid grid-cell, deciding then which one is the dominant one and what the land-use fractions are.
Again, since roughness length aggregates non-linearly (harmonic mean) you’d be far better to compute it from what you just did for the foundation data.
And then of course a number of vertical mixing parameters depend upon roughness length, and the ones you lnterpolate from WRF won’t be consistent with that…
It sounds as though it might be easier to start with a met-model that supports UTM (RAMS?)…
By the way, M3Tools program ***CAMXTOM3 can easily be used to convert UAM/RAMS-format data to I/O API…
Thank you very much for your advice.
I used the original land use data for a computation for the UTM grid.
I also used a look up table, in MCIP fashion, to create the roughness height field from the land use field.