Hi,
I am using CMAQ v5.3 to simulate windblown dust and to estimate contribution of windblown dust to PM10. I noticed that PM10 calculation in the mechanism “cb6r3_ae7_aq” can be found in the file “SpecDef_cb6r3_ae7_aq.txt” as below:
!! PM10.0 and Coarse-Sized Species
PM10 ,ug m-3 ,ATOTI[0]*PM10AT[3]+ATOTJ[0]*PM10AC[3]+ATOTK[0]*PM10CO[3]
Anyone can explain this equation and tell me what those items mean.
Another question, does this PM10 calculation include SOIL and PM2.5? If yes, why PM10 concentration processed with the combine is very small and even less than ASOIL concentration in CCTM_ACOUN file based on my CMAQ runs during high wind days. It is definitely not what I want if I need to estimate contribution of windblown dust to PM10. Thank you very much in advance for your time to help and reply.
The equation you copied from SpecDef_cb6r3_ae7_aq.txt shows that PM10 is computed as the sum of the aerosol mass in the Aitken (ATOTI), accumulation (ATOTJ), and coarse (ATOTK) modes, each multiplied by the fraction of those modes that contribute to PM10 (i.e. has a particle diameter < 10 um)
If you look for the definitions of ATOTI, ATOTJ, and specifically ATOTK further up in the SpecDef file, you will see that the definition of ATOTK includes ASOIL. If PM10 is less than ASOIL, this implies that the PM10CO factor (i.e. the fraction of the coarse mode aerosols that has a particle diameter < 10 um) is less than 1, maybe substantially so. This in turn implies that a non-negligible fraction of your total aerosol mass (ATOTIJK) is associated with particles > 10 um.
The cutoff fractions used here (PM10AT, PM10AC, and PM10CO) as well as those used for other size cutoffs (PM2.5, PM1, and AMS) are discussed in the description of the CCTM_APMDIAG and CCTM_PMDIAG files from which they are obtained by combine. Their description can also be seen by looking at the var_desc attribute in these files:
PM10AT:var_desc = PM10 fraction of Aitken mode
PM10AC:var_desc = PM10 fraction of accumulation mode
PM10CO:var_desc = PM10 fraction of coarse mode
Christian Hogrefe,
Thank you so much for the detail explanation. I now see that PM10 calculation from SpecDef_cb6r3_ae7_aq.txt includes all fractions that contribute to PM10.
Two more questions: 1. what does numbers [0] and [3] in the PM10 equation mean?
2. what kind of situation or conditions can lead to PM10CO factor < 1? If this is the case, I could get higher PM10 after I removed PM10CO in the equation, am I right?
The numbers in the square brackets following a species in the SpecDef file refer to the number of the input file (INFILE1, INFILE2, INFILE3, etc.) specified in the ‘combine’ run script from which that species should be read. For example, PM10AC[3] means that the variable PM10AC should be read from INFILE3 specified in the run script, i.e. the CCTM_APMDIAG file. [0] is an exception and is used to refer to a species previously defined in the same SpecDef file. For example, ATOTK[0] refers to the aggregate species ATOTK previously defined in the SpecDef file as the sum of all coarse mode species:
Variables from input files are defined by their name followed by its file number enclosed in brackets. Once defined in a species definition file, variables can subsequently be referred to by their name and the number zero enclosed in brackets.
Since CMAQ aerosols are represented by a modal rather than a sectional framework, the size distributions of each mode span a range of diameters. If your goal is to compare CMAQ aerosol mass to PM10 observations, using the PM10 definition with the cut-off fractions applied is the proper approach since the measurements would not include any aerosols with diameters > 10 um. If, on the other hand, your goal is to calculate CMAQ total aerosol mass, not applying the cut-off fractions when summing ATOTI, ATOTJ, and ATOTK would accomplish that (and is already done when calculating ATOTIJK).
Christian Hogrefe,
Thank you so much for such a nice clarification.
I now need to double check why I got much lower PM10 from windblown dust during high winds compared with PM10 observations. BTW, I turned off all anthropogenic emissions.
Thank you again.
Christian Hogrefe,
I checked my CMAQ outputs of windblown dust run, modeled PM10 concentrations are much lower compared with observational data, which is not what as I expected over sand or vacant area under WRF windy conditions. I also noticed that emission of PMCOARSE_SOIL is pretty small in eroded area. Do we need to adjust threshold velocity and have a lower threshold velocity for producing more dust? Alternatively, should we invest more time to do something else to improve CMAQ ability to simulate windblown dust?
BTW, I used BELD3 land use data for this run. I plan to switch to WRF/MCIP land use to run CMAQ model.
I am looking forward to your inputs. Thank you very much.
Unfortunately, this is outside my area of expertise.
If you are considering making code updates for your simulations, you probably would want to start by reading the paper by Foroutan et al. (2017) which documents the key processes and parameters in the current implementation of wind-blown dust in CMAQ.
Christian Hogrefe,
Yes, I did read the paper you mentioned. “We argued that the WRF‐modeled friction velocity should not be used as an input to the dust emission parameterization since it represents the surface roughness at a different scale. Instead, the friction velocity should be recalculated with a “microscopic” roughness length relevant to the dust generation phenomena…” according to the paper. I will take a look at the code and see how to recalculate U* actually. Thank you for your reply.
Feng
Feng,
Please note that following the argument you quoted, U* is indeed being updated within the dust scheme in CMAQ. Can you please provide information about the version of WRF and the land surface scheme being used in your simulations.Thanks.
Hello Hosein Foroutan,
It is nice to get your response. Thank you.
Yes, I noticed that module dust_emis in the CMAQ system is used for re-calculating the U*. For your question, please find some information about inputs to WRF and CMAQ as following:
I used WRF4.1.1.
geog input data for WPS: geog_data_res = ‘nlcd2011_9s’.
The physics schemes including pbl and land surface schemes for the first WRF/CMAQ run I discussed here are:
bl_pbl_physics = 2,
sf_sfclay_physics = 2,
sf_surface_physics = 2,
Land use data used in CMAQ: EPA BELD3.
BELD4 does not work so far and please refer to the post Errors in inline windblown dust using BELD4 data with CMAQv5.3.
I am going to try to use “unknown” option to use MCIP land use, and have yet to get the results.
I also tested other schemes in WRF including ACM2
bl_pbl_physics = 7,
sf_sfclay_physics = 7,
sf_surface_physics = 7,
num_soil_layers = 2,
In addition I also tested MYJ, MYNN2, and MYNN3 pbl schemes using the latest WRF4.2.1. Because high quality wind simulations is the most important factor in CMAQ windblown dust modeling. I did not use those WRF runs to drive CMAQ windblown dust because NONE of those WRF outputs provides satisfied wind speeds based on WRF model performance evaluation using AMET1.4 .
You mentioned in the paper that “global MODIS FPAR data in the MOD15A2 product at 1 km resolution and every 8 days [ Myneni et al ., 2011] are processed and regridded onto the computational domain…” I did not find the 8-day MOD15A2 data or data processor for WRF input. I just found monthly GREENFRAC (vegetation fraction). Is that users’ responsibility to process 8-day MODIS FPAR?
Soil moisture from WRF/MCIP should be re-calculated by factor 0.1 according to your paper when Noah LSM land surface model is used (as my first case described in Section 4 above). Do I have to manually do that by updating the code or we have set a switch in the CMAQ system to realize that? ( I did not check the code myself).
Thank you very much for taking the time to check and reply.
Feng
Your model setup seems fine to me. To answer your two questions:
1/ In CMAQ v 5.2, the vegetation fraction used in the dust module could be provided by either year-specific, 8-day resolution data (as we used in the paper) or climatological (10 year average) monthly GREENFRAC from MODIS. See this post explaining the details and how to generate the data: https://github.com/USEPA/CMAQ/blob/5.2/DOCS/Tutorials/CMAQ_DustInput.md
Now, a new update seems to go in for CMAQ v 5.3 such that this vegetation fraction be read directly from PX LSM. Provided that 1) WRF v4+ is being used and 2) “pxlsm_modis_veg = 1” in WRF, the vegetation fraction should then be the time-varying parameter that was recommended in CMAQ v 5.2. See here: https://github.com/USEPA/CMAQ/blob/master/DOCS/Users_Guide/Appendix/CMAQ_UG_appendixE_configuring_WRF.md
The best way to check this will be to look into DUST_DIAG file and inspect values of “veg frac”. If values are too high (which obviously suppress the dust uplift) it shows CMAQ uses vegetation from PX LSM look up table rather than MODIS data.
Hosein Foroutan,
Thank you very much for your response to my questions.
On your answer to my first question, I checked my GEOGRID.TBL in WPS, I did use rel_path=default:greenfrac_fpar_modis/ for GREENFRAC, please see attached GEOGRID.TBL.txt. However, geo_em.d01.nc still shows monthly green fraction other than 8-day one. Anyway I will use PXLSM using “pxlsm_modis_veg = 1” with ACM2 PBL scheme instead of correction of soil moisture from WRF. BTW, you can see from the attached I also used high resolution LAI. I have yet to investigate how resolution of LAI inputs influence soil dust emissions. Note that I am using CMAQv5.3.
On the answer to my second question, I conducted a test case yesterday using soil moisture factor of 0.1 to re-calculate U* in “dust_emis” module. The results show very high PM-10GEOGRID.TBL.txt (1.3 KB)
concentration even over-estimated compared with observed PM10 (see attached plot). The CMAQ output indeed shows significant difference between with and without the factor of 0.1. That means we reduced 10 times of U* value in the test case. However, the results are still far from promised ones as shown in your paper. I will get back to you soon with any updates on this topic.
Thank you very much.
Note that the soil moisture content itself and NOT the soil moisture factor should be changed in the code. The latter is calculated in the code using the former and based on the Fecan et al. (1999) parameterization. The relationship between soil moisture content and the threshold friction velocity (U*_t) therefore is not linear, so a 0.1 factor in soil moisture content does NOT mean a 10 times reduction in the threshold friction velocity (U*_t).
Hosein Foroutan,
Thank you very much for the comment and correction which really makes sense. I will go back to the code, re-build the system, and check PM10 output after updating soil moisture content.
Thank you again for your time.
