Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scaling of cohort crown area in the output files? #1126

Open
mpaiao opened this issue Dec 6, 2023 · 3 comments
Open

Scaling of cohort crown area in the output files? #1126

mpaiao opened this issue Dec 6, 2023 · 3 comments

Comments

@mpaiao
Copy link
Contributor

mpaiao commented Dec 6, 2023

I am adding a new crown area variable to the output (by size class and PFT). I was trying to build on existing variables in FatesHistoryInterfaceMod.F90, but I am somewhat confused. When defining crown area by size class, the cohort variable is scaled by 1 / m2_per_ha:

hio_crown_area_canopy_si_scls(io_si,scls) = hio_crown_area_canopy_si_scls(io_si,scls) + &
ccohort%c_area / m2_per_ha

hio_crown_area_understory_si_scls(io_si,scls) = hio_crown_area_understory_si_scls(io_si,scls) + &
ccohort%c_area / m2_per_ha

However, when defining crown area by PFT, the cohort variable is scaled by AREA_INV:

hio_crownarea_si_pft(io_si, ft) = hio_crownarea_si_pft(io_si, ft) + &
ccohort%c_area * AREA_INV
if (ccohort%canopy_layer .eq. 1) then
! Update PFT canopy crown area
hio_canopycrownarea_si_pft(io_si, ft) = hio_canopycrownarea_si_pft(io_si, ft) + &
ccohort%c_area * AREA_INV
end if

Is there any reason for the different scaling, or should both be scaled by AREA_INV?

@ckoven
Copy link
Contributor

ckoven commented Dec 7, 2023

@mpaiao I think it is the same conversion? i.e. multiplying by AREA_INV is the same as dividing by m2_per_ha. I think the implied meaning of the unit conversion is very slightly different though; AREA and AREA_INV are what set the nominal size of a FATES site to be 1 hectare, but in theory at least that could vary, and if it did, then the m2_per_ha would no longer be the correct unit conversion. So in principle AREA_INV would seem to be a very slightly safer unit conversion. Also seems weird that the two constants live in different modules.

real(r8), parameter, public :: area = 10000.0_r8 ! Notional area of simulated forest m2
real(r8), parameter, public :: area_inv = 1.0e-4_r8 ! Inverse of the notion area (faster math)

! Conversion factor: m2 per ha
real(fates_r8), parameter, public :: m2_per_ha = 1.0e4_fates_r8

@mpaiao
Copy link
Contributor Author

mpaiao commented Dec 7, 2023

@ckoven Thanks for clarifying. In the short term, I will replace m2_per_ha with AREA_INV when I submit the PR for the additional crown area variable, if anything, to be consistent with the other crown area conversions.

But maybe we can have a long-term discussion on whether or not to even have a nominal area at some point. If nplant is defined as a true demographic density (stems m−2), then the site area is not really needed for anything, and it would reduce the number of multiplication operations in the code.

@ckoven
Copy link
Contributor

ckoven commented Dec 7, 2023

@mpaiao agreed, that would be nice (but also will probably touch everything!)

mpaiao added a commit to mpaiao/fates that referenced this issue Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ❕Todo
Development

No branches or pull requests

2 participants