Interestingly, my CCTM_CONC_v55_gcc_huabei_20200630.nc file is generated from the METCRO3D_huabei.nc file.The runfile is as follows run_cctm.csh (39.2 KB) run_icon.csh (6.1 KB)
there are several approaches you could take in your specific case.
Given that you’re certain that your grids match and you’re just dealing with a precision issue, you could comment out the relevant grid consistency checks on lines 176 - 237 of subroutine m3_ck_ctmmet.F and then recompile ICON
you could presumably also edit line 277 in the same file linked above to change 94000 FORMAT( E15.5 ) to 94000 FORMAT( E15.4 ) or 94000 FORMAT( E15.3 ) to require a lower level of precision matching but leave the actual consistency checks in place and then recompile ICON
for a more robust and general solution, the code in lines 176 - 237 could be updated along the lines described by @cjcoats in this related post.
This doesn’t quite work.
Assuming the program does a perfect job of rounding (something not guaranteed by the Fortran Standard), no such look-at-ASCII-strings test works, as I have written extensively elsewhere. See NOTE below.
What is really is needed is to measure the relative error: how big is the difference when compared to the original numbers – something like ABS( B-A)/(0.5*A + 0.5*B) < TOLERANCE
(or various other relative-error formulations like those found in DBLERR from ioapi/chkfil3.f90 (which is what the author of this code should have used anyway).
NOTE
DOUBLE PRECISION, PARAMETER :: A = 1.234565D0
DOUBLE PRECISION, PARAMETER :: E = 1.0D-15
DOUBLE PRECISION, PARAMETER :: X = A - E
DOUBLE PRECISION, PARAMETER :: Y = A + E
X and Y are incredibly close; however (assuming perfect rounding), they fail the ICON-code test, which treats X as 1.23456 and Y as 1.23457 for purposes of its comparison.
Making matters worse, the ICON code reports the numbers to the log using a different format than it does for the comparison…