I have run CMAQv5.4 along with HDDM to calculate EGU sensitivity. I want to quantify: APOMI variable which has formula like this in specDef file (attached here):
APOMI ,ug m-3 ,ALVPO1I + ASVPO1I + ASVPO2I + APOCI
SpecDef_aconc_cmaqv53_cb6r3_ae7_aq.txt (16.0 KB)
I wanted to check if COMBINE post processing tools output of APOMI value matches with sum of each individual species. To do this: I have VERDI formula bar and added each species (ALVPO1I, ASVPO1I, ASVPO2I, APOCI, and APNCOMI). By looking, the APOMI figure from combine file matches with sum of species got from CCTM_ACONC file.
Now, the problem starts. I have sensitivity output files. CCTM_ASENS, and I want to quantify APOMI value for sensitivity parameter. I have change the above specDef file by adding senstivity name at the end of each variable. The formula becomes like this:
APOMI ,ug m-3 ,ALVPO1I_ES2 + ASVPO1I_ES2 + ASVPO2I_ES2 + APOCI_ES2
Please see the attached file also:
SpecDef_asens_egus_ES2_cmaqv54_cb6r3_ae7_aq.txt (17.3 KB)
I used verdi to sum up each species and ran combine post processing tool using SpecDef_asens_egus_ES2_cmaqv54_cb6r3_ae7_aq.txt file. While comparing the two figure I don’t know why am I getting different figure?
I changed the axis values, however, the combine file is showing 0 value. This ultimately impacting my PM2.5 values. Can you please let me know how to resolve this?
I am also attaching my script and sensitivity file that I used for CMAQ run.
sensinput.ptegu.dat.txt (2.4 KB)
run_cctm_hddm_egu.csh_sbatch.txt (41.2 KB)
That scale-max on the right-bottom is quite suspicious: the max looks very much like the inverse of the I/O API “missing/invalid
-BADVAL3 = 9.999E36.
COMBINE has a number of bugs when it comes to propagating “missing” …
Have you tried using the SpecDef_cb6r3_ae7_aq.txt or SpecDef_cb6r5_ae7_aq.txt that is provided with CMAQv5.4? The appropriate file would be located in the BLD* directory that you created for CMAQv5.4 by running the bldit_cctm.csh script.
No, I have used specDef file from here: CMAQ/SpecDef_cb6r3_ae7_aq.txt at 5.3.3 · USEPA/CMAQ · GitHub
The reason for using this SpecDef is, I want to quantify PM2.5 for sensitivity parameter which I could not using v5.4 file. Therefore, I have used v5.3 SpecDef file.
This issue that I see is that the CMAQv5.4 output includes the ELMO and AELMO output files that are used in the 5.4 Species Def file, while CMAQv5.3.3 output includes the PMDIAG/APMDIAG that is used in the 5.3 Species Def file. If combine is looking for the PMDIAG/APMDIAG files due to the species definition file that you are using, and there are no such files, then you may be getting missing values.
SpecDef_cb6r3_ae7_aq.txt references the following files:
File : CMAQ conc/aconc file
File : METCRO3D file
File : PMDIAG/APMDIAG file
File : METCRO2D file
Contains reference to the following files:
/ File : CMAQ conc/aconc file
/ File : METCRO3D file
/ File : ELMO/AELMO file
/ File : METCRO2D file
Is this the formula you are comparing in VERDI?
APOMI ,ug m-3 ,ALVPO1I_ES2 + ASVPO1I_ES2 + ASVPO2I_ES2 + APOCI_ES2 +APNCOMI_ES2
On the left plot, I am not sure if you are seeing all zero values, or just really small values that are not distinguishable due to the formatting of the legend. To see the min and max of the value using Exponential formatting, change the following in VERDI:
VERDI > Create Tile Plot
Select Configure > Configure Plot
Select Color Map Tab
Change Number format from -2.3f to -2.3e
For the right plot, can you add the run script you are using for combine to this issue?
Please see the attached run script I am using for combine run.
03_run_combine_asens_egus_ES2.csh.txt (9.7 KB)
Please also provide the log file from the combine run.
Just seconding @lizadams here. Clearly something didn’t work as expected in your combine run, so you need to post not only your combine run script and SpecDef file but also your full combine log file for people to help you track down the problem. The first step when seeing strange output from combine is to examine the log file. As noted by @cjcoats , it’s not always as clear as it should be, but it’s a starting point nonetheless.
While waiting for your log file, I had a quick look at your run script and SpecDef file.
It seems in your DDM ASENS specdef file, you pretty much defined every single post-processed concentration species used in the “standard” file as a desired COMBINE_ASENS output species, including radicals like OH and HOX. Do you really need those in our analysis? My strong suspicion is that the COMBINE run crashed, showing exactly which species defined in SpecDef could not be calculated because the required input species isn’t part of ASENS. Combine will crash upon the first such error, so all species defined after that, and all 23 time steps after that for all species will be missing until you start the combine run for the next day.
The solution is that you need to edit your SpecDef file to a) only include what you really need in your analysis and comment out everything else, and b) verify that all species referenced from the ASENS input file actually exist in that input file.
Thank you for your suggestion @hogrefe.christian @lizadams . I have looked into log file.
ES2_asens_combine_cmaqv54_dep_conc_cb6r3_ae7_aq_batch_707851.out.txt (2.8 MB)
I see there’s an issue in the log file saying:
Problem evaluating: AOMIJ/AOCIJ
Denominator, AOCIJ, equals zero.
After this problem, combine did not write any other species data and went to next day and so on.
I have traced back the problem in SpecDef file. I have looked into following species:
AOMIJ ,ug m-3 ,APOMIJ + ASOMIJ
AOCIJ ,ugC m-3 ,APOCIJ + ASOCIJ
APOCI ,ugC m-3 ,ALVPO1I_ES2/1.39 + ASVPO1I_ES2/1.32 + ASVPO2I_ES2/1.26
Finally when I looked into ALVPO1I, ASVPO1I, ASVPO2I, APOCI in ASENS file, i see these values are
0 (Please see attached image)
This leads into infinity scale. Now if I comment out following line in SpecDef file the combine runs fine:
ES2_asens_combine_cmaqv54_dep_conc_cb6r3_ae7_aq_batch_709701.out.txt (910.5 KB)
!!! OM/OC ratios
!AOMOCRAT_TOT ,ug ug-1 ,AOMIJ/AOCIJ
Is it the right approach I should follow?
Is it normal to get 0 value for ALVPO1I_ES2 and other variables?
After this (commenting out OM/OC ratios), I get PM25_TOT like this for different sensitivity parameters:
ES2: first order SO2 sensitivity from EGUs
ENX first order NOx sensitivity from EGUs
2NS second order NOx and SO2 sensitivity from EGUs
2NX second order NOx sensitivity from EGUs
2S2 2nd order SO2 sensitivity from EGUs
The infinity scale in 2S2 plot is due to ALVPO1I_2S2 values are infinite.
Overall, Am I following the right approach?
Given that your OC sensitivities apparently end up being zero at least for some grid cells (your plots actually show structure, and even though VERDI by default only shows three significant digits that suggest your min/max values are zero, you can change the scale to see that they are not exactly zero everywhere), commenting out the OM/OC calculation is the right approach. I now see that we actually discussed this very same combine run issue 30 days ago in this thread, and the solution was exactly the same.
None of your second order sensitivities shown in your plots appear reasonable, but this is likely not a combine issue, you probably see unreasonable second order sensitivities for one or more individual PM species in ASENS. combine is computing what it’s being asked to compute, but the very high / infinity values originate from the ASENS files themselves, not combine (in addition to the strange PM25_TOT plot for 2S2 you mentioned, the PM25_TOT plots for 2NX and 2NS show min and max values of infinity, so even though the color scale just shows zeros, the values themselves are not meaningful). So, this isn’t a combine question, but a DDM question that should have its own thread for other people to offer suggestions. In tracking this down, rather than jumping straight to PM25_TOT, I would look at the second order sensitivities (2NX, 2NS, 2S2) for individual species in ASENS or aggregates species like SO4, NO3, etc. in the COMBINE_ASENS file.