Is it appropriate to linearly interpolated zero plane roughness length config values from the roughness lookup table?

[aaraney]

Looking at the provided example configuration files and the readme instructions for calculating zero plane roughness length, the only way i'm coming up with something close to 0.0003 is by linearly interpolating between the values in the roughness class roughness length(m) lookup table. Is that how the look up table is supposed to be used?

vegetation_height_m=0.12
zero_plane_displacement_height_m=0.0003

source

Roughness class	Roughness length(m)	Landscape Type
0	0.0002	Smooth water surface
0.2	0.0005	Inlet water

zero_plane_displacement_height_m = y1 + (x - x1) * (y2 - y1) / (x2 - x1)
                                 = 0.0002 + (0.12 - 0) * (0.0005 - 0.0002) / (0.2 - 0)
                                 = 0.00038

From an admittedly pedantic reading of the readme instructions for calculating zero plane roughness, the word selected did not tip me off interpolate between the table class values.

The zero plane roughness length,"d" can be approximated as 2/3 of the vegetation height (H): d=2/3*H for grassland/cropland or selected from above table based on comprehensive land cover categories.

source

[SnowHydrology]

@aaraney, Thanks for bringing this up. A few comments:

1. The example config files are ancient (in project terms) and can probably use updating
2. Roughness length ≠ zero plane displacement height (their definitions seem similar, but they describe different processes—this response explains better than I can: https://earthscience.stackexchange.com/a/4666). Long story short, zero plane displacement height is typically > roughness length.
3. The quoted table footnote is wrong and I will update it. We needed to modify d estimates because the PET routines are best suited to agricultural areas where d is almost always << wind speed measurement height. This is not the case in forests where using the d=2/3*H equation would estimate a d > measurement height.

[aaraney]

@aaraney, Thanks for bringing this up. A few comments:

For sure! Thanks for the quick reply!

1. The example config files are ancient (in project terms) and can probably use updating

Right and on that note, I think the config files present in the repo have been more-or-less copied and pasted to the NGEN repo as well. I assume they are living in other repos too... Ill try to remember to open an issue to track updating PET config files in ngen once they are updated here.

Relating to updating the config files present here, I stumbled into needing to open this issue in trying to use hydrofabric linked data (e.g. cfe_noaaowp_attributes table) to create a PET bmi config file. It would be nice to include that "mapping," if you will, from fields in the hydrofabric to PET config parameters / derivations in the configuration file updates. I would be happy to iterate and contribute that back to this repo if that is something you feel should live here?

2. Roughness length ≠ zero plane displacement height (their definitions seem similar, but they describe different processes—this response explains better than I can: https://earthscience.stackexchange.com/a/4666). Long story short, zero plane displacement height is typically > roughness length.
3. The quoted table footnote is wrong and I will update it. We needed to modify d estimates because the PET routines are best suited to agricultural areas where d is almost always << wind speed measurement height. This is not the case in forests where using the d=2/3*H equation would estimate a d > measurement height.

👍🏻. Thanks for sharing some knowledge and clarifying!

[SnowHydrology]

@aaraney I'm tagging in @lcunha0118 and @WanruWu-NOAA to help with your followup questions. Luciana create the derivation from hydrofabric data code and Wanru did the updates to zero plane displacement.

[aaraney]

Thanks, @SnowHydrology! As a starting point, @lcunha0118, I found some of your scripts for creating bmi model specific configuration files from hydrofabric linked data, but Ive not run across any for PET. Ive probably just havent looked in the right place. Below is a table of mappings that ive come up with so far:

Assuming for now that we are using NGEN with AORC forcing and hydrofabric 1.2. In the future this is not a good assumption, so some of the following attribute values might need to change. I've broken PET's configuration parameters into three tables, assumed, derived, and user specified. Assumed meaning, we know these values primarily because of attributes of the assumed forcing (AORC). Derived meaning, we got these parameter values from the hydrofabric linked data or used the linked data plus some other information (i.e. lookup table).

PET Parameter	Assumed Value
forcing_file	BMI
yes_aorc	True
yes_wrf	False
wind_speed_measurement_height_m	10.0
humidity_measurement_height_m	10.0
shortwave_radiation_provided	False
time_step_size_s	3600
num_timesteps	720
cloud_base_height_known	False

PET Parameter	Hydrofabric 1.2 Field
	{{ gpkg table name}}.{{ field name }}
longitude_degrees	forcing_metadata.cetroid_lon
latitude_degrees	forcing_metadata.centroid_lat
site_elevation_m	forcing_metadata.elevation

PET Parameter	User Provided Value
pet_method	energy_balance = 1, aerodynamic = 2, energy_balance_aerodynamic_combo = 3, priestley_taylor = 4, penman_monteith = 5

That leaves the following parameters with unknown mappings. Also included are notes I found either in the readme or comments in the code and how I assume they should be determined.

• vegetation_height_m: // TODO this should come from land cover data and a veg. height model
  • assumption: use cfe_noahowp_attributes.IVGTYP and some lookup table / equation to estimate veg height?
• surface_longwave_emissivity: // dimensionless (0-1) < 1.0 for water and snow, all other surfaces = 1.0
  • assumption: use cfe_noahowp_attributes.IVGTYP and USGS 24 class vegetation lookup table to determine if this should be 1.0 or 0.97 if this a snow dominant catchment?
• surface_shortwave_albedo: not sure which comment is correct or if both of them are?
  1. // dimensionless (0-1) from land cover. Dynamic seasonally
  2. // this is a function of solar elev. angle for most surfaces.
     • assumption: derive from cfe_noahowp_attributes.IVGTYP and forcing_metadata.aspect?
• zero_plane_displacement_height_m: approximated using vegetation height
• momentum_transfer_roughness_length: approximated using zero plane roughness length or vegetation height
• heat_transfer_roughness_length_m: approximated using momentum_transfer_roughness_length

@lcunha0118 / @WanruWu-NOAA, can you confirm the mappings ive determined so far and provide guidance for deriving the remaining fields from hydrofabric linked data? Thanks in advance!

[lcunha0118]

For the surface_shortwave_albedo, so far we have a look up table with land cover. Aspect does affect it, but we do not currently have an albedo value for each land cover and aspect. @SnowHydrology are we planning to generate this?

We should discuss what to do with these parameters : momentum_transfer_roughness_length heat_transfer_roughness_length_m

Even though they are being provided in the configuration file (per the legacy code), they are also being calculated within the PEtPenmanMonteithMethod.h (per @WanruWu-NOAA modifications). https://github.com/NOAA-OWP/evapotranspiration/blob/0a66999db9695bccf4c1e35d904aa86f04e6cacf/include/PEtPenmanMonteithMethod.h#L97

Another one that might be an issue is vegetation_height_m, since it might potentially be modified in the code. https://github.com/NOAA-OWP/evapotranspiration/blob/0a66999db9695bccf4c1e35d904aa86f04e6cacf/include/PEtPenmanMonteithMethod.h#L87

If we are going to keep the calculation of the parameters within the code, we need to remove the values from the configuration file. If we do that, we will not be able to calibrate those parameters. @SnowHydrology @WanruWu-NOAA, opinions?

[WanruWu-NOAA]

momentum_transfer_roughness_length & heat_transfer_roughness_length_m -- to my understanding these two parameters are using the similar equations in both code and configuration based on the zero-plane displacement height? If there is a way to optimize/calibrate them, we can easily comment out the computation lines in code. Makes sense?

[WanruWu-NOAA]

A note from my limited research work for the PET AGU poster -- the roughness height z0 is for the aerodynamic and combination methods while the zero-plane displacement height d is for the Penman-Monteith method. Their values can be different. The two parameters are not separated and both use the zero-plane displacement height in the current PET module.

[aaraney]

For the surface_shortwave_albedo, so far we have a look up table with land cover. Aspect does affect it, but we do not currently have an albedo value for each land cover and aspect. @SnowHydrology are we planning to generate this?

Awesome, that's super helpful. Can you provide a link to that table? I may have missed it in the repo if it already here (sorry if that is that case!).

[aaraney]

~Awesome, that's super helpful. Can you provide a link to that table? I may have missed it in the repo if it already here (sorry if that is that case!).~

Sorry, i'd forgotten @lcunha0118 shared her PET configuration generation script. I now see that you were using MPTABLE.TBL and USGS vegetation and STASGO soil classifications to derive vegetation_height_m and surface_shortwave_albedo receptively. Specifically:

• vegetation_height_m: HVT field in MPTABLE.TBL indexed using the IVGTYP - USGS vegetation type (24 classes) that can be retrieved from the hydrofabric at cfe_noahowp_attributes.IVGTYP.

• surface_shortwave_albedo: albedo_mean column in a CSV @lcunha0118 shared with me indexed using the ISLTYP - STASGO soil type (16 classes) value that can be retrieved from the hydrofabric at cfe_noahowp_attributes.ISLTYP. I'm assuming albedo_mean is derived from MPTABLE.TBL? Can you elaborate on how that CSV was created, @lcunha0118?

I checked the WRF and WRF-Hydro MPTABLE.TBL documentation and nothing really stuck out to me. I saw that Noah (not Noah-MP) has a VEGPARM.TBL that contains ALBEDOMIN and ALBEDOMAX fields (these use USGS classes though). That seemed unrelated though.

[lcunha0118]

I think I provided that file with the code to generate the config files (maybe not). The name of the file is MPTABLE_VEG_LandType.csv, content below.

"vegtyp","description","CH2OP","DLEAF","Z0MVT","HVT","HVB","DEN","RC","MFSNO","SCFFAC","albedo_mean","albedo_max","albedo_min","Roughness_length" 1,"Urban and Built-Up Land",0.1,0.04,1,15,1,0.01,1,2.5,0.042,0.19,0.25,0.15,0.8 2,"Dryland Cropland and Pasture",0.1,0.04,0.15,2,0.1,25,0.08,2.5,0.014,0.22,0.3,0.18,1.33333333333333 3,"Irrigated Cropland and Pasture",0.1,0.04,0.15,2,0.1,25,0.08,2.5,0.014,0.17,0.2,0.12,1.33333333333333 4,"Mixed Dryland/Irrigated Cropland and Pasture",0.1,0.04,0.15,2,0.1,25,0.08,2.5,0.014,0.17,0.2,0.12,1.33333333333333 5,"Cropland/Grassland Mosaic",0.1,0.04,0.14,1.5,0.1,25,0.08,2.5,0.026,0.16,0.2,0.12,1 6,"Cropland/Woodland Mosaic",0.1,0.04,0.5,8,0.15,25,0.08,2.5,0.026,0.2,0.21,0.18,2 7,"Grassland",0.1,0.04,0.12,1,0.05,100,0.03,2.5,0.02,0.19,0.21,0.17,0.666666666666667 8,"Shrubland",0.1,0.04,0.06,1.1,0.1,10,0.12,2.5,0.018,0.17,0.23,0.13,0.733333333333333 9,"Mixed Shrubland/Grassland",0.1,0.04,0.09,1.1,0.1,10,0.12,2.5,0.016,0.2,0.3,0.11,0.733333333333333 10,"Savanna",0.1,0.04,0.5,10,0.1,0.02,3,2.5,0.02,0.16,0.21,0.13,1.6 11,"Deciduous Broadleaf Forest",0.1,0.04,0.8,16,11.5,0.1,1.4,2.5,0.008,0.15,0.2,0.1,1 12,"Deciduous Needleleaf Forest",0.1,0.04,0.85,18,7,0.28,1.2,2.5,0.008,0.11,0.12,0.1,1 13,"Evergreen Broadleaf Forest",0.1,0.04,1.1,20,8,0.02,3.6,2.5,0.008,0.14,0.16,0.12,1 14,"Evergreen Needleleaf Forest",0.1,0.04,1.09,20,8.5,0.28,1.2,2.5,0.008,0.11,0.15,0.05,1 15,"Mixed Forest",0.1,0.04,0.8,16,10,0.1,1.4,2.5,0.008,0.13,0.18,0.1,1 16,"Water Bodies",0.1,0.04,0,0,0,0.01,0.01,2.5,0.03,0.08,0.15,0.03,0 17,"Herbaceous Wetland",0.1,0.04,0.12,0.5,0.05,10,0.1,2.5,0.02,0.19,0.32,0.11,0.333333333333333 18,"Wooded Wetland",0.1,0.04,0.5,10,0.1,0.1,1.4,2.5,0.02,0.19,0.32,0.11,1 19,"Barren or Sparsely Vegetated",0.1,0.04,0,0,0,0.01,0.01,2.5,0.016,0.22,0.4,0.05,0 20,"Herbaceous Tundra",0.1,0.04,0.1,0.5,0.1,1,0.3,2.5,0.03,0.19,0.2,0.18,0.333333333333333 21,"Wooded Tundra",0.1,0.04,0.3,4,0.1,1,0.3,2.5,0.03,0.15,0.16,0.13,0.4 22,"Mixed Tundra",0.1,0.04,0.2,2,0.1,1,0.3,2.5,0.03,0.16,0.17,0.15,0.4 23,"Bare Ground Tundra",0.1,0.04,0.03,0.5,0.1,1,0.3,2.5,0.03,0.24,0.24,0.24,0.333333333333333 24,"Snow or Ice",0.1,0.04,0,0,0,0,0,2.5,0.03,0.72,0.9,0.45,0 25,"Playa",0.1,0.04,0.01,0.1,0.1,0.01,0.01,2.5,0.03,0.31,0.45,0.2,0.066666666666667 26,"Lava",0.1,0.04,0,0,0,0.01,0.01,2.5,0.03,0.14,0.15,0.12,0 27,"White Sand",0.1,0.04,0,0,0,0.01,0.01,2.5,0.03,0.31,0.45,0.2,0

[lcunha0118]

BTW, Keith and I came up with the albedo values based on values in the literature. So the albedo did not come from the Noah-MP parameter tables.

[lcunha0118]

@WanruWu-NOAA See table below. This is what I came up with in terms of what parameters each formulation uses. Does this match with what you evaluated previously? @SnowHydrology I think a table like this should be added to the repository to guide the user on the parameters that matter for each formulation.

[aaraney]

Thanks for including the csv file and clarifying the origin, @lcunha0118! You did send it to me, but for others reading this in the future, it could be really useful.

Two questions I have that follow:

1. Will the information from the above CSV table make it into hydrofabric link data?
2. For full transparency and origin sake, it seems like the CSV should be added to this repo and some documentation should be added explain where the values can from. Is that fair?

[mattw-nws]

momentum_transfer_roughness_length heat_transfer_roughness_length_m Even though they are being provided in the configuration file (per the legacy code), they are also being calculated within the PEtPenmanMonteithMethod.h

... the roughness height z0 is for the aerodynamic and combination methods while the zero-plane displacement height d is for the Penman-Monteith method. Their values can be different. ...

Not to open a different can of worms, but these seem like really strong indicators that this should not be one module but between 3 and 5 different modules... has this been considered? There are different inputs, and the inputs are used differently... would it make more sense for these to be separate "models" that share some applicable code portions?

[SnowHydrology]

this should not be one module but between 3 and 5 different modules.

[WanruWu-NOAA]

• The momentum-transfer and heat-transfer roughness lengths are for the Penman-Monteith method only, as well as the zero-plane displacement height, if we can add a separate parameter “surface roughness height” for the Aerodynamic method and the Combination method.
• The surface longwave emissivity and surface shortwave albedo are used to compute the surface net radiation, which is needed for all other four PET methods except for the aerodynamic method.
• The vegetation height is not needed if the zero-plane displacement height is preset/calibrated.

Thoughts?