I see you have edited your initial response which contained some good questions. I will respond to your initial response since this discussion may be of interest to other users as well.
- I am not sure how to know which species are tree, forest, or croplands for BELD3 although I could see the species classification for BELD4 (not BELD3) at https://www.cmascenter.org/sa-tools/documentation/4.2/html/raster/Raster_Users_Guide_4_2.htm#_Toc389118706
Are BELD3 and BELD4 classifications the same?
No, the BELD3 and BELD4 classifications are not the same.
All variables in the beld3_b files represent forest LU types (Oak_chinkapin … Yellowwood)
The variables in the beld_a files are a bit more varied (in the beld_a file for tile10, variables 1 - 19 are USGS types variables 20 - 35 are crop types, and variables 36 - 84 are tree species; in any beld_a file, crop variables and tree species types are always ordered alphabetically):
Forest (tree types): Ailanthus … Oak_chestnut
Non-forest (crop types): Barley … Wheat
For the USGS types, my best guess for assigning forest / non-forest is as follows, but others may want to review this and provide alternate suggestions for categories like USGS_mxtundra. However, note that the dust code does not expect the USGS forest types to be part of the FOREST variable (see your post above) so you should not include any of these when computing FOREST.
Forest (USGS types): USGS_cropwdlnd USGS_decidforest USGS_evbrdleaf USGS_coniferfor USGS_mxforest USGS_wetwoods USGS_woodtundr
Non-forest (USGS types): USGS_urban USGS_drycrop USGS_irrcrop USGS_cropgrass USGS_grassland USGS_shrubland USGS_shrubgrass USGS_savanna USGS_water USGS_sprsbarren USGS_mxtundra USGS_snowice
- By the way, can BELD4 data be used instead of BELD3 for inline DUST emission?
Unfortunately, not at the moment. It appears that the land use categories included in the BELD4 file generated by the spatial allocator do not contain all the categories expected by the CMAQ dust module when CTM_WBDUST_BELD is set to BELD4. We are investigating this issue and plan to update the code and/or model documentation in the future.
- And can we trust ‘tot_a’and ‘tot_b’ files considering misleading/incorrect data distributed in this case?
The BELD3 tiles provided with the spatial allocator are quite old (they seem to have been created in the early 2000’s). However, the content of the beld3_a and beld3_b tiles appears reasonable to me, it is only the FOREST variable in the beld3_tot tiles that is clearly wrong. I performed a quick test where I summed up all the LU percentages in the beld3_a and beld3_b files for tile10 and the sum was very close to 100%, with values ranging between 99.94% and 100.05%.
This suggests that you could indeed pursue summing over all forest LU percentages from the beld3_a and beld3_b files to derive a FOREST variable which you would then store in a newly created beld3_tot file. As noted above, this summation should not include any of the USGS types. Alternatively, you could compute the FOREST percentage by computing 100% - sum [all non-forest LU percentages from the beld3_a and beld3_b files] - there are more forest percentages than non-forest percentages in these files so this may be quicker to code. Given the slight deviation from 100% when summing over beld_a and beld_b files, you would also want to bound the calculated FOREST variable between 0% and 100%.
Alternatively, as mentioned in my initial response above, you could pursue using MCIP LU information for the dust module by setting CTM_WBDUST_BELD to UNKNOWN.