ERROR: Grid origins not compatible between AQRP_TX_12 in
grid description file and initialized values.
ERROR: Grid parameters for AQRP_TX_12 in
grid description file are inconsistent with initialized values.
*** ERROR ABORT in subroutine GRDMAT
Problem with gridded input data.
Are the values close enough that they may reasonably ascribed to round-off error, given that the calculations for them may have been done in single precision, not double? …and note that the tolerances for “close enough” should be relative, not absolute (e.g., ABS(P-Q)<TOL*MAX(*P,Q) or, more efficiently (since pure arithmetic is faster than the logic in ABS or MAX), (P-Q)^2<2.0D0*TOL*(P^2+Q^2)).
SMOKE routine CHKGRID uses absolute comparisons e.g., DABS(XORIG-X0)>0.001D0), with a 1-mm tolerance that is completely unreasonable for the question at hand’ It should instead have used standard I/O API routine GRDCHK3 which is carefully tailored to handle this relative-tolerance problem.
One solution is to borrow code from GRDCHK3 to fix CHKGRID.
BTW, be aware that there are lots of less-than-obvious ways in which single-precision arithmetic may have happened, if you’re not careful. It is perfectly legal (under the Fortran Standard) for the code reading the GRIDDESC file to say to itself:
Hmmm… -994500.000: decimal point but no D-exponent field nor type-specifier. Let’s read this in as a single precision REAL and then convert it to DOUBLE.
Most compilers don’t generate code that does this (they get complaints from customers; on the other hand one prominent free compiler can be quite self-righteously idiosyncratic) but if this is in fact the problem, then replace the -994500.000 by -994500.000D0 (or -994.5D3, from which you can easily read kilometers as well as meters). [Still doesn’t replace the defective SMOKE code, though.]
Carlie J. Coats, Jr., Ph.D.
I/O API Author/Maintainer
Thank you for your quick response Carlie. I tried with both “-994500.000D0 or -994.5D3” and it says the same thing.
When I check my other MCIP files, parameters are as follows:
:P_ALP = 33. ;
:P_BET = 45. ;
:P_GAM = -97. ;
:XCENT = -97. ;
:YCENT = 40. ;
:XORIG = -994500. ;
:YORIG = -1606500. ;
:XCELL = 12000. ;
:YCELL = 12000.
But my GRIDDESC is like I posted before. I also tried with -994500. but it is not working either.
I have used .000 format for some other domain before on the same SMOKE set up and it was working fine before. What should I do now?
Thank you again. @bbaek@eyth.alison what do you guys think?
If you are using the EPA provided spatial surrogates, the xorig and yorig of their domain need to be divisible by 12000 so that their domain and the surrogate domain line up. Also, they should change the grid description in each of the 12km spatial surrogates back to the original grid description (our grid, not their grid) so that SMOKE knows the col/row numbers correspond to the surrogate domain.
Thank you very much for your help Alison. I was thinking that I only need to set Alpha = 33º, Beta = 45º and Gamma = ‑97º, with a center of X = ‑97º and Y = 40º. Can you or maybe @tlspero@rgilliam help me to find out how to set my namelist in such a way that XORG and YORG are divisible by 12000?
I can give you an explanation of how to do this, but I won’t be able to answer until later today or early tomorrow. I assume you’re asking with respect to WRF, so that is how I will explain it.
To your question about constraining the WRF domain to adhere to the emissions constraints for the U.S. with SMOKE, I believe this is what you will need to do. Keep in mind that I did not test it, but I’m pretty sure it will be what you need.
As I understand it, the spatial surrogates for the emissions are constrained to a Lambert conformal projection with true latitudes at 33N and 45N and a standard longitude at 97W. The latter three parameters are reflected in Models-3 I/O API as P_ALP (alpha), P_BET (beta), and P_GAM (gamma). In addition, the surrogates are constrained to a central longitude (XCENT) at 97W (the same as the standard longitude) and a central latitude (YCENT) of 40N. Both XORIG and YORIG are defined with respect to XCENT and YCENT. Per @eyth.alison, XORIG and YORIG need to be in increments of 12,000 meters (or 12 km) for compatibility with the emissions surrogates domain.
When you are configuring the domain in Geogrid in the WRF Preprocessing System (WPS), you will need to do the following within the “geogrid” namelist for WPS:
dx = 12000 ! grid spacing in meters in the x-dimension
dy = 12000 ! grid spacing in meters in the y-dimension, and dx=dy
map_proj = ‘lambert’ ! shorthand name in character/string for the map projection to be used
ref_lat = 40.0 ! reference latitude
ref_lon = -97.0 ! reference longitude
truelat1 = 33.0 ! one of the two true latitudes, where map-scale factors = 1.0
truelat2 = 45.0 ! one of the two true latitudes where map-scale factors = 1.0
stand_lon = -97.0 ! the standard longitude, which aligns south-north in projected space
The above items will set your projection to match that used for the emissions surrogates. Now for the flexibility of where you place your domain:
Because you need to align with the grid for the emissions surrogates exactly (rather than slightly offset by half of a cell), you will need to set your grid dimensions to be odd numbers. In WRF, the grid dimensions count the edges or corners of cells rather than cell centers. (By contrast, CMAQ and associated processors use the number of cells or cell centers, so the WRF dimensions for the same physical space are increased by 1, relative to CMAQ.) By using odd-numbered dimensions for the horizontal grid, you are aligning the center longitude and center latitude with a corner that is common for four cells (and overlaps with the emissions surrogates domain).
a. s_we = 1 ! index for the start of the west-east dimension (edges of columns)
b. e_we = {an odd number} ! index for the end of the west-east dimension
c. s_sn = 1 ! index for the start of the south-north dimension (edges of rows)
d. e_sn = {an odd number} ! index for the end of the south-north dimension
Now that you’ve laid out the size of the domain that you want, you can shift it around. That is, you are not constrained to keep 40N,97W as the actual center of your domain. WRF has given you the flexibility to move that reference point around. You can use the following two namelist variables to shift things around. These two variables are the grid points (edges) where you’d like to move ref_lon and ref_lat within your domain. They are identified by their grid point indices, keeping in mind that the counting starts with 1 (not 0).
a. ref_x = {xx}.0 ! where “xx” is the real number equivalent of the column edge where you want ref_lon
b. ref_y = {yy}.0 ! where “yy” is the real number equivalent of the row edge where you want ref_lat perpendicular at ref_lon (ref_x)
Hope this helps. Please let me know if this works for you.