-
Notifications
You must be signed in to change notification settings - Fork 9
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
Aligning PModel and Subdaily PModel #401
base: develop
Are you sure you want to change the base?
Conversation
…added a few more attributes
Hi @davidorme. Just taken a look at this. Overall I think it looks really good and is a big improvement on what we had before. Areas for improvement:
|
Yup - I agree that could be packaged more cleanly. I'll have a look at this but might park some of this for later polishing. I think the big picture shape of the new API and keeping the tests working is key on this PR.
On the bounds checking - yes, but not here. Once this is done, PPFD and FAPAR will move into PModelEnvironment, and that adds bounds checks already (no issue yet, but see #394) |
Hi @davidorme , is this ready to go now? |
@j-emberton Nope - this is going to sprawl a lot more, but there are a couple of incoming PRs that will make this switch cleaner. |
ah cool. I thought I saw a refreshed request for review come in so thought I'd double check. |
Description
This is a draft of a new structure for the PModel and SubdailyPModel:
PModelABC
, which includes a single abstract class_fit_model
.PModel
andSubdailyPModel
subclasses then:_fit_model
for the class.__init__
method that:super.__init__(...)
to initialise the superclass attributesself._fit_model()
The result aligns the internal attribute names and shares a lot of docstrings and boilerplate. It also dumps the separate
PModel.estimate_productivity
step and movesfapar
andppfd
into the signature of both models.Warning
This is very much a propotype. However, running the code below work and duplicates the results of the notebook that this was copied from.
Prototype code
Things still to do:
__init__
and move them back into the base class once we know how to populate on both models.@cachedproperty
on some of these attributes to keep overheads down, but that seems like a separate PR, and it shouldn't break the API. For example,PModel.rd
might be always calculated or only calculated on request.fapar
andppfd
will move intoPModelEnvironment
and anAcclimationModel
class will bundle a lot of the args toSubdailyPModel
(see discussion PModel API for 2.0.0 #394), but again this can be two separate PRs.Fixes #386
Fixes #385
Type of change
Key checklist
pre-commit
checks:$ pre-commit run -a
$ poetry run pytest
Further checks