-
Notifications
You must be signed in to change notification settings - Fork 109
Fix bugs in the Tree Recruitment Scheme with seedling dynamics #1572
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
base: main
Are you sure you want to change the base?
Changes from all commits
7d295f2
2afcc3f
1aa229a
006e8a9
0e9f7d8
f2c2233
408c8cd
e047aab
8477b83
5918340
fb4f280
735c4cb
1988d06
356b305
c82ba29
ef6ea7e
8d7e4ca
c4f5097
204dcf4
dc31b22
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2335,8 +2335,12 @@ subroutine UpdateFatesRMeansTStep(sites,bc_in, bc_out) | |
| endif | ||
|
|
||
| ! Update the seedling layer smp and mdd running means | ||
| call cpatch%sdlng_emerg_smp(pft)%p%UpdateRMean(new_seedling_layer_smp) | ||
| call cpatch%sdlng_mdd(pft)%p%UpdateRMean(new_seedling_mdd) | ||
| ! Only update after first model day to avoid adding | ||
| ! initialization spike in smp to running means | ||
| if (hlm_model_day > 2.0_r8) then | ||
| call cpatch%sdlng_mdd(pft)%p%UpdateRMean(new_seedling_mdd) | ||
| call cpatch%sdlng_emerg_smp(pft)%p%UpdateRMean(new_seedling_layer_smp) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We want to make sure that hlm_model_day is continuous across restarts. If for some reason someone is running two day restarts, and hlm_model_day is resetting each time, this running mean will never increment with meaningful data. While I don't think SMP spikes are unexpected at the beginning of a simulation, and your move to ignore them makes sense. But I also wanted to check in regarding frozen soils. I think there was some discussion of it here: SHould we apply some filters to prevent calculations when soils are frozen?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, I see. Re: frozen soils - I think you're right that we need some conditionality, but I don't think we should stop calculations when soils are frozen. We could do something analogous to the phenology code (https://github.com/r-ward/fates/blob/3b58472a513e39fcb8d0dafc7bc0ae31b91f6e95/biogeochem/EDPhysiologyMod.F90#L1222)) and use a lower bound value similar to In the tropics, though, using an Can we differentiate real frozen soils from initialization/erroneous freezing by adding a check on soil temperature? If soil temperature is warm and there is no liquid water, skip the calculations. If soil temperature is freezing, and there is no liquid water, use an smp_lwr_bound. @lmkueppers - what do you think? |
||
| endif | ||
|
|
||
| enddo !end pft loop | ||
|
|
||
|
|
@@ -2410,8 +2414,8 @@ subroutine SeedlingParPatch(cpatch, & | |
|
|
||
| ! Start with the assumption that there is a single canopy layer | ||
| seedling_par_high = atm_par_dir+atm_par_dif | ||
| par_high_frac = 1._r8-cpatch%total_canopy_area | ||
| par_low_frac = cpatch%total_canopy_area | ||
| par_high_frac = 1._r8 - (cpatch%total_canopy_area / cpatch%area) | ||
| par_low_frac = cpatch%total_canopy_area / cpatch%area | ||
|
|
||
| ! Work up through the canopy layers from the bottom layer | ||
| do cl = cpatch%NCL_p,max(1,cpatch%NCL_p-1),-1 | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@r-ward , I'm wondering if this seed_germ_in could potentially be negative. I don't think it can since seed decay is the only negative term in net_seed_available, and it is by definition a fraction of seed mass. Can you verify this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, seed_germ_in is never negative. Although, I guess it is possible for the flux to go negative if fates_recruit_seed_germination_rate or fates_trs_seedling_a_emerg were erroneously set as negative values. Maybe there should be a check on this in FatesCheckParams (I see for example a check against values of seed_dispersal_fraction < 0). I could add something similar. What do you think?