I am using the plume in-line emission setting to process Canadian industrial emissions with the plume rise threshold of 38m. The plume in-line outputs for the 9 and 3km domains were reasonable. For the 1km domain, the in-line method did not work and gave the following error. FYI I was able to run the rest of the Canadian inventories for the same 1km domain without any error.
I then turned off the ELEVPOINT and changed the SMK_METHOD to 0 to re-run the point source inventory. With this setting, a reasonable output was generated.
I am confused with why the plume in-line setting doesn’t work for the 1km domain. Can you please help me understand what exactly the smoke plume in-line emissions are and also how to decide on a reasonable plume rise height for the threshold value?
I have attached the log file related to the error shown above, my griddsec file and as well as the inventory files I am having issues running the plume in-line.
GRIDDESC_test.txt (1.5 KB)
smkmerge.point_16.16can.20161001.MO1km.txt (18.3 KB)
canada_2015_point_noVOC_svn70_02apr2019_v0.csv (7.6 MB)
canada_2015_point_VOC_INV_svn70_02apr2019_v0.csv (974.9 KB)
Not sure either. SMOKE does not care whether it is 1km or not but care more about the size of data files to process.
Can you check the header information from Grdmat output file (PGMAT) and see whether all the grid parameters are consistent to the MO1km info from GRIDDESC input file? Can you post the grid information from the PGMAT file header?
I managed to get the plume in-line method working for the new 1km domains. It was an issue with old and new surrogates for our 1km domains.
Anyhow, I am getting the following error( same error as before) when running the layered emissions.
This issue is there only for the layered emissions.
hence, I suspect it is related to the issue with miss match grids in MCIP outputs and surrogates.
My MCIP 1km domain is large and I use the m3cple tool to extract the MCIP outputs for the smaller 1km domain which we generate smoke emissions for.
As you can see in the following figure, the smaller 1km domain has an offset with the larger domain.
I believe this is the issue that causes the above-mentioned error. I was wondering is there any other tool that can be used to interpolate the values to the smaller domain?
Or simply fix this error?
This has a number of problems:
These grids are not on the same map projection (one grid is clearly rotated with respect to the other), so in particular the wind-components won’t be counter-rotated correctly by interpolation-programs.
Do the command *ncdump -*h on your emissions file and the MET_CRO files, and see whether the
XORIG,YORIG,XCELL,YCELL grid-definition agree up to reasonable round-off error: if so, then something is wrong with the parameter-match tolerance in your laypoint; if not, then you do not have correctly matching grids; I would suggest you read up on the specification of grids and map projections..
Note also that since emissions units are not truly MKS units (they have an unstated “per grid cell” component to the units), when interpolating you need to re-scale emissions by the ratio of grid-cell sizes. Also, because of this “per grid cell” issue, it is better to use programs mtxcalc followed by mtxcple, which (a) have scale-factor application; and (b) use sub-sampling to do approximate cell-totals.
Thanks for the quick response. The MET_CRO files do agree with the GRIDDESC info for the smaller 1km domain. As you mention it is then the parameter-match tolerance in the laypoint. is there any way to tweak this? or do you think it is better to re-define the small 1km domain in a way that it overlaps with the larger 1km domain?
I will go through the information you shared as well.
I changed the QC1km domain to match with the wrf domain and also made sure the surrogates and mcip output all have the same grid info.
However, i am still getting the same error.
Following is the surrogate output domain info:
#GRID QC1km -71.415880 46.687960 0.013282 0.009081 22 24 1 LAT-LON degrees 0.000000 0.000000 0.000000 0.000000 0.000000
Here is the original WRF domain-based MCIP GRIDCRO and METDOT3D info.
Here is the QC1km MCIP output (used m3cple tool to get these) domain info :
I tried shifting the METDOT3D xorg, and yorg a bit to see if it will work. So far nothing really has worked for me. I have used the exact same procedures for our 9 and 3km domains and those all worked just fine.
Anyways, I am attaching the laypoint log file for your reference.
laypoint.point_16.16can.20161001.QC1km.txt (15.6 KB)
pgmat info is below as well.
Any lead will help. Thanks a lot.
These grids aren’t even close to being compatible – starting with Lambert Conformal Conic for the met-grids and Lat-Lon for the emissions-grid…
You need to be working “within the same system” in order for the modeling to work.
As noted here MCIP output projection change, I used m3cple to change the wrf domain to the emission (lat/lon) domain.
This whole method worked for our 9 and 3km domains. so I think this is just a precision issue in laypoint program. would it be problematic if I change lib/chkgrid.f script?
Generally, you need agreement to about 5 significant digits to be sure you have the “right” parameters.
Note that this means relative differences, not absolute differences: something like the following for checking two constants
A, B against each other:
ABS( B - A ) < 1.0e-5* MAX( ABS(A), ABS(B) ) or
ABS( B - A ) < 1.0e-5* ( ABS(A) + ABS(B) )/2 or
( B- A ) < 1.0e-10*( A^2 + B^2 )
(or see the
DBLERR function in ioapi/grdchk3.f)
Note that checking if
B give the same 6-digit ASCII string (e.g.,
WRITE( STR, '(1PE13.6)' ) A )
does NOT work, because two VERY-CLOSE numbers may round differently, e.g., let
X = 1.234565d0
E = 1.0d-15
A = X + E
B = X - E
B give different rounded-to-6-digit outputs
1.23457 in spite of the fact that the relative difference between them is only about 2.0d-16
I understand your point. Is there a way that I can fix this issue?
I have already generated all the other emissions for this 1km domain and the only standing issue is the volume emission. I have tried changing the grid info by several decimals and tried matching. so far nothing has worked.
Find the file (and subroutine) where this error-message is being generated (grep for the message in the SMOKE source). There will be multiple such grid-parameter checks: replace them with a call to the I/O API routine