I am using CMAQ-ISAM v5.3.3 to tag PM₂.₅-related species. However, in my output, the variable AECJ in the CCTM_SA_ACONC file is entirely zero, while in the regular CCTM_ACONC file, AECJ does have nonzero values. I also checked other species such as ASO4J, ANH4J, and ANO3J, and they all have valid (nonzero) values. I’m not sure what caused this issue, and I would greatly appreciate your help.
In the CCTM_SA_ACONC file, do the AECJ_ICO (contribution from initial conditions) and AECJ_BCO (contribution from boundary conditions) variables have non-zero values?
Looking at the CTM_LOG file, I think the emissions files may not include EC. If using the default emission mapping, then CMAQ expects there to be an emissions variable called PEC which will be mapped to the AECI and AECJ CMAQ species. In the emission portion of the CTM_LOG file (the part that starts with “EMISSIONS SCALING DIAGNOSTIC”), I am not seeing any lines for EC emissions. Could you check your emission input files to see if they include the variable PEC?
Hello, I found an issue while processing the data: the average daily proportion of the “local emissions” category in the marked area is abnormally low. Local emissions should account for around half, but the result is only a little over 10%. Meanwhile, the values labeled as “OTH” are unusually high, making up 70–80%. This result is clearly unreasonable. I would like to ask why this is happening. Could you help identify the potential cause of this discrepancy?
I just realized that there is overlap at the boundaries of my regions. And I found the error.
I see from your run script and the CTM_LOG file that all of the emission files use the same emission label GRIDDED_EMIS which is also the emission label that is given in your isam_control.txt file. With that configuration, it may be that ISAM is only tracking the contribution from the last emission file that was assigned the GRIDDED_EMIS label while the contribution from the other emission files are tracked in the OTH tag.
You should give each file a unique label in the run script. Then in your ISAM control file, you can list the different labels as a comma separated list for the EMIS STREAM(S)line. For example if you decide to assign the labels GR_TRANSPORT, GR_AG, GR_RES, GR_IND, GR_POWER to your emission files then the line in the ISAM control file should be as below to track the contribution from the sum of the five emission files: EMIS STREAM(S) |GR_TRANSPORT, GR_AG, GR_RES, GR_IND, GR_POWER.
As for whether this will resolve the warning related to the ISAM mass balance error, I am not sure, but let’s see if it resolves after updating the emission labeling.
Hello, I assigned a separate label to each emission file, but in some of the logs an error appears (as shown in the figure), although the model is still able to continue running. Why does this happen? In addition, I ran some tests and found that if I label two non-adjacent regions, there is no error. But if I label two adjacent regions, then the error appears. So does this mean that the mask file is incorrect?
This warning comes from the EMIS_DEFN.F file in CMAQv533 (CMAQ/CCTM/src/emis/emis/EMIS_DEFN.F at 5a2ab32fa9fa49dd3c966ed10ddadce8120c97b0 · USEPA/CMAQ · GitHub). It appears to be triggered when a negative emission value is calculated to be assigned to the OTH ISAM tag. I think you are on the right track to look at the mask file. If you take the sum of all the region mask variables from the mask file, are there any grid cells where the sum is greater than 1? Your testing that finds no warning is raised when using non-adjacent regions but is raised when using adjacent regions leads me to suspect that this may be the case for grid cells that include parts of two or more regions. That could explain how a negative value is calculated to be assigned to OTH.
Whether it is a problem depends on the specific situation. It is just a warning after all, and the code does have some logic to handle this situation (L671-L695 of EMIS_DEFN.F). If the sum of the region mask variables are exactly 1 or very close to 1 in all the grid cells, and the results look reasonable based on the location and magnitude of the sources/regions corresponding to the different tags, then maybe it is not an important issue for this case and the warning can be ignored.