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.
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?
Hi,
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.
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?
Thanks
Sham
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.
Thanks again.
Sham
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.
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 A and 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
and then A and B give different rounded-to-6-digit outputs 1.23456 and 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 GRDCHK3
