Hi all, I’m getting extreme low O3 concentration in my model simulation, almost no O3 over whole CA domain. I tried debugging it for a long time but couldn’t figure it out. Two example log files are attached here if you want to see the log before trying my simulation. The model ran without stopping. In second file (20100924) I got a warning saying EBI Euler convergence failure. I’m not sure if this matters so I just upload the log file here. CTM_LOG_000.s07tic_ae7i_intel_CA12KM_2010_09_v3_20100921.txt (480.0 KB) CTM_LOG_002.s07tic_ae7i_intel_CA12KM_2010_09_v3_20100924.txt (486.1 KB)
The model version I’m running is 5.3.1. The icbc files were generated from mozart using mozart2camx tool. The met files were generated using mcip. The emission files were generated using our own code as we’re using a local emission inventory. We’ve checked that the emission files could be read by CMAQ. These input files were also used in our own model (not the exactly same format, but should be same). Our own model results looks normal. But when using CMAQv5.3.1, the ozone concentrations were extremely low. I got a large Ozone hole over the whole domain.
The chemical mechanism I used is saprc07tic_ae7i_aq. There are some species having different names between emission files and cmaq, so I also modified the EmissCtrl file to make sure those species were read.
The first thing I’d do is to do a crude check of the emissions files against others (possibly on a different grid) from SMOKE that generate reasonable results for CA using M3Tools program m3stat. In order to do this, you need to know that CMAQ expects emissions in non-interpolatable, non-MKS units of mass per grid cell, so the appropriate comparison is between statistic/grid-cell-area for the various statistics (mean, max, etc.) produced by m3stat.
So if your file F1 on a 5KM grid (25KM^2 cells) has mean M1 at a particular date&time, whereas reference file F2 on a 4KM grid (16KM^2 cells)has mean M2 at that date&time, then what you need to compare is
Thanks for the advice. I compared my emission files with previously SMOKE-generated NEI emission files. My own area emission files have 10 times higher domain-averaged NOx emission rates than the NEI area emission files. The NOx emission rates in my inline pt emission files are 2 times higher than the NEI inline pt emission files. The VOCs in my own emission files are also higher than the NEI emission files.
However what I don’t understand is that when our own model also uses these emissions, the predicted O3 concentration looks fine. But when these emissions are put in CMAQ, we get almost no O3 concentration in the results. I know it’s very hard to compare two models that have different algorithms. Therefore I’m reducing the model complexity to see when the two models’ results agree. Currently I’ve turned off the chemistry and set all wind fields to zero to disable the transport. But I’m still getting different results. Can I ask if I can manually set the mixing layer height in CMAQ to a desired constant in the source code? I observed that mixing layer heights for our own model and CMAQ are different. I wonder if this causes the divergence of model results.
I do not understand what you mean by “extreme low O3 concentration in my model simulation, almost no O3 over whole CA domain”. I did not examine the spatial variation or anything, but the peak O3 concentration I see in your ACONC file is 0.141 ppm, or 141 ppb. This is not extremely low.
Hi, the file I uploaded was the first day result, which does not have a significantly low O3 concentration. I just uploaded the fourth day result (CCTM_ACONC_s07tic_ae7i_intel_CA12KM_2010_09_v3_20100924.nc). It has a peak O3 concentration of 56 ppb which is contributed from the boundary condition. In the center of the domain, there’s a large area where O3 concentration is below 1 ppb.
I am facing something similar with my cases, and not only with O3, also with other pollutants (NO2, CO), and thus I am looking for some ideas in this forum. But I would say that in my case the problem is relate to the number of vertical layers. My previous simulations were generated with CMAQ v5.2.1, which they were fine. However, we are now using the version 5.3.1. Both used the SMOKE v4.6 to generate the emissions file (one point file with 20 layers, one area file with 1 layer and one biogenic file also with 1 layer), then I used the smk_mrgall in order to generate only one file. Now I am wondering why the surface emissions are very low. Some settings tat was used:
set NZ = 23
setenv CTM_EMLAYS 20
setenv CONC_BLEV_ELEV “1 1”
setenv ACONC_BLEV_ELEV “1 1”
setenv APMDIAG_BLEV_ELEV “1 1”
setenv N_EMIS_GR 1
set EMISfile = emissions.ncf
setenv GR_EMIS_001 {EMISpath}/{EMISfile}
setenv GR_EMIS_LAB_001 GRIDDED_EMIS
setenv N_EMIS_PT 0
I am performing another test with CMAQ v5.3.1 (the WRF settings were left unchanged) which I left the script like that:
set NZ = 23
##setenv CTM_EMLAYS 20
setenv CTM_PT3DEMIS Y
setenv CONC_BLEV_ELEV “1 1”
setenv ACONC_BLEV_ELEV “1 1”
setenv APMDIAG_BLEV_ELEV “1 1”
setenv N_EMIS_GR 1
set EMISfile = emissions.ncf
setenv GR_EMIS_LAB_001 GRIDDED_EMIS
setenv N_EMIS_PT 0
@RockeyZ Does your gridded emissions file contain more than one layer? Do you have inline point sources (is CTM_PT3DEMIS set to TRUE)? Are you setting or overriding CTM_EMLAYS?
Just trying to figure out if your situation is similar to that of @ykaore or not.
We have installed a few error/warning protocols in the emissions mapping routine that I think would be good to use in this case to make sure the link between the CMAQ Emissions Module (DESID) and your emission input files is robust.
Please do the following:
Set CTM_EMISCHK to TRUE in your runscript. This will cause the model to crash if anything suspicious is detected in the mapping.
Now in the Emission Control File:
Comment out any lines referring to WBDUST. It looks like you’ve turned wind-blown dust off in the runscript.
Comment out the lines for “PT_FIRES”, “PT_RXFIRES”, “PT_AGFIRES”, “PT_OTHFIRES”, “PT_FIRES_MXCA” and “GR_RES_FIRES”. It doesn’t look like you’re using any of these.
Comment out the lines for “PMFINE_XXX” species where XXX equals NO3, NH4, FE, AL, SI, TI, MN, OTHR, LVPO1, and LVOO1. Also comment out “PMCOARSE_NO3” and “PMCOARSE_SOIL”. These species are for wind-blown dust speciation and again, it looks like you have it off.
Based on the log file you sent, you will still get model crashes. This is because the code is looking for a number of surrogates like “HONO”, “AACD”, “PACD”, etc on the emissions input files and not finding them. Verify that they should be there or that they should be removed from the Emission Control File. Get rid of all the ones that should be removed until the code proceeds normally.
Once the code is running, turn on the emissions diagnostic output by using the EMISDIAG environment variable in the runscript:
set EMISDIAG 2DSUM
Now you will be able to visually inspect the diagnostic output files (EMDIAG) to confirm they are reasonable. Note that they won’t exactly match your input files because CMAQ is printing the values in the middle of the closest time step to the hour. For example, if time steps are 5 mins long CMAQ won’t be printing values at 01:00:00, it will be at 00:57:30, or 2 mins and 30 seconds into the 5 min timstep proceeding the 1 hour output step. We’re going to revise this in the future, but for now, the diagnostic values should still be close to those on your input files.
Once you’ve inspected this, there could be other issues at play. We’ve tried to expand the features using the UNITS field on the input files. So if these aren’t in a format that the module is expecting, it might lead to order of magnitude problems from erroneous unit conversions.
Another issue could be molecular weight. CMAQ will now try to perform mass-mole conversions if called for using the molecular weights it knows about typical SMOKE surrogates. If your emission input surrogates are not typical, then we just need to teach CMAQ how to interpret them by assigning them a molecular weight. In most cases though, we try to avoid mass-mole conversions if possible so that we can avoid this exact vulnerability. Again, the diagnostic output file will help us understand if this could be a problem or not.
I performed some tests, and here are some results for NO2, CO, SO2 (the O3 results seems similar when comparing the results of each version).
The black lines are the values observed in the monitoring station.
The blue lines are the previous results using the CMAQ v5.2.1
The others lines are overlapping and their values were close to zero.
I also segregated the emissions by source and performed new simulations separately, trying isolating the issue.
All these values were extracted from the first layer.
My gridded emissions files only contain the ground level emissions. I didn’t have either CTM_PT3DEMIS or CTM_EMLAYS set in my run script. Do I need to include them?
Thanks Ben! I’ll try what you suggest. Actually as I was debugging, I found that my emission generation codes had some small issue and I just fixed it. Hopefully I can expect a reasonable O3 concentration from CMAQ output this time.
Hello, I see your question. I now use the version of CMAQv5.2.1 to simulate the concentration of pollutants and find that the spatial distribution of ozone is normal, but the concentration of PM2.5, NO2, and SO2 is particularly low. So I also want to turn off the chemical reaction to check, how did you turn off the chemical reaction in the script settings?
It seems odd that the ozone field would be ‘normal’ but NO2 field would be too low. Is this the case after a couple of simulation days or have you only been able to look at the first day so far?
The easiest way to turn off the effects of chemical reactions on primary pollutants in the model is to comment out the call to the chemistry subroutine. Simply comment out the call to “CHEM” in sciproc.F and recompile. If you want to disable specific chemical reactions, you will need to do quite a bit more modification for v5.2.1.
A bit more information would be helpful in diagnosing this issue. How low are the primary pollutants compared to what you expect? Are they all low by the same relative change? Can you determine if they are of the right magnitude on the emission input file?
Hi, you could also refer to this post: Turning off chemistry mechanism in CMAQ if commenting out CHEM causes model crash. But it is a method for CMAQv5.3.1, so I don’t know if this would also work for v5.2.1. Hope this could be helpful.
Hello, thanks for your reply. I simulated the situation throughout January of 2020. After the combine operation, the spatial distribution has such a problem. My spatial distribution map looks like this. It is relatively reasonable for me to simulate the distribution of January 2017 with the same emission inventory and different meteorological documents. So the emission inventory should be correct. The simulated 2017 average PM2.5 concentration is about 35 times the average in January 2020.
