Replies: 1 comment
-
Actually, it's probably cleaner to have the @dataclass()
class StemAllometry():
"""
* Data class containing allometric predictions from stem traits.
* Core data class for Communities - holds actual stem allometries
"""
# Init vars
stems: InitVar[StemTraits | Flora]
dbh: InitVarNDArray
# Post init attributes
stem_height: NDArray[np.float32] = field(post_init=True)
...
canopy_z_max: NDArray[np.float32] = field(post_init=True) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
With the current WIP pull requests #296, there is now quite a lot of structure and function in the
demography
modules. The implementation in #296 has a good chunk of the functionality we want but the internal structures are a little creaky. There is a whole lot of dictionaries of variables and also a lot of symmetries in the data structure that we aren't making use of.So - I moaned about this in #296. Given what is in that PR, I'd rather aim towards something where we have:
Here's a more thought through sketch of some signatures.
Flora
The Flora class is a
dict
ofPlantFunctionalType
instances. I think originally that was primary use mode we envisioned, but actually all of the internal usage is of theFlora.data
attribute (which is a dict of arrays). On top of that, the internals of the Community and Canopy make extensive use of arrays ofPlantFunctionalType
traits. So I think we have basically four objects that have extremely similar internals.Allometries
The T Model code can then keep the individual functions with low level signatures but provide a high level API that generates a
StemAllometry
object:Allocation model
The allocation model takes specific stem allometries and calculates the expected allocation of GPP across the stem. It can take a very similar form to the allometry.
Beta Was this translation helpful? Give feedback.
All reactions