DUST_LU_2 file FOREST variable not correct

Spatial Allocator
1

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
image1232×579 64.8 KB

2

@lizadams or anybody - do you have any comments on it?

Thank you.

3

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
The following tar.gz file contains the files that are required by the benchmark case:

beld3_12US1_459X299_output_a_bench.nc
beld4_12US1_459X299_output_tot_bench.nc

4

The FOREST variable appears to be a percentage of land area covered by forest. The comparison plot for the benchmark case using VERDI is available here:

Screen Shot 2020-03-04 at 3.37.57 PM
Screen Shot 2020-03-04 at 3.37.57 PM1404×1198 35.4 KB

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.

5

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
Screen Shot 2020-03-04 at 3.54.30 PM1112×1376 180 KB

I will try using the Spatial Allocator routine that you are using and see if I can reproduce the benchmark file.

6

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.

7

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
Screen Shot 2020-03-04 at 5.35.33 PM1448×1434 148 KB

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.

8

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.

9

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.

10

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.

11

Which data specifically are you using?

12

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.

13

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!

14

@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

15

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

16

@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

17

@bbaek do you know where we can find the correct spatial allocator data to produce DUST_LU_2 file?
Thanks,

18

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.

19

Thank you, @hogrefe.christian, for the ideas.

21

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.

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.