noaa-oar-arl / canopy-app

Stand-alone/column canopy codes and parameterizations
MIT License
6 stars 6 forks source link

Hoping to Merge Develop Changes to Stable #104

Closed drnimbusrain closed 5 months ago

drnimbusrain commented 5 months ago

@zmoon

drnimbusrain commented 5 months ago

Thank you Wei-Ting! This brings up the question again on if we should make the change from MODIS forest fraction to total vegetation fraction.

On Wed, Jan 24, 2024, 4:55 PM Wei-Ting Hung @.***> wrote:

@.**** approved this pull request.

I did not check the bioemi and ipynb scripts. Others look good. But I suggest changing "Forest clumping index" to "Vegetation clumping index" in README, since it should include all vegetation species.

— Reply to this email directly, view it on GitHub https://github.com/noaa-oar-arl/canopy-app/pull/104#pullrequestreview-1842455913, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLFYNUG66SFQFXQ5UXBMWLYQF7N7AVCNFSM6AAAAABCIA7OC2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQNBSGQ2TKOJRGM . You are receiving this because you authored the thread.Message ID: @.***>

drnimbusrain commented 5 months ago

@angehung5 Did some checking, currently the ffrac is only used to define contiguous canopy grid cell threshold, and in the PAI calculation option as a surrogate for canopy cover fraction (but this M17 formulation/option leads to results we do not trust).

Overall, since canopy-app is technically being driven by any canopy type (for height, lai, clu, etc.) it seems to me that we should change this "ffrac" variable into our canopy-app inputs to rather use a total canopy fraction, i.e., "canfrac". It would be more general, and likely more representative as a threshold (and in the PAI M17 calculation). We could add this canfrac also as an additional 1-km global file for UFS later too.

I don't think this effects much your paper results, but could be something that could be brought in here. As you mentioned, this is something you already have as the annual total vegetation fraction (TVFRAC) in your global extension document, and something that was needed for ffrac anyway.

What do you think?

drnimbusrain commented 5 months ago

@angehung5 See issue #106 I think we should also make this change for 'ffrac' to 'canfrac' before merging develop to stable...