BELD5-compliant input files for WBDUST in CMAQv5.3.2

Spatial Allocator
1

WIth the introduction of BELD5 in SMOKEv4.8, I have been able to generate the B3GRD file needed for BEIS3.7 inline biogenic emissions in CMAQv5.3.2 using the aggwndw and normbeis3 tools in SMOKE. Would it be possible to generate the DUST_LU_1 and DUST_LU_2 input files for inline windblown dust emissions in CMAQ? I see only convert_beld3.csh and convert_beld4.csh shell scripts that use the $SA_HOME/bin/32bits/beld3smk.exe and $SA_HOME/bin/32bits/beld4smk.exe, respectively. Maybe I can make minimal changes to beld4 code from experts and recompile to get a beld5smk.exe?

2

What grid are you trying to create the dust files for?

3

Thanks for responding @eyth.alison ! For now, 36US3 grid files are more urgent, but eventually, I will also need for 12US1 (or 12US2 also works).

4

Hi @skunwar,
Thank you for your question. The windblown dust module in CMAQ does not support the use of BELD4 or BELD5 data.
The alternative we suggest is to set the environment variable CTM_WBDUST_BELD to UNKNOWN in your CCTM run script. This option allows you to use land use information provided in your MCIP meteorological input files for the windblown dust calculations.

Here is the section in our User’s Guide Appendix:

5

Thanks. Actually, I have been using the setenv CTM_WBDUST_BELD UNKNOWN option in CMAQ but I am not noticing any contribution from the windblown dust module to PM25_SOIL_AVG in the calc_tmetric postprocessed CMAQv5.3.2 output:

image
image1217×492 215 KB

The left figure above is with biogenic and dust emissions activated, and the right one is with dust off, biogenics on. I am not sure they are different, so I was thinking using a new BELD5 land database might change it.

6

Hello @skunwar,
I have the same problem as you have. Windblown dust and PM2.5_SOIL are not properly captured by CMAQv5.3.2. PM10 and PM2.5 are extremely low compared with observational data no matter we are using the setenv CTM_WBDUST_BELD BELD3 or UNKOWN option. The problem is friction velocity (U*) seems too low to generate promised particulates from erodible soil surface. The modeling results of PM10 caused by windblown dust gets better if we use U* directly from WRF/MCIP because, at least for my case, the U* from WRF/MCIP is generally greater than re-calculated U* by dust module in CMAQ.
On the other hand, land use information provided by BELD3 data is outdated for 2016 or later. We are looking forward to the updated windblown dust module supporting the application of BELD4 and BELD5 data.
Thanks.
Feng

7

Hi @skunwar, @FengLiu,
Thank you for sharing your experience with this CMAQ option. I have spoken to several team members about the issue you are seeing. Our internal development and application of the WBD option has largely been limited to WRF simulations using the PX land surface model (LSM). Moreover, the WBD option in CMAQv5.3+ relies on updated PX LSM vegetation fraction information that is available only in WRFv4.1+.
Our simulations driven by WRF fields using the PX LSM do show dust and, in fact, we encountered cases where the PM2.5 would spike to very high levels and were due to the estimated dust emissions probably being unreasonably large. Your experience with seeing very low windblown dust in your simulations could be due to a mismatch of land use, vegetation fraction, and/or soil moisture information in the WRF simulation you are using (perhaps with a different LSM such as Noah?) and what the CMAQ WBD module is expecting. We have team members that are going to investigate this further but at this time we can only support questions that relate to using the WBD module with WRFv4.1+ and PX LSM. We will update our documentation to make this more clear to other users, so again we appreciate your feedback.

8

We had some further discussions on this topic within our group. Based on these discussions, here is some additional information on our understanding of the current WBD scheme’s dependency on various inputs.

  • The CMAQ WBD module requires information about fractional land use. While the WRF PX LSM provides this information, in our understanding this isn’t necessarily the case for the default configurations of other WRF LSM options. The CTM_WBDUST_BELD option in CMAQ is a potential alternative to providing fractional land use information to the WBD module if this information isn’t available from the WRF LSM, but it doesn’t address the other WRF LSM related issue discussed in the next bullet

  • The LSM options in WRF differ in their definition of the depth of the first soil layer. For the PX LSM, that depth is 1 cm while to our knowledge it is 10 cm for the default version of the NOAH LSM. Soil moisture in the first soil layer is used in the CMAQ WBD module calculations, and the parameterizations in the code were developed based on WRF layer 1 soil moisture provided by the PX LSM (i.e. at 1 cm). Given that the NOAH LSM has a deeper first soil layer, soil moisture would generally be expected to be higher, suppressing the generation of WBD using the current parameterization expecting soil moisture for a 1 cm deep layer.

  • The CMAQ WBD scheme also relies on the vegetation fraction provided by the WRF LSM (wrfout variable VEGF_PX if the PX LSM was used and VEGFRA for other LSM). For the CMAQ WBD scheme to work, it is important for this vegetation fraction information to exhibit accurate seasonal and spatial variations. We know that this is the case for vegetation fraction information provided by the PX LSM in WRFv4.1+ but we have no experience with using vegetation fraction from other LSM.

This reiterates the point made above by @foley.kristen that at this time we can only support questions that relate to using the CMAQ WBD module with WRFv4.1+ and PX LSM.

If there are users in the community who are performing model development work to expand the WBD module to work with other WRF LSM, we would like to hear about your experiences.

@skunwar and @fliu, would you mind providing the following information about your runs in which you experienced very low or even no WBD?

  • WRF version and LSM option
  • MCIP version
  • Did the WRF LSM provide fractional land use information (LUFRAC_## in GRIDCRO2D for MCIP < 5 or LUFRAC in LUFRAC_CRO for MCIP5), i.e. were the values of these variables all 0 and 1 or were they fractions?
1 Like
9

Thanks @hogrefe.christian for sharing the information.

For my runs, I have used:

WRFv3.9.1.1
LSM option NOAH
MCIPv5.1
LUFRAC_CRO output file from MCIP does have the variable LUFRAC shown below:
image

image
image905×706 85.2 KB

I am seeing in this VERDI visualization of LUFRAC that (1) even though units are percentage, values might be fraction, and (2) the US and Mexico have less than 0.1 value (or it may even be 0!) and only parts of Canada have higher values.

10

Thanks, @skunwar.

The plot suggests that fractional land use information was made available to CMAQ in your runs. The coverage would be different from the one you plotted if you looked at different “layers” (land use categories), and presumably many of them would have coverage in the U.S. as well. The sum over all “layers” (land use categories) should be 1 since this variable represents the fractional coverage of each land use category in that grid cell. You are correct, the units should be “fraction”, not “percent”, we’ll have to update that.

When you ran MCIP, was the fractional land use information available from your wrfout files, or did you have to set IfGeo to T and provide a InGeoFile file?

11

Thanks for clarifying @hogrefe.christian, I actually read in geogrid file through IfGeo and InGeoFile options in MCIP runscript - I don’t see LANDUSEF variable in my WRF output files.

12

Hello @hogrefe.christian,

Thank you very much for the updates.

Please find the following information about our WRF model runs:
WRFv4.2.1
MCIPv5.0
Unified Noah land-surface model is used in WRF as shown in namelist
sf_sfclay_physics = 91,
sf_surface_physics = 2,

MCIP outputs provide fractional land use information by LUFRAC_CRO with 40 layers.

I am working on WRF with PX LSM according to your message.

BTW, one important thing is BELD3 is outdated for current nationwide landuse. We do need to move on to BELD4 or BELD5.

Thank you very much.
Fliu

13

Thanks @skunwar, @FengLiu and @fliu for your updates.

For the issue of BELD3 vs. BELD4/BELD5, our current thinking is that future model releases may remove the option to use any version of BELD to obtain fractional land use information, instead requiring this information to be available through the MCIP files. No decision has been made, but since it seems possible to provide fractional land use information for any WRF LSM through MCIP (either because the wrfout files already contain this information for some LSM, or by using the MCIP IfGeo and InGeoFile option if this information isn’t in wrfout), there shouldn’t be a need for providing a separate fractional land use data set to the WBD module. Eliminating this option would eliminate the need to update this portion of the code as BELD evolves. In addition, BELD data is generally not available outside North America so requiring this information through MCIP would be the more generalized approach. The historic reason for obtaining this information from BELD3 likely was that it was not always possible to obtain fractional land use output from WRF. If you have any concerns about this potential change, please let us know.

For the compatibility issues between the current implementation of the CMAQ WBD scheme and the WRF NOAH LSM - in particular the issue of the first layer soil depth - you might be interested in a WRF sensitivity simulation performed by our former colleague @Patrick.C.Campbell who modified the NOAH LSM to use a 1 cm thick first layer instead of a 10 cm thick first layer and then used outputs from that modified version of WRF to drive the CMAQ with the WBD option turned on:

https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2018MS001422

Our understanding is that most of the NOAH updates described in this paper - but importantly not the change of the first layer thickness that affects the CMAQ WBD calculations - have been implemented in the public version of WRF.

We should also note that the following statement in this paper “When running the unmodified off‐line WRF/Noah‐CMAQ, the soil moisture and temperature are adjusted in CMAQ from 10‐ to 1‐cm depth based on Darmenova et al. (2009), which creates additional uncertainty in model predictions” referred to an internal development version of CMAQ that was not publicly released. In the current public release version of CMAQ, no such adjustment is performed, and the WBD module expects layer 1 soil moisture to represent a depth of 1 cm.

1 Like