Hi, I have a few domains defined in LLC which i am using to generate emissions in SMOKE. However, the AQ model we are using requires the Domain info in lat/lon coordinates. Is there any tool that I can use to convert the GRIDDESC file info to Lat/lon?
I tried using the ioapi latlon tool and it did not generate the correct values.
Thanks for your help.
Sham
If I understand you correctly, you have SMOKE-output emissions data defined on a Lambert Conformal Conic grid, and you wish to generate input for some other model’s Lat-Lon based grid.
First of all, a warning: Be careful of the units; frequently, emissions data is in silently non-SI units that cannot be simply interpolated – often, mass per grid cell per unit time, so that interpolation must be followed by re-scaling by the ratio of grid-cell areas, or something like that. (Does your Lat-Lon based model assume this “per grid cell” implicit units-assumption?)
Several of the M3Tools programs may be helpful:
m3cple does grid-to-grid linear interpolation (with optionally different output map-projection from the input). It should be used only if the output grid is finer than the input. Versions of the program for Oct. 21, 2021 or later optionally apply a scale-factor (which may be the ratio of grid-cell areas). Be cautious with Lat-Lon, since Lat-Lon grid cells have varying areas.
Programs mtxcalc and mtxcple work together for emissions data when the resolutions are comparable, or when the output resolution is coarser than the input: the former uses sub-sampling to create a sparse-matrix to transform input-grid data to output-grid data, with an optional scale-factor; the latter then uses the matrix for the data-conversion.
And then, of course, you’ll need to transform into the file-format expected by your model…
If your Lat-Lon grid is large enough that the cell-areas are not approximately constant, then after running the data-conversion with scale-factor 1, you should then compute cell-areas for your Lat-Lon grid, divide by the input (Lambert)-grid cell areas, and re-scale the emissions-data by that gridded ratio before using it.
See https://cjcoats.github.io/ioapi/GRIDS.html#horiz for more about Models-3/CMAQ horizontal grid and coordinate-system conventions.
Thanks for the quick response. the AQ model we are using requires emissions as bin files and units have to be emissions in micrograms, per square meter, per second (surface emissions). I have scripts to do these conversions.
My main concern is AQ model (Polyphemus) requires domain info, the center of the bottom left corner coordinates, delta_x and delta_y in lat/lon coordinates. So I am looking for a method that I can use to simply convert the GRIDDESC file inputs in llc to lat/lon. I understand this conversion won’t be 100% accurate. I just need to make the best assumption possible.
Hope this makes sense. Thanks again.
First of all: good, you understand the units issue and it looks as though you have it under control.
For the M3Tools programs above, what you need is a GRIDDESC .
GRIDDESC files are documented at https://www.cmascenter.org/ioapi/documentation/all_versions/html/GRIDDESC.html; there is a sample file at https://www.cmascenter.org/ioapi/documentation/all_versions/html/GRIDDESC.txt, with Lat-Lon, Lambert, and UTM coordinate systems, and various grid definitions in terms of these coordinates.
This sample file shows how to define the Lat-Lon coordinate system; for the grid definition, you need the cell-size (your delta_x and delta_y), the bottom-left corner coordinate (in Lat-Lon; it will be a
half-cell below/left of your bottom-left cell-center (also in Lat-Lon), and of course the numbers of grid-columns and rows. For your purposes, you don’t need to worry about boundary-thickness NTHIK–just set it to 1 for the usual boundary-files.
For BIN-files, the caution is about storage-order: frequently , the GIS people use “scan-line order”,
where the (1,1)-cell is at the upper-left. If this is the case with your grid, then you need to put the grid-origin at the upper-left corner of the (1,1)-cell, and let YCELL = -delta_y; M3Tools programs such as m3cple are carefully coded to work in all cases of X, Y cellsize positive or negative also (frequently, the CMAQ tools are not, by the way…).
Carlie J. Coats, Jr., Ph.D.
I/O API Author/Maintainer
I’ll apologize in advance if I’m misreading the conversation so far, and specifically the two posts by @shayamila.gamage, but I think there may be a misunderstanding.
If your intent is to simply convert the format and units of your existing emission files (with emissions that are gridded onto a LCC grid) and then just tell your AQ model that they are on a regular lat/lon grid (by specifying the center of the bottom left corner lat/lon coordinates and delta_x and delta_y in lat/lon coordinates, which you apparently intend to obtain from the GRIDDESC file you would like to create) without actually regridding them to a regular lat/lon grid, that just is not possible from a projection perspective (there simply is no way to calculate evenly spaced delta_x and delta_y in lat/lon space from the evenly spaced delta_x and delta_y the LCC space). If your AQ model needs to be run in lat/lon space, the best approach would be to use the definition of your desired lat/lon air qualiy modeling domain when processing emissions in SMOKE. If that is not possible, you do need to actually regrid the emissions from LCC space to lat/lon space, possibly using the tools listed by @cjcoats in his first post and taking into account his caveats about cell areas.
Again, my apologies if I’m misreading your plans, I just interpreted your statement “I have scripts to do these conversions.” as only tackling the necessary unit and format conversions but not the required regridding step.