CMAQ combine module 1.3km

I tried to use combine module for 1.3km but it was not working with this error.
Is there any solution?

Please see these recent discussions:

Posts 17 - 19 in this thread
Error in running combine for cmaq 531

I changed
#verify domain parameters
#check if file needs to be converted
but still not working.
I tried to mix and match as well.

In that case, there might indeed be a non-negligible difference in the XCELL parameters across the files you are trying to combine variables from. To troubleshoot this further, can you please attach a copy of your run script and the header (ncdump -h) of all input files provided to combine?

As an aside, in the modified code shown in the screenshot, you want to change the variables in the line with the “!height of cell” comment from XCELL to YCELL so the if statement doesn’t duplicate the line above that, but clearly even the XCELL comparison already triggers the if statement.

There was also a recommendation to set the following:
IOAPI_CHECK_HEADER flag should be N

That I/O API environment variable might only affect the creation of output files

so it shouldn’t come into play here when the actual combine code performs consistency checks across input files and exits when detecting inconsistencies (in a generally non-robust manner as noted in the other threads), but it can’t hurt to try.

1 Like

IOAPI_CHECK_HEADER is irrelevant: it causes checks for negative dimension-values and duplicate variable-names; grid-parameter checking should be done byI/O API routine GRDCHK3(), which checks whether grid and map-projection parameters match up to reasonable round-off error, and gives meaningful log-messages in case of mis-matches( indicating exactly which parameters are mis-matched.
Program combine (which was written much later than GRDCHK3(), by the way) does exact-value checking for these parameters, not allowing for any round-off error whatsoever. In that, it violates coding standards which were supposedly in place at the time it was written: from a numerical-analysis point of view, one should NEVER test REALs for exact equality.
Replace all these checks in combine with a call to GRDCHK3() (look at M3Tools program m3diff to see how this should be done).



There are headers of files that I am using now.
[1] ACON_head.txt (60.1 KB)

[2] METCRO3D_head.txt (10.1 KB)

[3] APMDIAG_head.txt (15.3 KB)

[4] METCRO2D_head.txt (13.6 KB)

Best regards,

Hello Hyeongseok,

thanks for posting the file headers.

The differences in XCELL and YCELL are sufficiently small that your updated grid consistency check in post #3 should no longer trigger the “valid = .false” action.

However, looking at the two lines with the “!width of cell” and “!height of cell” comments again, it seems both lines (adapted from post #14 in the other thread I linked) have unbalanced parenthesis, aside from the fact that the second line should check for YCELL instead of XCELL. In these lines, “((XCELL-XCELL3D)**2” should either be “((XCELL-XCELL3D)**2)” or “(XCELL-XCELL3D)**2” (or YCELL on the second line).

Are you sure you were able to successfully recompile combine after making these code changes, and your run script was using the updated executable in your latest tests?

As noted in one of the other threads, another brute force solution to your specific case would be to comment out these checks altogether, recompile the executable, and use it for this case, but you would not want to use that executable for any other case where you want to perform the grid consistency check. But the relative grid consistency check should work.

Thank you for reply.

I changed my code to this. But still not running. 1. Can you check it?

Also, 2. can you tell me how to recompile with this code?
because I tried to leave this script only to recompile but Everything is changed after recompiling.

Thank you for your efforts.

After you make these code changes in the BLD directory, you don’t want to re-run the bldit script from the directory above that, because that will just pull the original unmodified code back from the code repository.

Instead, after modifying the code, you want to rebuild the executable in the BLD directory by typing make clean followed by make. If the revised code compiles successfully, you should now have a new executable which you should then reference in your run script.

I should have been more clear. You CAN rerun the bldit_combine.csh script again to compile the executable from your revised code, but you would have to comment out the following line

set CopySrc #> copy the source files into the BLD directory


# set CopySrc #> copy the source files into the BLD directory

in order to avoid overwriting your edited code with the original unmodified code from the code repository.

Using make clean and make in the BLD directory is the more direct way to build the new executable, though.

1 Like

Thank you!!!
It is working well now!

Thank you for your big help for a few days.

Best regards,

1 Like