# DUST\_LU\_2 file FOREST variable not correct **URL:** \ **Category:** Spatial Allocator\ **Created:** [February 13, 2020, 2:47pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305 "2020-02-13T14:47:11Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [February 13, 2020, 2:47pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/1 "2020-02-13T14:47:11Z")
Hi, I used the convert\_beld3\_64bits.csh, and convert\_beld4\_64bits.csh scripts in the spatial allocator to generate inputs for CMAQ5.3.1, and got generated the following files. beld3\_dom3KM\_output\_a.ncf, beld3\_dom3KM\_output\_b.ncf, beld3\_dom3KM\_output\_tot.ncf, and beld4\_dom3KM\_output.ncf. Note that beld4 has just one file created. The benchmark run indicates to use setenv DUST\_LU\_1 $LUpath/beld3\_12US1\_459X299\_output\_a\_bench.nc setenv DUST\_LU\_2 $LUpath/beld4\_12US1\_459X299\_output\_tot\_bench.nc That is beld4\_tot for DUST\_LU\_2; since I don’t have it, I was using beld3\_dom3KM\_output\_tot.ncf. (For DUST\_LU\_1, I was using beld3\_dom3KM\_output\_a.ncf). And beld4\_dom3KM\_output.ncf (this file has FOREST ). But the variable FOREST looks weird to me (shown in the screenshot, looks as if a mask for countries with values 1 and 0). Can you hint what’s going on wrong with my procedure. Thank you. ![image](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/1X/3f4ea671c86951897f23958ea72c0395f14b0f29.png) ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [February 19, 2020, 4:44pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/2 "2020-02-19T16:44:22Z")
@lizadams or anybody - do you have any comments on it? Thank you. ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 4, 2020, 8:11pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/3 "2020-03-04T20:11:31Z")
> [@CMAQ\_user](#): > > convert\_beld3\_64bits.csh Do you need the standard input files for the Benchmark case for CMAQv5.3.1? Or is your goal to verify that you can generate the DUST\_LU\_1 and DUST\_LU\_2 input files that we provide in the benchmark input tar.gz file? If you are using the benchmark case, check the following google drive location for the following input files: [https://drive.google.com/drive/u/1/folders/10wFNch1MkI49ZjD2XD6wK2xzDWOav2zY](https://drive.google.com/drive/u/1/folders/10wFNch1MkI49ZjD2XD6wK2xzDWOav2zY) The following tar.gz file contains the files that are required by the benchmark case: > **[CMAQv5.3.1\_Benchmark\_2Day\_Input\_20191219.tar.gz](https://drive.google.com/file/d/1m_v5BicazdxcDt23CRXxneqx5i6Y9AUD/view?usp=sharing)** > > Google Drive file. beld3\_12US1\_459X299\_output\_a\_bench.nc beld4\_12US1\_459X299\_output\_tot\_bench.nc ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 4, 2020, 8:41pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/4 "2020-03-04T20:41:17Z")
> [@CMAQ\_user](#): > > beld3\_dom3KM\_output\_a.ncf, beld3\_dom3KM\_output\_b.ncf, beld3\_dom3KM\_output\_tot.ncf, > and beld4\_dom3KM\_output.ncf. The FOREST variable appears to be a percentage of land area covered by forest. The comparison plot for the benchmark case using [VERDI](https://www.cmascenter.org/verdi/) is available here: ![Screen Shot 2020-03-04 at 3.37.57 PM](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/1X/962c391af98fb549c29758b1ce5c11c304073654.png) Your screenshot from ncview indicates it is using a displayed range from 0 to 1 percent? I will download ncview for comparison to see how it displays the benchmark beld4\_12US1\_459X299\_output\_tot\_bench.nc file. ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 4, 2020, 8:57pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/5 "2020-03-04T20:57:24Z")
I confirmed that ncview displays a similar range of 0 to 95.9264 percent for the FOREST variable using the benchmark beld4\_12US1\_459X299\_output\_tot\_bench.nc file. ![Screen Shot 2020-03-04 at 3.54.30 PM](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/1X/c62b7b5b4a6f1ef757e013a42527d84ff969c046.png) I will try using the Spatial Allocator routine that you are using and see if I can reproduce the benchmark file. ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 4, 2020, 9:20pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/6 "2020-03-04T21:20:25Z")
Thank you @lizadams, but I am not doing the benchmark case - it is for my domain, which extends a bit into Mexico too - but still within the North American domain for which the spatial allocator data is supposed to be there. I am waiting to see what happens with your trial with the script I was trying with. ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 5, 2020, 1:59am UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/7 "2020-03-05T01:59:34Z")
Hi again, I have reproduced the error that you are observing when trying to generate the landuse files for the GRIDNAME 2016\_12SE1 and using the GRIDDESC file provided with the benchmark data. When I ran the convert\_beld3\_64bits.csh script, 3 output files were generated: beld3\_2016\_12SE1\_output\_a.nc beld3\_2016\_12SE1\_output\_b.ncf beld3\_2016\_12SE1\_output\_tot.ncf The beld3\_2016\_12SE1\_output\_tot.ncf file contained the FOREST variable, and it had a range from 0 to 1 percent. I am including a screenshot of the result. ![Screen Shot 2020-03-04 at 5.35.33 PM](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/1X/45aba51e6dfabb6ab1259494cd9879cc8872faf3.png) I will also tried using the convert\_beld3.csh script, to see if there is any difference in the result, as the beld3smk.exe executable under the 64bits directory is more recent than the one in the 32bits directory, but it gave the same result. 9308928 Feb 26 11:10 /64bits/beld3smk.exe 6557799 Oct 18 2018 /32bits/beld3smk.exe It looks like there may also be issue with the other output files. I used the m3stat program to find the min, max of the files. > setenv AFILE beld3\_2016\_12SE1\_output\_tot.ncf > m3stat > Gave this as the REPORT > File: INFILE ``` Variable: FOREST 3-D grid statistics Max 1.00000E+00 @(c,r,l)=(31,1,1) Min 0.00000E+00 @(c,r,l)=(2,1,1) Mean 7.19852E-01 Sigma 4.45379E-01 ``` It almost looks like the program is calculating a value from 0 to 1 rather than 0 to 100 for the FOREST variable. I’ve also tried an earlier executable, but it gave the same result. I will look into this further. ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 5, 2020, 3:34pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/8 "2020-03-05T15:34:24Z")
I’ve checked the input files that the beld3smk.exe is using to regrid to a new grid using m3stat, and those input files have values for FOREST that range from 0 to 1. This issue may be due the b3\_tot.tile\*.nzero.ncf input files that are being distributed with the Spatial Allocator. ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 5, 2020, 4:02pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/9 "2020-03-05T16:02:07Z")
Thank you @lizadams for the replies. This has become a long-standing problem for me to get this done . Is there anyway to get the correct input data - this case makes me a bit more wary about the credibility of other data too that is distributed with the Spatial allocator. ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 5, 2020, 4:35pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/10 "2020-03-05T16:35:20Z")
Ok, the b3\_tot.tile\*.nzero.ncf files should have 0 or 1 values in it, so that probably isn’t the problem. I am downloading new input data from this location and rerunning the script just in case. > **[Biogenic Emissions Landuse Database, Version 3 (BELD3) | US EPA](https://www.epa.gov/air-emissions-modeling/biogenic-emissions-landuse-database-version-3-beld3)** > > BELD3 data provides distributions of 2030 vegetation classes at 1-km resolution over most of North America. These data are used by SMOKE to develop estimates of emissions from biogenic sources. ---
**Author:** ![eyth.alison](https://avatars.discourse-cdn.com/v4/letter/e/7ab992/32.png) [@eyth.alison](https://forum.cmascenter.org/u/eyth.alison)\ **Post date:** [March 5, 2020, 4:30pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/11 "2020-03-05T16:30:18Z")
Which data specifically are you using? ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 5, 2020, 10:31pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/12 "2020-03-05T22:31:24Z")
I am using: spatial\_allocator\_v4.3\_Feb2017.data.tar.gz I asked some other people, they also have the same problem as I do. I don’t know exactly what data they are using though. ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 6, 2020, 3:02am UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/13 "2020-03-06T03:02:09Z")
I am also trying with the same - but I am not hopeful! The input data’s ‘\_tot’ tile files show either 0 ro 1. Seems like some sort of ‘misleading’ data (regarding this case) is put everywhere! ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 6, 2020, 3:56pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/14 "2020-03-06T15:56:27Z")
@lizadams I tried with that ‘new’ data, but my script gave the same old thing -0 and 1. What did you get, and is there any alternative? Thanks ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [March 6, 2020, 5:13pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/15 "2020-03-06T17:13:00Z")
I am trying to track down whether the FOREST variable should be just an indicator to the WB\_DUST module if there is land or not (range 0 to 1) or if it should be a percentage of the grid cell that is covered by forest (0 to 100). Can you try to use the file generated by the Spatial Allocator in the CMAQv5.3.1 run for your domain? I am assuming that you are trying to run CMAQv5.3.1 with the Wind Blown Dust Inline Emissions Option turned on. I have been able to run with either version of the DUST\_LU\_2 file, and I do not see any impact to the ACONC output variables for the first day, unless I am doing something wrong in my run script setting. Perhaps it is only on the second day that you start to see differences, as the dust from the first day is used by the next day… I am currently turning on the WB\_DUST diagnostic flags in the cmaq run script to see if I can learn more. setenv EMISDIAG T setenv EMISDIAG\_SUM T setenv CTM\_DUSTEM\_DIAG Y Liz ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 6, 2020, 7:40pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/16 "2020-03-06T19:40:57Z")
@lizadams, yes you are right, I am running CMAQv5.3.1 with inline Dust option. I have run the simulations several times (while waiting for people to get reply on this topic) using the weird (’\_tot’ file with 0 and 1) output files produced by Spatial Allocator . However, I am not sure if that’s making a significant difference because I don’t have a reference correct input data, and also haven’t looked for such things as diagnostic outputs, as you mentioned. But clearly, as you have also shown above, for the benchmark case the values look very realistic - % of land covered by FOREST. And the use of this variable is dust prediction is being used for finding dust transport fractions - which is an important thing to consider - I believe. C building surrounding uland( c,r,3 ) = lut( c,r,1 ) ! USGS\_urban C forest surrounding uland( c,r,4 ) = lut( c,r,10 ) ! USGS\_decidforest & + lut( c,r,11 ) ! USGS\_evbrdleaf & + lut( c,r,12 ) ! USGS\_coniferfor & + lut( c,r,13 ) ! USGS\_mxforest & + lut( c,r,15 ) ! USGS\_wetwoods & + lut( c,r,20 ) ! FOREST (dust\_lu\_2) end do end do I wonder what to do to get the correct files for DUST\_LU\_2 ?? Thanks ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 8, 2020, 9:12pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/17 "2020-03-08T21:12:29Z")
@bbaek do you know where we can find the correct spatial allocator data to produce DUST\_LU\_2 file? Thanks, ---
**Author:** ![hogrefe.christian](https://avatars.discourse-cdn.com/v4/letter/h/74df32/32.png) [@hogrefe.christian](https://forum.cmascenter.org/u/hogrefe.christian)\ **Post date:** [March 10, 2020, 2:22pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/18 "2020-03-10T14:22:21Z")
A workaround for the incorrect FOREST variable contained in the “tot” file created by the spatial allocator would be to sum over all the tree species in the BELD3 “a” and “b” files, i.e. all LU percentages in these files except those for the USGS types and crop/agricultural species. This summation could presumably be accomplished using tools like “combine” or “m3combo”. As an alternative to providing BELD3 LU information to the windblown dust model, it can also be configured to only use LU information from MCIP. This is accomplished by either commenting out the line “CTM\_WBDUST\_BELD BELD3” in the run script or changing it to “CTM\_WBDUST\_BELD UNKNOWN”. As noted in Chapter 6 of the Users Guide, the MCIP LU information available for the dust module was updated in WRF4.1 with the Pleim-Xiu land-surface model (PX LSM) compared to the information available from the PX LSM in earlier versions of WRF. ---
**Author:** ![CMAQ\_user](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@CMAQ\_user](https://forum.cmascenter.org/u/CMAQ_user)\ **Post date:** [March 10, 2020, 5:50pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/19 "2020-03-10T17:50:50Z")
Thank you, @hogrefe.christian, for the ideas. ---
**Author:** ![hogrefe.christian](https://avatars.discourse-cdn.com/v4/letter/h/74df32/32.png) [@hogrefe.christian](https://forum.cmascenter.org/u/hogrefe.christian)\ **Post date:** [March 11, 2020, 1:42pm UTC](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/21 "2020-03-11T13:42:26Z")
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](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](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305/16)) 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. [Next page](https://forum.cmascenter.org/t/dust-lu-2-file-forest-variable-not-correct/1305.md?page=2)