Refactoring the leaf phenology code (both cold and drought deciduous)

[mpaiao]

Task description

Through a few discussions with other FATES developers, several variables that are currently defined in sub-routine phenology would probably be better defined elsewhere, so they can be used by other parts of the code that are under implementation or planned. Examples include a crop model, crown fire, and mortality functions.

I started migrating these functions to a new module, and I will use this issue to discuss a few points that could use some feedback before I wrap up a pull request.

Update. Separating growing degree days from the leaf phenology code is a bit more involving than anticipated, because many updates on GDD state are currently bound to phenology status. They can be separated, but this will become more a refactoring of the phenology code in general, so I renamed the issue.

[mpaiao]

I noticed that the cold deciduous phenology has one check that prevents leaves from flushing if the temperature never drops below the chilling temperature threshold (5°C, if using the default value of fates_phen_chilltemp).

fates/biogeochem/EDPhysiologyMod.F90

Lines 1116 to 1133 in 7c45878

	!LEAF ON: COLD DECIDUOUS. Needs to
	!1) have exceeded the growing degree day threshold
	!2) The leaves should not be on already
	!3) There should have been at least one chilling day in the counting period.
	! this prevents tropical or warm climate plants that are "cold-deciduous"
	! from ever re-flushing after they have reached their maximum age (thus
	! preventing them from competing
	if ( any(currentSite%cstatus == [phen_cstat_iscold,phen_cstat_nevercold]) .and. &
	(currentSite%grow_deg_days > gdd_threshold) .and. &
	(currentSite%cndaysleafoff > ED_val_phen_mindayson) .and. &
	(currentSite%nchilldays >= 1)) then
	currentSite%cstatus = phen_cstat_notcold ! Set to not-cold status (leaves can come on)
	currentSite%cleafondate = model_day_int
	currentSite%cndaysleafon = 0
	currentSite%grow_deg_days = 0._r8 ! zero GDD for the rest of the year until counting season begins.
	if ( debug ) write(fates_log(),*) 'leaves on'
	endif !GDD

The comment indicates that this is to avoid cold-deciduous plants to grow in the tropics. I can see how not having such check may allow cold-deciduous plants to grow in the tropics. But I am also wondering what happens in relatively mild subtropical/mid-latitude places, where some plants may be seasonally deciduous but the daily average temperatures may never or only rarely drop below the threshold.

[mpaiao]

After a quick chat with @glemieux yesterday, the current plan for the refactoring is the following (each item being a separate pull request):

• Create a new module for cumulative/memory variables (main/FatesCumulativeMemoryMod.F90). This step will be intended to be bit-for-bit, and will have the following features (Update, this is pull request Migrate 10-day memory variables out of the main phenology sub-routine #1389):
  a. Main sub-routine UpdateCumulativeMemoryVars that will be called from sub-routine ed_ecosystem_dynamics (main/EDMainMod.F90)
  b. Three sub-routines called from UpdateCumulativeMemoryVars: (1) UpdatePhenologyDate, which will just update the phenology time; (2) UpdateCumulativeThermal, which at this point will just update the canopy temperature memory; (3) UpdateMemoryMoisture, which will update the soil moisture / soil matric potential memory variables.
• Update the code for cold-deciduous parameters and trackers, so they are PFT-specific. This will be bit-for-bit too, but will allow different PFTs to have different temperature requirements (Update, this is pull request Make cold deciduous variables and parameters PFT-specific #1392).
• Add a new capability to the code to track the minimum daily btran, which can inform the leaf phenology routines. This implementation is just adding new reporting variables, and should be bit-for-bit (Update, this is pull request Add summary metrics for btran (and expand capability of running averages) #1409).
• Streamline the multiple cold-deciduous decisions on whether to flush or abscise leaves, so they are more similar to the drought-deciduous code. This will likely not be bit-for-bit, because the current code checks the phenology through multiple, but independent if statements, and the streamlined version would have one if/elseif/.../else/end if structure. The latter is preferable because it ensures only one transition is possible at any time step (Update, this is pull request Additional changes to streamline the phenology code (not bit-for-bit) #1396).
• Add a btran memory to UpdateMemoryMoisture and switch the soil moisture-based drought deciduous (which is currently deprecated) with a btran-based drought deciduous. This will address issue Reconcile parameters and scales driving leaf phenology and mortality #1363, and this change will not be bit-for-bit. The soil moisture memory variable will not be deleted, because it may be used for the crown fire module, but it will no longer be used for drought deciduous (Update, this is pull request Btran (of fmc) based drought deciduous phenology thresholds #1411).
• Refactor hydraulic failure mortality so the parameters have equivalent meanings as the drought deciduous thresholds. This is not bit-for-bit, but results should be nearly identical when FATES-Hydro is enabled. Changes expected when FATES-Hydro is disabled (Update, this is pull request Updates to hydraulic failure mortality #1427).
• Separate the growing degree days (GDD) and number of chilling days (NCD) from the leaf phenology update, and address sub-issues Source for current Number of Chilling Days "clock reset" dates? #1384 and Remove phenology controls from Growing Degree Days integration? #1386 (addressing may mean no changes if we decide to keep the current formulation). This will likely not be bit for bit, but will allow using growing degree days for other parts of the code.
• Move the GDD and NCD updates from the phenology sub-routine to UpdateCumulativeThermal, so these quantities are available to other parts of the code. This should be bit-for-bit when compared to the previous step
• (Potential follow-up development) Implement different approaches for cold-deciduous phenology, based on alternative models described by Botta et al. (2000), which may be more appropriate for biomes other than temperate, broadleaf-dominated, deciduous forests (discussed in Alternative models for cold-deciduous phenology? #1390).

This is just to keep track of the tasks, and I may update this comment if needed, but please let me know if you have any suggestions or concerns.

[mpaiao]

One suggestion for step 1 is to use the existing FatesRunningMeanMod instead of creating a new module. For now I am coding it in a new module, but it should be very trivial to move these new sub-routines to FatesRunningMeanMod.

If you have a strong preference for one way or the other, please use the reaction button, let's say thumbs up for making a new module, thumbs down for not creating a new module and using FatesRunningMeanMod instead.

[rosiealice]

Is it maybe slightly neater to put then in the existing routine so that there aren't loads of places where one might search for these things? I probably haven't thought enough about this to have a considered opinion but generelle it's great that you are doing this.

[rosiealice]

Is it maybe slightly neater to put then in the existing routine so that there aren't loads of places where one might search for these things? I probably haven't thought enough about this to have a considered opinion but generelle it's great that you are doing this.

[rosiealice]

Also, on this general theme, in my global simulations i am seeing near universal death of the drought deciduous plants from hydraulic failure in the first couple of months. I suspect that your Btran fix might well alter this behaviour, but just wanted to report that this is the present state of things...

[mpaiao]

Also, on this general theme, in my global simulations i am seeing near universal death of the drought deciduous plants from hydraulic failure in the first couple of months. I suspect that your Btran fix might well alter this behaviour, but just wanted to report that this is the present state of things...

Thanks for the feedback! Indeed this is something I started seeing in my runs too, after I changed the hydraulic failure mortality parameters. This is actually the main motivation for coding a btran based threshold. By using the same environmental variable for both mortality and leaf phenology, and comparing their values before running FATES, hopefully there will be less risk of mortality that could be prevented by deciduousness. Out of curiosity, are you also seeing much termination mortality?

[mpaiao]

Is it maybe slightly neater to put then in the existing routine so that there aren't loads of places where one might search for these things? I probably haven't thought enough about this to have a considered opinion but generelle it's great that you are doing this.

I tried to migrate the code to FatesRunningMeanMod.F90, but it will not work due to module circularity with EDTypesMod.F90.

[rosiealice]

Just today I concur with the idea of making the mortality threshold indexed via the same metric as the lead drop. The current threshold units are quite hard to process/interpret...