Max Btran Value Eqaul to 0.8 in Static Structure Mode

[DanyangYu]

Describe the issue

Dear Sir or Madam,

I am writing to report an issue I encountered when running the ELM-FATES model on Perlmutter. Specifically, the maximum Btran value with the static structure remains fixed at 0.8 (see Attachment 1).

To investigate, I compared the temporal changes of soil water potential and root biomass across soil depths between the dynamic and static structures (Attachments 2 and 3). These results appear normal, which leads me to suspect that the issue may stem from the source code.

Could you please share your thoughts on where this error might originate? Your guidance would be greatly appreciated.

Best regards,
Danyang

Relevant log output

FATES tag

sci.1.84.0_api.40.0.0

Host land model tag

e3sm v3.1.0-alpha-2720-g5264437aaa

Machine

perlmutter

Other supported machine name

No response

Additional context

No response

[rgknox]

@DanyangYu , myself and others had some email exchange on this. I want to note my thoughts from the email so it's in record here:

" With some static configurations, ie those that use the fixed biogeography mode, the fraction of naturally vegetated lands are fixed. I wonder if in this case, this fraction is 80% of the land. And therefore, the BTRAN history output variable (which may be on the CLM side of the code, depending on the specific output variable) is averaging in a 0 for 20% of the area... FATES side diagnostics, ie any history variable that starts with "FATES_" will be sure to NOT include area not under FATES jurisdiction (by treating that area as "ignore"), and therefore should not have this problem. I would have to look at how CLM/ELM performs their btran calculation though, to see if they average in zeros."

In fully dynamic fates, the vegetated fractional area would change and potentially reach 100%, so I could see how we would not encounter the issue in that configuration (given the above hypothesis).

[jennykowalcz]

Would looking at FATES_BTRAN_SZPF help diagnose this? (@DanyangYu this variable is inactive by default but you could add it to your history file.)

[DanyangYu]

Thanks, Ryan and Jenny! We found that the reason the Btran values reach around 0.8 is due to the inventory files. In some patches, vegetation may not grow, resulting in a Btran value of 0. When these patches are aggregated, the overall Btran values are approximately 0.8. Therefore, it is not due to the code!