noaa-oar-arl / canopy-app Goto Github PK

I see that although for 30eea0b there was an error when running the nb, it didn't fail CI. I should fix that. Probably need to check the rc in the loop and exit if nonzero.

Originally posted by @zmoon in #109 (comment)

Also when it did fail (should have, for invalid namelist key), the error message was from a later cell, will have to investigate that as well.

@angehung5
As discussed, this would be an effort to improve the granularity, and/or consistency between the input vegetation type dataset and the input GEDI canopy height and PAVD profile datasets.

Currently, as shown in previous issues/PRs, the GEDI height of maximum PAVD value does not match well with Massman prescribed heights in forest regions. This is likely impacted by surrounding low-lying vegetation in the original 1-km GEDI dataset, which when regridded (using dominant approach) to coarser resolution (e.g., GFS 13 km) results in a different profile shape compared to what a true forest point would look like at the sites compared in the canopy-wind paper (i.e., sites forced to be a forest vegtype). While a single point it is clear the issue, and to thus not use a regridded (dominant approach) GEDI 1-to-13 km PAVD product for the forest site, when applying to the global canopy-app it is clear such inconsistencies will arise.

Ultimately, we should bring in Barry's methods that uses the VIIRS 20 category 30 arcsec product to obtain a global gridded fractional vegtype dataset (from native high resolution, to a lower target grid resolution, e.g., 13 km), and adopt canopy-app to use it. Here we would need to change canopy-app to calculate a "sub-grid" fractional profile for each vegtype contained within the 13 km GFS grid, and then normalize profiles to the total number of vegtypes in the grid box. This would better represent the true heterogeneity in the vegtypes in each grid box and likely better match up with the originally higher resolution GEDI 1 km products.

Based on the LES chemistry simulations of Clifton et al. (2022), and after issue #21 - #28 are completed, we can add simplified submodules representing biogenic emissions, chemical reactions, dry deposition/CRFsoilnox as new features to the canopy-app.

@angehung5 As discussed, and as described in your paper, we instead should be using the total MODIS vegfrac, i.e., "canfrac" rather than the specific forest fraction (ffrac).

Start with Parametrized BDSNP soil NO scheme as in HEMCO (https://github.com/geoschem/HEMCO/blob/main/src/Extensions/hcox_soilnox_mod.F90) or MEGAN v3.2

ENOx = f( T, biome, WFPS, Fert) x Pulse(dryspell) x canopy uptake

Can utilize MEGAN v3.2 soil NO input data for this

Note: Soil NH3 volatilization schemes would need soil NH4+ (example: [DNDC model] https://www.sciencedirect.com/science/article/pii/S0048969718353038)), eventually would need a mechanistic option that distinguishes the total soil Nitrogen in to organic and inorganic pools (NH4 and NO3)

This issue will pull out and restructure stand-alone Tleaf and PPFD parameterization modules from the biogenic codes to facilitate future canopy-app developments that may use these variables (e.g., netphoto, drydep, soilNO, etc.). The biogenic module will be restructured here to take Tleaf and PPFD as inputs. It is envisioned that more sophisticated Tleaf and PPFD module options will become available later for different canopy-app testing.

@MaggieMarvin Starting an issue to link here as well. As you know, I have a new branch and draft PR for your testing of this explicit approach following MEGANv2 in HEMCO, and using rolling averages with e-folding times for hours and days after a given canopy-app simulation reaches > 24-hours.

After discussion with Rick and Barry, we will go forward at first with taking pieces from ACCESS/CANACC, starting with photosynthesis net assimilation module, which can help connect the next pieces in adding LEB (also includes photosynthesis assimilation), temp/water vapor/scalar profiles, and dry deposition.

It has been shown that the current MEGANv2 or v3 soil moisture/drought gamma is does not capture the 2011 or 2012 drought effect on isoprene emissions (Potosnak et al., 2014; Sindelarova et al., 2014; Seco et al., 2015; Huang et al., 2015) when using the default soil data (i.e. soil types and wilting points from Chen and Dudhia, 2001) due to the low wilting point values recommended by Chen and Dudhia (2001). This would be the case in the current canopy-app implementation of gamma_sm, and using the GFSv16/Noah LSM soil moisture and wilting point parameters for the correction.

At some point, recommend updating to include another option using Jiang et al. (2018) approach, based on physiological effects of drought stress on plant photosynthesis and isoprene emissions for use in the MEGAN3 biogenic emission model.

add the Cmake build system to canopy-app instead of traditional makefiles.

Turns out GEDI/Sentinel-2 can map crop heights after all:

https://www.earthdata.nasa.gov/learn/articles/lasering-in-on-corn-fields

Ultimately, we would want to combine this dataset with our GEDI FCH, for full coverage of all valid vegetation types in canopy-app for biogenics, etc. For now, I will put in an 'crop' option in canopy-app to put a user set value value for height until we can get this into our inputs...

@angehung5 Adding updated PAVD to the example SE files on repo, as well as updating the global 12 km daily files and 1 km files on AWS.

I have a python script to calculate the rate of fire spread (ROS) using Rothermel's approach (Rothermel 1972; Andrews 2018). I reclassify the 13 standard fuel types (Table 8a in Andrews 2018) into 4 (grass, brush/slash, timber/hardwood, logging slash).

Input:

• Fuel type
• Fuel moisture (%)
• Terrain slope
• Wind speed (ft/min)

Output:

• Rate of spread (ft/min)

The full parameter list can be found in /groups/ESS/whung/canopy_wind/rothermel_spread.py
Prescribed fuel parameters (e.g. total fuel loading (W0)) are adapted from the Table 8a in Andrews (2018). Fuel bulk density (rho) and pack ratio (beta) are calculated from W0 and fuel bed depth instead of using the static values.

Example of ROS:

After discussed with @drnimbusrain, we think it will be great to extend canopy-app's capability by adding ROS calculation based on Rothermel's model. To add this function, several things needed to be think of:

• Map fuel categories/parameters based on VIIRS AST
• How to get fuel moisture content - There were some presentations on AMS fire meeting about getting fuel moisture approximation from humidity. We may contact them for details
• Get terrain slope
• How to apply it to operational system? How to relate the grid cell by grid cell ROS to the overall fire spread - Maybe check RFS-Fire?

The fraction of new, growing, mature, and old/senescing foliage, can be added as per Table 4 of Guenther et al., 2012 MEGANv2.1 for different biogenic emission compounds, to start with

Need to explore any possible enhancements after seeing the result of this one.

There is an idea by Zach to add more complex canopy chemistry and related processes (e.g., CRFs, soil processes, etc.) to canopy-app by use of python-based surrogate/ML tools to avoid computational slowdown. This high-level idea could be achieved by calling python random forest or gradient-boosted (XGBoost) tools from the main canopy-app Fortran routines.

@zmoon Can you elaborate a bit more on ideas to help push this forward?

          > @drnimbusrain any new features to highlight in the 1-D examples?

@zmoon Thank you for working on these updates! Most recently we have been working on the biogenic emissions, and have added a number of new options that I think could be added and useful for 1-D examples. See the new biogenic options, loss_opt, leafage_opt,hist_opt, and soim_opt.

Originally posted by @drnimbusrain in #135 (comment)

Following discussion with @angehung5 on the missing WAF calculation when grid cells have FRP, but do not satisfy canopy conditions (thus not performing canopy wind calculation), maybe we can add additional user option(s). Here is an idea:

• nocanwind_opt=0: Do not perform canopy wind calculation, set to zero in grid cell (Default)
• nocanwind_opt=1: Set output to reference wind speed in grid cell (e.g., input 10-m wind speeds)
• nocanwind_opt=2: Set output to MOST defined wind speed at the calculated FRP-based flame height/2.0

Further discussion is needed with @angehung5 .

@angehung5 Maybe we can revisit adding more GFSv16 met/land variables needed for other canopy-app processes (dry deposition, soil NOx/CRFs, etc.).

These would include things like.
2D Soil moisture at four LSM levels (soilw1-4)
Soil temperature at four LSM levels (soilt1-4)
etc...

As discussed at today's UFS-CATChem development meeting, there may be need to expand the current capabilities of canopy-app biogenics to have more granularity and flexibility across chemical complexity and more PFT complexity.

As a first step, we could follow MEGANv3 for mapping across chemical complexity. Currently, MEGANv3 takes the 19 compound class output species, speciates to 201 species, and then remaps to any chemical mechanism complexity using set mechanism input files (e.g., CB06, SAPRC, RADM, etc.). Currently on GMU Hopper, the MGN2MECH codes are found by example at:

/groups/ESS/pcampbe8/MEGAN/MEGANv3.2_Dec_2021/src/MGN2MECH/mgn2mech.F

This would be relatively easy to make an option in canopy-app to follow the MEGANv3 mapping and output the chemical mechanism/complexity is desired.

Currently get a bunch of warnings about the fill values.

Although they look the same, they are different precisions (missing_value is float32 while _FillValue is float64).

We should address this.

Canopy-app does not calculate WAF when flameh>FCH and returns missing values

 lat      lon      canheight (m)         flameh (m)    waf (1)

34.97 276.33 27.91 27.00 4.5880087E-02
34.97 276.33 27.91 28.00 -8.9999998E+20

In fact, if either sub- or abov-canopy type canopy-app will not calculate WAF if flameh>FCH. It would be better to show an alert and use WAF=1 when flameh>FCH. But seems something wrong with above-canopy case which should use flameh+FCH in the calculation.

To reduce looping in canopy_driver over submodule canopy profiles, make all submodules take entire profile by making them elemental subroutines.

Relevant comment threads:

• #20 (comment)
• #20 (comment)

After discussion with John following the AMS conference, there was discussion on adding canopy air water vapor and sensible heat exchanges in canopy-app. While somewhat out-of-scope for canopy-app this would open more doors for collaboration with ATDD, and such energy balance/flux approaches may be necessary for other canopy-app processes such as C/N fluxes and stomatal fluxes for dry deposition in #60.

I think we could start with ACCESS canopy physics codes and some approach to getting parameterized canopy air temperature and water vapor profiles through canopy. We do not necessarily want to do a full LEB approach, as we have parameterized the leaf temperature and PAR in the biogenic emissions module, but should be cognizant of this consistency when leaf conductance and temperatures (sunlit vs. shaded) are needed for canopy air temperature profile for example. Seems we should do a similar parameterization to get at those terms for adding cantemp and canvapor as we need the LEB from ACCESS in some way.

Likely we could add 'cantemp' and 'canvapor' options based on IntegrateTempAir and IntegrateWaterVapor from ACCESS, using the above canopy resolved model air temperature/water vapor as the upper boundary condition to keep it simple.

However, this should cross over with issue #63, to unify a more simplified turbulence ('canturb') option that uses Bonan and ACCESS to control profiles of momentum (winds/diff), heat (temperature), and vapor profiles through canopy.

@MaggieMarvin This should be relatively simple addition, where we can add the MEGAN3 function for calculating "GAMMA_AQ", which depends on a current air quality index, i.e. in MEGAN3 it uses ozone W126 (ppm hours-1). This can be calculated based on input ozone concentrations. Initially, we can make an option for a a set constant ozone mixing ratio input in the namelist and calculate the W126 (easier) in canopy-app, but it should be spatially dependent for regional and global scale applications, thus calculated using gridded input ozone concentrations to canopy-app (trickier).

Based on @angehung5 global canopy files Python script, as input to canopy-app (GMU Hopper: /groups/ESS/whung/canopy_wind/global_canopy_gen.py), it would be good if we can revise to include methods in the script to generally complete following pre-processing steps for global canopy-app:

1. Use wget to retrieve the hourly 13 km GFSv16 meteorology files from AWS for specified times: wget --no-check-certificate --no-proxy https://nacc-in-the-cloud.s3.amazonaws.com/inputs/YYYYMMDD/gfs.t12z.sfcfHHH.nc,

2. Use wget to retrieve climatological monthly canopy files with canopy (lai, clu, fch, and frt) and external variables used in canopy-app (frp, mol, csz, and href): wget --no-check-certificate --no-proxy https://nacc-in-the-cloud.s3.amazonaws.com/inputs/geo-files/gfs.canopy.t12z.2022MM01.sfcf000.nc

3. Perform steps to append correct monthly climatological canopy variables (lai, clu, fch, and frt) from Step 2 to the hourly GFSv16 files matching correct months,

4. Perform steps to calculate date/time dependent external variables (mol and csz) and update the modified hourly GFSv16 files from Step 2-3. Also ensure that the constant href (10 meter) variable is copied to each GFS file for dates/times, and

5. Check local directory (or possible FTP server) for NOAA's GBBEPx FRP data for the correct hourly dates/times and, if present update files from Step 4 for the correct FRP values. If not present, use the example 12 month climatology (with warning printed that fires/FRP will not be respective of actual conditions). This is OK if users don't need the limited WAF application for fires.

Then, we can provide this script on the GH repo, and will be instrumental in helping others generate global canopy inputs for canopy-app (for any given date/time (back to March 21, 2021 -- Start of the GFSv16 data record on AWS). We could add the script to the https://github.com/noaa-oar-arl/canopy-app/tree/develop/python directory.

@MaggieMarvin
As discussed, we will need to also add a soil moisture gamma factor into the biogenic emissions (for isoprene only), which will be based on the GWETROOT = degree of saturation or wetness in the root-zone (top meter of soil). This is defined as the ratio of the volumetric soil moisture to the porosity. This can be calculated from input GFS soil moisture (Noah and Noah-MP models include four soil layers, centred at 5, 25, 70, and 150 cm).

        float soilw1(time, grid_yt, grid_xt) ;
                soilw1:long_name = "volumetric soil moisture 0-10cm" ;
                soilw1:units = "fraction" ;
                soilw1:missing_value = 9.99e+20f ;
                soilw1:_FillValue = 9.99e+20f ;
                soilw1:cell_methods = "time: point" ;
                soilw1:output_file = "sfc" ;
        float soilw2(time, grid_yt, grid_xt) ;
                soilw2:long_name = "volumetric soil moisture 10-40cm" ;
                soilw2:units = "fraction" ;
                soilw2:missing_value = 9.99e+20f ;
                soilw2:_FillValue = 9.99e+20f ;
                soilw2:cell_methods = "time: point" ;
                soilw2:output_file = "sfc" ;
        float soilw3(time, grid_yt, grid_xt) ;
                soilw3:long_name = "volumetric soil moisture 40-100cm" ;
                soilw3:units = "fraction" ;
                soilw3:missing_value = 9.99e+20f ;
                soilw3:_FillValue = 9.99e+20f ;
                soilw3:cell_methods = "time: point" ;
                soilw3:output_file = "sfc" ;
        float soilw4(time, grid_yt, grid_xt) ;
                soilw4:long_name = "volumetric soil moisture 100-200cm" ;
                soilw4:units = "fraction" ;
                soilw4:missing_value = 9.99e+20f ;
                soilw4:_FillValue = 9.99e+20f ;
                soilw4:cell_methods = "time: point" ;
                soilw4:output_file = "sfc" 

I think we can initially follow MEGANv2 in HEMCO: https://github.com/geoschem/HEMCO/blob/main/src/Extensions/hcox_megan_mod.F90#L2467, or use MEGANv3 soil moisture corrections.

To get the volumetric soil moisture in top meter of soil, we can average the first three layers soilw1, soilw2, and soilw3, but need to get porosity to get GWETROOT, which can be associated with soil types, also available in the GFS data:

float sotyp(time, grid_yt, grid_xt) ;
                sotyp:long_name = "soil type in integer 1-9" ;
                sotyp:units = "number" ;
                sotyp:missing_value = 9.99e+20f ;
                sotyp:_FillValue = 9.99e+20f ;
                sotyp:cell_methods = "time: point" ;
                sotyp:output_file = "sfc" ;

Alternatively, as discussed in Guenther et al. 2006 and shown in Eqs 20a-c, we can use the wilting point instead of porosity, which is available in the GFS data too, and use a PFT dependent root depth fraction (see Eq. 2 and Table 2 in Zeng 2001) and all soil levels to calculate the weighted average gamma soil moisture to use here. I favor this approach as it can be used across any soil layer depths in model or observations.

float wilt(time, grid_yt, grid_xt) ;
                wilt:long_name = "wiltimg point (volumetric)" ;
                wilt:units = "Proportion" ;
                wilt:missing_value = 9.99e+20f ;
                wilt:_FillValue = 9.99e+20f ;
                wilt:cell_methods = "time: point" ;
                wilt:output_file = "sfc" ;

@angehung5 After we get this working in canopy-app using the already included four soil moisture parameters and the soil type or wilting point (dependent on approach) in the GFS sfc NetCDF files, we will need to add similar columns in the text files for example SE files in the GH repo.

Adding namelist controlled NetCDF input/output file options for improved assessment and testing of canopy-app modules.

Could also make a netcdf_io module based on NACC to read netcdf inputs: https://github.com/noaa-oar-arl/NACC/blob/master/parallel/src/netcdf_io_mod.f90
canopy_netcdf_io_mod.F90
canopy_outncf.F90

After Issue #22 is completed, the output creation could be moved to txt and netcdf output modules:
canopy_outncf_mod.F90: Based on NACC: https://github.com/noaa-oar-arl/NACC/blob/master/parallel/src/outncf.f90
canopy_outtxt_mod.F90: https://github.com/noaa-oar-arl/canopy-app/blob/develop/canopy_driver.F90#L333

For the input option, we need example input NetCDF file from Issue #25 first. Hopefully, @angehung5 can help generate one based on the current input_variables.txt file.

@zmoon
@drnimbusrain

@angehung5

Currently the CANFRAC is annual, but could/should be daily, or at least monthly in temporal resolution.

Incorporate crop height option to either use future GEDI measurements (i.e., issue #69 ) or user set value for crop heights (for biogenic emissions etc.). This can be improved later.

Add an alternative biogenic emissions calculation to canopy-app that uses the canopy-averaged emission factors and the total LAI and compare that to current layerwise output integrated. Standalone MEGAN v2.1 and v3 do something like this.

Add a start to using a user-defined CO2 inhibition factor for ISOP only (GAMCO2), maybe gleaming from simple HEMCO/MEGANv2.1 implementation.

@angehung5
As we move towards adding more parameterized processes in Canopy-App (e.g., bioemis, drydep, chem), we will inherently need new input variables added to the example 1D text and 1D/2D NetCDF input files for testing.

Here is the list of new (typical atmospheric gridded model) input variables needed for now:

• Soil Type/Cat
• Surface pressure (Pa)
• Instantaneous surface downward shortwave flux (W/m2)
• Surface/Skin Temperature (K)
• 2-meter temperature (K)
• 2-meter water vapor mixing ratio or specific humidity (kg/kg)
• Planetary Boundary Layer Height (m)
• Mass Precipitation Rate (kg/m2 s)

We should follow exact same format as in current text and netcdf files (with attributes) in the [develop] branch as they have been standardized.
https://github.com/noaa-oar-arl/canopy-app/blob/develop/input_variables.txt
https://github.com/noaa-oar-arl/canopy-app/blob/develop/input_variables_1D.nc
https://github.com/noaa-oar-arl/canopy-app/blob/develop/input_variables_2D.nc

We can add these new variables as we go and determine what's really needed. You can branch off of [develop] and make PRs for subsequent additions to the files.

There will be a need to add carbon and nitrogen pools/fluxes in canopy-app in some way. Its possible we need to leverage other models of the ecosystem and biogeochemical models of carbon and nitrrogen fluxes and balance.

One example is the LPJ-GUESS Ecosystem Model, where outputs include vegetation composition and cover in terms of major species or plant functional types (PFTs), biomass and soil organic matter carbon pools, leaf area index (LAI), net primary production (NPP), net ecosystem carbon balance, carbon emissions from wildfires, biogenic volatile organic compounds (BVOCs), evapotranspiration, runoff, and nitrogen pools and fluxes. The latest version (4.1) includes further outputs and functionalities such as methane emissions, soil nitrogen chemistry, permafrost dynamics, and a new wildfire model.

Also, we should explore using the ACCESS model and consistency with issue #64 in the canopy.

@zmoon pointed out the unphysical jump in the modeled wind profile from above the canopy to the canopy top (panel on far left below):

The main issue is that the canopy-wind codes were originally only designed to go from canopy-top downward, and then it got a bit fragmented when combining this approach with the MOST and unified RSL approaches I adopted from Noah-MP and Rosenzweig et al., (2021) https://doi.org/10.1029/2021MS002665.

This could be rectified by making the wind profile smooth below the reference height wind (e.g., @ 10 m winds from model). Reference height wind is needed in WAF calculation, so winds can be constant above the reference height wind.

Ultimately, we should have a smoothly varying wind speed below the reference height wind (such as in Bonan's plot below):

Need to move and reorganize significant amount of code/logic from driver and consolidate in their own submodules. Some locations (based on current develop branch) where this is needed is as follows (with suggested module names):

1. Pull out all physical calculations to separate subroutines:
   canopy_griddx_mod.F90: https://github.com/noaa-oar-arl/canopy-app/blob/develop/canopy_driver.F90#L189 (Also improve the dx calculation to be dependent on grid cell lat/lon using haversine formula for distance between two points).
   canopy_foliage_mod.F90: https://github.com/noaa-oar-arl/canopy-app/blob/develop/canopy_driver.F90#L255
   canopy_flameh_mod.F90: https://github.com/noaa-oar-arl/canopy-app/blob/develop/canopy_driver.F90#L288

2. Could also make a netcdf_io module based on NACC to read netcdf inputs: https://github.com/noaa-oar-arl/NACC/blob/master/parallel/src/netcdf_io_mod.f90
   canopy_txt_io_mod.F90 (for inputting/reading text file data)
   canopy_netcdf_io_mod.F90 (for inputting/reading netcdf file data)

3. After Issue #22 is completed, the output creation could be moved to txt and netcdf output modules:
   canopy_outncf.F90: Based on NACC: https://github.com/noaa-oar-arl/NACC/blob/master/parallel/src/outncf.f90
   canopy_outtxt.F90: https://github.com/noaa-oar-arl/canopy-app/blob/develop/canopy_driver.F90#L333

4. After Issue #21 is completed, anything else about choosing which things to calculate based on the config or calling computation routines could be consolidated into a subroutine to call on the inputs and config:
   canopy_input_mod.F90: https://github.com/noaa-oar-arl/canopy-app/blob/develop/canopy_driver.F90#L278

@zmoon
@drnimbusrain

After Issues #21, #22, and #23 are completed get some tests of output going, maybe for WAF based on the examples in the paper
so we can track that results stay the same and validate with literature

Another test we can add, now that there are a bunch of option switches, is to at least make sure that they all run using an automated CI/checks so you don't have to check yourself every time you do something.

@zmoon
@drnimbusrain

As discussed at today's UFS-CATChem development meeting, there may be need to expand the current capabilities of canopy-app biogenics to have more granularity and flexibility across chemical complexity and more PFT complexity.

We could also bring in more complexity of the many PFTs as in MEGANv3 input files mapped across fractional gridded growth forms and ecotypes. Since different tree species can have very different BVOC emission rates, this can be very important for accurate canopy-app predictions. Currently, the compound class EFs are based on the simplified, mapped MODIS/VIIRS input vegetation types, but likely we should bring in this data/methods in some way to have more granularity across different PFTs. The global, lat/lon gridded input ecotypes and fractional growth forms (in NetCDF CF-convention) used in MEGANv3 are found by example on Hopper at: /groups/ESS/pcampbe8/MEGAN/MEGAN3_inputs/.

MEGANv3 uses the python scripts (e.g., on Hopper:
/groups/ESS/pcampbe8/MEGAN/MEGAN3_work_GFSv16_NACC_G1/02.MEGEFP32/MEGAN_EFP.py) to integrate the input gridded ecotype and fractional growth forms maps across plant species composition and species-specific emission factor CSV file data to get the final EFs across 19 compound classes. The input PFT species-specific emissions factor data and associated fractional growth form mapping/speciation CSV files are found on Hopper at: /groups/ESS/pcampbe8/MEGAN/MEGAN3_work_GFSv16_NACC_G1/02.MEGEFP32/inputs/EFP/. This is ultimately more complex than canopy-app (i.e. uses MEGANv2 with simple vegtype dependent EFs from Guenther et al., 2012), and could be tricky, so can we include these processes in some simpler way?

@angehung5 Do you think you can make an input gridded, NetCDF file that is identical to the current develop input_variables.txt file?

As shown in Issue #22 , we want to also add an option in canopy-app for both inputting and outputting NetCDF gridded files to improve testing and assessment of different modules.

@zmoon suggested using markdown to create a canopy-app flowchart/diagram to add to the README or eventual ReadTheDocs page for user information.

Markdown Suggestions
Mermaid (https://mermaid-js.github.io/mermaid/#/)
MyST: (https://js.myst.tools/guide)

@zmoon Maybe we can close/combine other issues under this larger one in the attempt to conform the canopy_app structure to be more easily adaptable to CCPPv6 standards:

See the paper, Figure 1, and Listings 2 -4 (e.g., Listing 2: A complete CCPP-compliant parameterization with Fortran source code)
https://egusphere.copernicus.org/preprints/2022/egusphere-2022-855/egusphere-2022-855.pdf

It was alluded to at the AMS conference that the initial implementations of horizontal in-canopy wind parameterizations are not yet fully consistent with the Raupauch method for simple modified eddy diffusivity/turbulence in canopy-app.

This is rather expected, but it could be a goal to improve consistency and unify these horizontal and vertical momentum variables in canopy-app using more robustly coupling. This may be a larger task involved later eventually connecting canopy-app with the UFS through CCPP in issue #32.

We should start with ACCESS physics model first, and then maybe leverage some of Bonan et al. (2018) unified RSL/stability approach to modeling canopy turbulence in CLM. Ultimately, it may be best to combine vertical turbulence (i.e., eddy diffusivity, i.e., 'caneddy') and winds (i.e., 'canwind') options together and create a new 'canturb' module/option so that one that is more self consistent between horizontal and vertical momentum.

Overall, this could be a simplified manner to combine issue #62 for momentum #64 for heat/moisture to create 'canturb' that gives winds, heat, and vapor/moisture profiles self consistently through profile.

@zmoon Following discussions at the AMS Fire and Forest conference with Michael Vermeuel (Post-Doc with Dylan Millet at University of Minnesota) on his work on multi-layer canopy model with dry deposition in MLC-Chem and FluCS 2021 dataset (and comparison to GEOS-Chem big-leaf resistance method), we have good ideas to move forward with initial version of an explicit dry-deposition module in canopy-app.

This can be linked with say our BVOC emissions model in canopy-app for BIDI-sensitive species as well. To accomplish this tasks, however, we may need to link surrogate/ML models as in issue #59 to handle driving a stand-alone canopy-app interface with chemical concentrations, compensation points (for BIDI-VOC) etc., and we can use more generalized dry deposition models that depend on chemical properties and diffusivities as inputs.

The question is what is the best method to get stomatal (and included species-dependent mesophyll) resistances:
(1) the default multiplicative method in the Wesely scheme (W89) and Zhang et al. (2003) scheme (Z03), (2) the traditional photosynthesis-based Farquhar–Ball–Berry (FBB) stomatal algorithm, and/or (3) the Medlyn stomatal algorithm (MED) based on optimization theory. We could add options to use each method in the canopy-app NL.

We could just add a deposition velocity functions, which employ option to either input (e.g., bulk RS from the LSM) or calculate the stomatal resistances at leaf level and use data tables that parameterize the mesophyll resistance as a function of solubility following Wesely (1989) or another method above.

Or, maybe if we need to calculate the RS take the approach used in MLC-Chem or even better use the MLC codes for different stomatal resistance options from ACCESS dry deposition as a start. I think using ACCESS is the best initial path forward for adding dry deposition velocity in the canopy.

We could take some insight Clifton et al. 2022 type approach in LES.

Also, after we get something more general, maybe add new approaches such as ecophysiology models.

Adding config type will more help simplify code, since you can pass it instead of long lists of parameters.
@zmoon
@drnimbusrain

@MaggieMarvin I will add an approximate canopy loss factor when bio summing option is used.

It is based on Eq. 21 of Guenther et al. 2006)

This will facilitate improved comparison of canopy-app top primary biogenic emissions from top of canopy with ground-truth flux observations (e.g., PECORINO, FLUCs, etc.) that inherently measure fluxes after chemistry and deposition loss have occurred in-canopy. We can always turn this off when directly using leaf-level canopy-app emissions with chemical box models that may have BVOC chemistry and deposition (e.g., F0AM)

@zmoon @angehung5 Decided to make this a separate issue to add the Bonan wind profiles with Unified RSL approach (eventual RSL_OPT = 1) to canopy-app, so we can be more robust and fully compare in-canopy wind profiles to Massman/MOST approach (RSL_OPT=0) for Wei-Ting's paper as well.

The code for the 2018 paper can be found at https://github.com/gbonan/CLM-ml_v0

This isn't all of the code you need to run it; if interested I have a full setup at https://github.com/zmoon/CLM-ml-mb

Wind profile computation starts with the above-canopy part (Eq. 19 in the paper):
https://github.com/gbonan/CLM-ml_v0/blob/881a5c44b86f92c4ce65b3268b190297fbb0bd65/CanopyTurbulenceMod.F90#L432
This uses utility functions here: https://github.com/gbonan/CLM-ml_v0/blob/881a5c44b86f92c4ce65b3268b190297fbb0bd65/CanopyTurbulenceMod.F90#L921
Obukhov length needed but we could make it an input.

Followed by within-canopy (Eq. 21 in the paper): https://github.com/gbonan/CLM-ml_v0/blob/881a5c44b86f92c4ce65b3268b190297fbb0bd65/CanopyTurbulenceMod.F90#L478

@angehung5 As discussed in numerous air-sfc-x meetings, and to facilitate further potential project/funding and improvements for the UFS in our group, we should think about deriving new global canopy input datasets including roughness length (Z0) and zero plane displacement heights (ZPD). These surface parameters are critical inputs to land, weather, and atmospheric composition models. This would impact also canopy-app processes, e.g., canopy wind.

These can be used as optional inputs to canopy-app instead of using approximated model Z0 and ZPD. Z0 and ZPD can readily be derived from NDVI, e.g., https://www.fao.org/aquastat/py-wapor/et_look_rsts/roughness.html, as other similar canopy products are.

Barry has already started testing that using MONETIO NDVI and deriving Z0 for example:

It was discussed at the ARL air-sfc-x meeting that it would be nice to include an option in canopy-app to use the GEDI vertically resolved (1 m) LAI profiles in the canopy.

This may be derived from the GEDI Level 2B product, plant area volume density profile: https://gedi.umd.edu/data/products/

See Table 3 for the Level 2B product in: https://lpdaac.usgs.gov/documents/588/GEDI_FCCVPM_ATBD_v1.0.pdf

The level 2 product would need interpolation from swatch to gridded product, and right now its difficult to tell if there is a Level 3 gridded product for this already: https://gedi.umd.edu/data/documents/

GEDI Products are available here: https://gedi.umd.edu/data/download/
E.g., for the L2B vertical profile metrics: https://lpdaac.usgs.gov/products/gedi02_bv002/

Need for improved directory structure for Canopy-App source codes (src), example inputs (data), docs, etc.

From our discussion today, having the capability to spin-up and restart canopy-app seems like it could be very beneficial and may help to address current limitations.

For example, a short spin-up period could manage assumptions in the leaf age calculation that affect the first timestep (specifically, that past LAI = current LAI everywhere).

Spin-up and restart could also be a way to incorporate historical temperature averages (24-hour or 240-hour, etc) into the biogenic emissions calculations as done in MEGAN, to replace the instantaneous temperatures that are used currently as placeholders in canopy-app.

Right now, we only use a single formation from Byram (1959) for calculation of FRP (intensity) to flame height relationship in canopy-app.

We can/should use the work of Alexander and Cruz, Table 1 and S1 work., and add vegetation type inputs to have a variable FRP to FlameH calculation.

@angehung5