Error in running COMBINE for CMAQ5.3.1

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