This is the error we get when we run COMBINE program to calculate parameters that require MET files from WRF runs. The program runs fine for parent domain but gives this error when run for nested domain. Surprisingly the inconsistency in the coordinates pointed by the error is not there.
Error Inconsistence file domain for INFILE2
NROWS= 45 45
NCOLS= 63 63
XORIG= -865254.00 -865254.00
YORIG= -112772.09 -112772.09
ERROR Cannot open all input files
Program combine has problems with its grid-consistency checking; I will be talking with EPA about that later.
This may be a precision issue when computing the I/O API XORIG/YORIG values from WRF projection attributes and dealing with non-integer grid resolutions like 1.33333 km and/or non-integer origins like YORIG= -112772.09 in your example. Could you please share the resolution you used in both your successful processing of the parent domain and the failed processing of the nested domain?
In the meantime, you could try modifying lines 208 - 209 of module_file.F to relax the tolerance for the consistency check.
Change
if( ABS(XORIG-XORIG3D) .gt. 0.000001 ) convert(N) = .true.
if( ABS(YORIG-YORIG3D) .gt. 0.000001 ) convert(N) = .true.
to something like
if( ABS(XORIG-XORIG3D) .gt. 0.01 ) convert(N) = .true.
if( ABS(YORIG-YORIG3D) .gt. 0.01 ) convert(N) = .true.
and see if this helps with your processing of the nested domain.
Thank you for your kind help.
Thank you for your kind response.
The grid resolution we used for parent domain was 36 x 36 km while for nested domain we used 2 x 2 km. We didnât follow the 1/3 or 1/5 rule for the 4th domain so as to keep the grid resolution an integer.
I just tried of relaxing the tolerance for consistency check in module_file.F to 0.01 and even to 0.1. We still ended with similar error:
Error Inconsistence file domain for INFILE2
NROWS= 45 45
NCOLS= 63 63
XORIG= -865254.00 -865254.00
YORIG= -112772.09 -112772.09
ERROR Cannot open all input files
Also we are eagerly waiting if you can suggest some solution based on your discussion with EPA.
Many thanks in advance.
What is really needed here (and many places elsewhere in the modeling) is a test that says âgiven possible round-off error, these two numbers are probably intended to be the same.â That needs to be a relative-magnitude test, using a tolerance somewhere between 1.0e-5 and 1.0e-6 (and you need the former if there is any possibility youâre dealing with IBM s/360 arithmetic; the latter is probably good on IEEE-compliant hardware). There are several ways you might go about this; the fastest probably is the one that uses squaring instead of absolute values, and that avoids (expensive) divisions; it looks something like
(X-Y)^2 < TOL^2 * ( X^2 + Y^2)
as a test for approximate equality. Note that absolute-tolerance tests that donât compare the difference with the magnitude of the numbers being compared will fail unless the relative size of the numbers being tested is already known; and the test of writing out 6-significant-digit character strings and comparing them is both very expensive and bogus, because very-nearly-equal numbers near the rounding-threshold can âtest wrongâ â for example, let A=1.234565 (right on the 6-digit rounding-threshold), and consider X=A+1.0e-16 and Y=A-1.0e-16: X rounds to "1,23457" while Y rounds to "1.23456" although X and Y are exceedingly close.
The I/O API routine GRDCHK3() is designed to do just this sort of checking, for the complete set of parameters used to define a grid and map projectionâŚ
@nimish , I have sent you a message so we can try to troubleshoot this after having a look at your files.
Thank you Christian. The issue has been resolved by the code modifications suggested by you.
The simulation was not working due to slight difference in YORIG between the MCIP files and CMAQ output files.
MCIP_output_file: YORIG = -112772.0859375
CMAQ_output_file: YORIG = -112772.086
To solve this issue we have to âmodifying lines 208 - 209 of module_file.F to relax the tolerance for the consistency checkâ as suggested in your earlier post.
After this recompile âcombine_v532.exeâ, and the program works as suggested.
Hope the solution helps other users.
Regards
Nimish Singh
Hi
I have the same error although I did what you suggested on this topic.
these are my log and run_combine.csh.
log.txt (5.8 KB)
run_combine (copy).csh (6.5 KB)
And these are my global attributes for INFILE1(cctm_aconc) and INFILE2 (metcro3d).
cctm_aconc.txt (9.5 KB)
metcro3d.txt (6.2 KB)
This is also my grid desk file.
GRIDDESC_1p8.txt (229 Bytes)
Thanks for your response.
Sorry, no help here: the author of COMBINE does not do a proper job of error-logging, so we do not know what is the cause of his âinconsistentâ claim. Moreover, he did not use standard I/O API library functions written half a decade before he wrote COMBINE, that would have done a detailed and robust job of consistency-checking with a detailed error-log report.
Solution: either compile for debug and watch this code under the debugger (which will be tricky: the standard scripts claim to support debugging but do not do so correctly); or else re-write this code for a proper job of consistency-checking (for that latter, M3Tools program m3diff provides a good code-example of such checking).
Or as a test, run m3diff in statistics-mode (i.e., not generating an output difference-file, only a statistics-report) on a combination of variables from the files (maybe ozone-temperature). Either the files are inconsistent and m3diff will tell you just what the problem is, or else you will know the files are indeed consistent but have a meaningless statistic-output.
Given your XCELL/YCELL grid spacing of 1811.11120605469 m, the source of the error very likely is this consistency check on lines 194 - 202 of module_file.F:
! verify domain parameters
if( XCELL.ne.XCELL3D ) valid = .false. ! width of cell
if( YCELL.ne.YCELL3D ) valid = .false. ! height of cell
if( .NOT.valid ) then
Write( *, '(''**Error** Inconsistence file domain for ''
& ,A)' ) M3FILENAME(n)
N_M3FILES = 0
return
endif
As discussed by @cjcoats further up in this thread (when dealing with similar issues for the other userâs slightly different XORIG and YORIG values), the solution would be to change the consistency checks between XCELL/XCELL3D and YCELL/YCELL3D from a direct comparison to a check that allows for small deviations.
Alternatively, if you are only using this tool for this particular project and grid setup, you could also decide to comment out these checks given that you have manually verified by looking at the grid headers that you are dealing with consistent grids and given that the consistency check as coded does not work for your setup, but in general that might be risky if for other setups youâd like the code to catch potential inconsistencies.
Also looking at lines 208 - 209 of the main combine.F code
IF ( XCELL .NE. XCELL3D ) KSWIT = .false.
IF ( YCELL .NE. YCELL3D ) KSWIT = .false.
Iâm not sure if only modifying (or commenting out) the consistency check for the input files in module_file.F would solve your problem or whether you might have to do the same here for the output file consistency check.
Thanks for your response.
I solved the error by changing the source code of combine (module_file.F), making clean, and making combine again.
You should modify the lines 194-195 of module_file.F
from
if( XCELL.ne.XCELL3D ) valid = .false. ! width of cell
if( YCELL.ne.YCELL3D ) valid = .false. ! height of cell
to
if( abs (XCELL-XCELL3D).gt.(1e-5) ) valid = .false. ! width of cell
if( abs (YCELL-YCELL3D).gt.(1e-5) ) valid = .false. ! height of cell
I should say if someone has the error again, they can change 1e-5 to 1e-2.
1 Like
What you want is a relative tolerance (with the tolerance scaled by XCELL), not an absolute one. Note that if XCELL is 45.0D3 ( for 45KM cell-size), then your 1e-5 represents a difference in the tenth significant digit â way within the realm of potential round-off error problems. Instead:
if( abs (XCELL-XCELL3D).gt.(1e-5*XCELL) ) ...
or
if ( ((XCELL-XCELL3D)**2 .gt. (1e-5*XCELL)**2 ) ...
which is slightly more efficient computationally.
2 Likes
You are right. It can be better.
Also, the IOAPI_CHECK_HEADER flag should be N, otherwise, we receive an error.
I hope these solutions that checked up on this topic, will be in the new release of CMAQ.
Thanks again.
1 Like