Open dfalster opened 5 years ago
It strikes me that there is significant duplication for simple environments. K93Environment
and FF16Environment
are effectively the same.
Brainstorming, with no consideration for how this will affect compilation, there might be room for components that are not specific to one strategy but part of a larger class of models.
For example:
inst
├──include
| ├── evolutionary
| | ├── StochasticPatch.h
| | └── StochasticSpecies.h
| ├── fish
| | └── 3DEnvironment.h
| ├── generic
| | ├── Cohort.h
| | ├── Environment.h
| | ├── Individual.h
| | ├── Patch.h
| | ├── Species
| | └── Strategy.h
| ├── models
| | ├── FF16.h
| | ├── FF16evo.h
| | ├── FF16r.h
| | └── K93.h
| ├── numeric
| | ├── QAG.h
| | ├── Lorenz.h
| | ├── QK.h
| | | .....
| ├── plant
| | ├── LightEnvironment.h
| | └── WaterEnvironment.h
| └── SCM.h
└── RcppR6_classes.yml
would permit FF16
and K93
to use the same plant\LightEnvironment
, while still providing room to specialise.
grow_plant_to_size
-> grow_individual_to_size
res$plant
-> res$individual
lai_error
in run_scm_error
to e.g. competition_error
Note @devmitch - I added something to the list, rename cohort
to node
scm_base_parameters
-> FF16_system
or parameters
?scm_base_control
-> system_control
or delete. We already have Control()fast_control()
-> system_control_fast()
expand_parameters
-> add_strategies
(see #410 )run_scm
-> solve_system
Gradually thinking some renaming of functions, files, classes will help make the material more accessible. For example:
Variables and functions:
height
->individual_size
(#223)plant
->individual
cohort
->node
compute_vars_phys
-->compute_vital_rates
area_leaf_above
->competition
(or other)germination_probability
->establishment_probability
seed_rain
->offspring_arrival_rate
models
folderfiles:
plant.h
->individuals.h
ff16strategy
->strategy_ff16