I am currently applying CMAQv5.3.2 for nested operation. When running source resolution with ISAM, the result of running 36 kilometers is fine. When running 12 kilometers of ISAM with the same script, after modifying the relevant path files, there are no errors in the log, and the program runs normally without interruption. The source resolution result (SA_CONC file) shows that the zero-point data of the marked area for each day starts a new. The source resolution marked area data for each day is 0 at the 0th point, but the BCO, ICO, and OTH of the source resolution all inherit the data of the previous day (SA_CGRID).
The version of the compiler I’m using is ifort (IFORT) 2021.3.0 20210609
run_BTH2+26_12KM_ISAM.csh (34.6 KB)
CTM_LOG_000.v532_ISAM_intel_BTH2+26_12KM_20250326.txt (581.5 KB)
CTM_LOG_000.v532_ISAM_intel_BTH2+26_12KM_20250327.txt (561.0 KB)
When I use isam_control.fen.txt, the result that appears is as shown in the above figure, which is incorrect. When I use isam_control.hebing.txt, the data of the last hour of the first day can be inherited in the first hour of the second day. But I want to operate by industry.
isam_control.fen.txt (4.4 KB)
isam_control.hebing.txt (1017 Bytes)
To add to @lizadams ‘s comment, your isam_control.fen.txt configuration file defines 67 different tags and you’re running for the OZONE tag class which I believe tracks ~55-60 different precursor species, so your SA output file will have more than the 2048 variables allowed in the standard I/O API library. When you built your executable, did you compile it with the I/O API version 3.2 “large” as noted in the User’s Guide for applications generating a large number of output variables?
Thank you for your reply. I have found the solution. I added “_” to the TAG NAME in isam_control.txt. It should be AGRYH instead of AGR_YH.
