The hrdro output ERROR

[LianGong98]

I am running FATES in CESM2.2.0 and the FATES tag is sci.1.30.0_api.8.0.0. I used two pfts_(broadleaf_evergreen_tropical_tree and broadleaf_hydrodecid_tropical_tree_) in BCI . If I turn off the plant hydro the outputs of the GPP seems normal. However, when I turn on the hydro, the AGB always decrease and the GPP less than nohydro.

I tried to adjust some parameters,such as the fates_leaf_BB_slope, fates_leaf_long, fates_roota_par,fates_rootb_par ,but the following error is easily to occur:
ERROR in plant hydraulics
The HLM predicted transpiration flux even though no leaves are present?
The HLM predicted a non-zero total transpiration flux
for this patch, yet there is no leaf-area-weighted conductance?
I guess that most likely the trees are dead what should I do to avoid this mistake? what parameter to adjust? or turn off all mortality first?

[rosiealice]

Hi @LianGong98. I would try this in SP mode, (use_fates_sp=true) to look at the hydro dynamics without the feedback to carbon dynamics and mortality..

[LianGong98]

Hi @rosiealice ,I am so sorry to bother you again and again!! I find that I could not run SP mode, unless I update FTAES ,but I can not update it successfully. If I still use the sci.1.30.0_api.8.0.0 tag, is there a better soluntion to the hydro problem?
Any help would be greatly appreciated!

[rosiealice]

Some possible issues:

1. The soil water initialisation is too dry and kills things off before it equilibrates? If the data you plot are from the first year of the simulation, this looks likely to me,
2. The conductances are too low and are throttling the GPP, but this seems less likely as the GPP is still low when conductance is the same. Is that because the LAI has changed for the hydro runs and the conductance is expressed per unit leaf area?
   Maybe if you plotted total soil moisture and lai also that would help diagnose?

[LianGong98]

OK ,Thank you very much! I just plotted total soil moisture and total lai of the first year and second year

[LianGong98]

Maybe the picture below is clearer

[rosiealice]

What is the timestamp of these plots?

[rosiealice]

Maybe related to this #994 ?

[LianGong98]

I am a little confused, that seems to improve the establishment of forest in bare ground simulations, I just initialized from the inventory data,but changing use_fates_planthydro to use_fates mabay a good advise.Thank you very much!

[LianGong98]

Thank you very much! The H2OSOI much higher than before after I made this change,but I have another question, what's the impact mortality and the termination mortality?

[rgknox]

When a tree in the upper canopy dies, if the user has set a non-zero disturbance_fraction, it will create a newly disturbed patch of land in the space it previously occupied. We assume that a fraction of the understory plants die from getting hit by the original tree-fall in this newly created area (impact mortality).

Termination mortality does not really have a direct association with any process in nature. FATES uses this to get rid of cohorts in the model when either their number density is incredibly small and inconsequential, or they have reached some impossible status such as negative amounts of carbon. The argument is if the plant is doing so poorly that if it has negative values, it will die soon anyway and we should get rid of the cohort before the negative (which is impossible in nature) values get large and have an impact on the carbon balance of the forest.

I'm not sure if others feel the same way, but I would not expect a well calibrated model to produce much termination mortality, particularly in areas where I would expect those plants to thrive. The plants should instead be dying from mortality mechanism connected to nature, like carbon starvation, hydraulic, fire, etc...

[LianGong98]

That's quite clear, great appreciation! It means that well parameters calibration will not produce much termination mortality? And If I want to disable all mortality,whcih code should to modify? I only find in EDMortalityFunctionsMod.F90 : logical, parameter :: test_zero_mortality = .false.

[LianGong98]

Hi @rgknox @rosiealice When trun on the plan hydro model,why the hydraulic mortality of small trees was so high? It's been bothering me for months.
Any help would be greatly appreciated!

[rosiealice]

Also to confirm. This is just with hydro on? (There is a pseudo hydraulic mortality in non- hydro fates, which is triggered by low soil water potential, but it might just not be as intense in its current parameterization.

[LianGong98]

I replaced use_fates_planthydro with use_fates,the initial soil moisture higher than before, but the same error always occurs:
ERROR in plant hydraulics
The HLM predicted transpiration flux even though no leaves are present?
The HLM predicted a non-zero total transpiration flux
for this patch, yet there is no leaf-area-weighted conductance?
the meteorological data I used from 1986-2017 in bci Panama, I am not sure if there is someting wrong with the data, because I got it from my mentor.
The initial soil moisture after replaced use_fates_planthydro with use_fates:

[rosiealice]

This looks more sensible, but it’s hard to say with soil moisture content on its own. Doe you have soil moisture potential output too?

[rosiealice]

My guess, given that the non hydro version runs ok, is that there might be an issue with both the initial soil moisture and the hydraulics parameters. One thing you can change to tone down the hydraulic mortality is to change the mortality scalar,

fates/parameter_files/fates_params_default.cdl

Line 1254 in 7f448b0

fates_mort_scalar_hydrfailure = 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6,

to a very small number (or maybe it would even work with 0?) and that might help it to run far enough out that you can diagnose the important parameters.

[LianGong98]

I just have the leaf water potential
for broadleaf evergreen tree:
the cohort1's leaf water potential

and cohort2-cohort14

[rgknox]

I would recommend evaluating mortality by dividing the result by the number of plants, so that you are looking at mortality rate as a fraction of the population, instead of an absolute value. Since the smallest cohorts have the highest number density, they will also have the highest mortality counts.

[rgknox]

regarding the transpiration error. There seems to be some miscommunication between fates and clm. FATES believes there are no leaves in the patch, so no transpiration. However, clm thinks there is transpiration according to the code in CanopyFluxesMod.F90.
Transpiration is derived from the "rppdry" term here:

https://github.com/ESCOMP/CTSM/blob/ctsm5.1.dev120/src/biogeophys/CanopyFluxesMod.F90#L1132

If it it true that there should be no transpiration, there should be no leaves, and the laisun and laisha terms should be zero:

print*,"patch: ',p,'shade: ',laisha(p),'sun: ',print*,laisun(p)

This is where FATES tells CLM what laisun and laisha are: https://github.com/ESCOMP/CTSM/blob/ctsm5.1.dev120/src/utils/clmfates_interfaceMod.F90#L1937-L1938

Here is where we fill in laisun and laisha on the fates side:
https://github.com/NGEET/fates/blob/main/biogeophys/EDSurfaceAlbedoMod.F90#L1225-L1226

However, now I am noticing a potential inconsistency, that call just mentioned uses calc_areaindex()
https://github.com/NGEET/fates/blob/main/biogeophys/EDSurfaceAlbedoMod.F90#L1223

But see here: https://github.com/NGEET/fates/blob/main/biogeochem/EDCanopyStructureMod.F90#L2081

We do impose a minimum LAI. So I could see how we are forcing transpiration to happen, even when there is no conductance.

@LianGong98 , we have been trying to change this parameter to zero for a while now and have encountered some strange behavior, but I think it could be the root of your problem.

Try changing ai_min to 0 and see if that works for you:
https://github.com/NGEET/fates/blob/main/biogeochem/EDCanopyStructureMod.F90#L2041

[everpassenger]

Thanks a lot Ryan. It helps a lot. BTW, @LianGong98 is my granduate student.

[rgknox]

I'm going to put a note for us to talk about this at the developers meeting today

[LianGong98]

@rgknox Great appreciation! I will have a try. And can this miscommunication be avoided if I use FATES in E3SM?

[rgknox]

no, sorry, the same issue is with both models, since the minimum is imposed on the FATES side of the code

[LianGong98]

@rgknox I have another problem, the file https://github.com/NGEET/fates/blob/main/parameter_files/patch_default_bciopt224.xml just based on fates_params_default.cdl. In other word, only parameters listed in patch_default_bciopt224.xml changed in fates_params_default.cdl and keep the default for other parameters?

[rgknox]

yes, and you can use the following python script to apply the changes listed in the xml, and create a new parameter file: https://github.com/NGEET/fates/blob/main/tools/BatchPatchParams.py

I would try running that script (from the parameter file directory) like so, to see the command options:

python ../tools/BatchPatchParams.py --help

[LianGong98]

That's great! Thank you very much!

[rgknox]

@glemieux and I are going to try removing that LAI minimum I mentioned in the comment above, and run some tests. This will manifest as a pull request and will cross-reference here when it is generated. The tests are not oriented around solving @LianGong98 's problem, the tests are to make sure that the change does not create problems elsewhere in the model.