Annual fAPAR_max and LAI_max

[MarionBWeinzierl]

Description

Implements the computation of fAPAR_max and LAI_max, and provides examples usages of the API (including test data).

Fixes #348 .

Type of change

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Key checklist

• Make sure you've run the pre-commit checks: $ pre-commit run -a
• All tests pass: $ poetry run pytest

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 25.00000% with 78 lines in your changes missing coverage. Please review.

Project coverage is 93.57%. Comparing base (2d06b2b) to head (a077164).
Report is 64 commits behind head on develop.

Files with missing lines	Patch %	Lines
pyrealm/phenology/fapar_limitation.py	16.12%	78 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #403      +/-   ##
===========================================
- Coverage    96.26%   93.57%   -2.69%     
===========================================
  Files           34       36       +2     
  Lines         2652     2756     +104     
===========================================
+ Hits          2553     2579      +26     
- Misses          99      177      +78     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MarionBWeinzierl]

@davidorme , could you have a look and sense-check what's there? As you suggested in #407 (I hope I understood that right) I used Scaler directly, rather than extracting any functionality.

[davidorme]

Some optimisations and a couple of issues. I think we're on the right track here. I did wonder about making the class __init__ accept daily/subdaily observations and moving the resampling in the from_Pmodel into there, but on balance I think it is right to have the straightforward usage as __init__ and then use factory methods to handle other core inputs.

[davidorme]

I think this need to check we are dealing with whole years in the input?

[MarionBWeinzierl]

Wondering whether this should be something similar as in __init__ of scaler, or something much more simple (like checking that growing_season can be divided by 365 or 366).

[davidorme]

Yeah - this was tying me in knots as well. I think it needs to be something similar to the scaler init. We want to:

• Check that the timing is regular - although that is a pain when we want to support e.g. weekly or monthly inputs
• Check that there are the same number of observations per year - although that is a pain for leap years at daily precision.

[MarionBWeinzierl]

OK, I implemented a check for the datetimes. I am sure I have missed something...

Probably a good time to implement tests.

[MarionBWeinzierl]

It currently assumes daily or subdaily inputs

[davidorme]

More thoughts - not fully formed!

[davidorme]

Yeah - this was tying me in knots as well. I think it needs to be something similar to the scaler init. We want to:

• Check that the timing is regular - although that is a pain when we want to support e.g. weekly or monthly inputs
• Check that there are the same number of observations per year - although that is a pain for leap years at daily precision.