Closed rafaqz closed 4 years ago
Great idea
Actually, not sure about this. In a very simple strategy, we would drop most of the content FF16. So agreed we should create a base class with Strategy, but this would not necessarily remove all the duplication. The core functions would be something like this:
class Base_Strategy {
public:
typedef std::shared_ptr<Base_Strategy> ptr;
FF16_Strategy();
// update this when the length of state_names changes
static size_t state_size ();
// update this when the length of aux_names changes
size_t aux_size ();
static std::vector<std::string> state_names();
std::vector<std::string> aux_names();
// TODO : expose this so can access state_names directly
std::map<std::string, int> state_index;
std::map<std::string, int> aux_index;
bool collect_all_auxillary;
// This would get renamed to something more generic - get_competiton_effect ?
double area_leaf(double height) const;
void refresh_indices();
// This would get renamed to something more generic -- compute_rates
void compute_vars_phys(const Environment& environment, bool reuse_intervals,
Internals& vars);
void update_dependent_aux(const int index, Internals& vars);
// [eqn 20] Survival of seedlings during germination
double germination_probability(const Environment& environment);
// * Competitive environment
// This would get renamed to something more generic -- compute_competition
double area_leaf_above(double z, double height, double area_leaf_) const;
// This would get renamed to something more generic -- initial size?
// The aim is to find a plant height that gives the correct seed mass.
double height_seed(void) const;
// Every Strategy needs a set of Control objects
Control control;
std::string name;
};
Base_Strategy::ptr make_strategy_ptr(Base_Strategy s);
}
For sure, it might not save that much code. But it's also useful for being explicit about the core requirements for a strategy. Currently its not so clear to me what is specific to FF_16 and what is general.
Should I put together a pull request with this Strategy class? it would be a good practise run.
Agreed. Yes, sure.
Review for yourself what should be included.
We can also do more layers of inheritance when there are similar strategies that share a larger amount of code than is covered in Strategy
Yes, sounds good.
We should also find a place to pull out those routines integrating assimilation over the leaf area of the plant. While the particular photosynthesis equation may differ among strategies, the integration function is more generic may all be used by multiple strategies. Plus, we'd like to try alternatives for each strategy.
Ok I'll have a look at doing that too.
Addressed via #235
The base Strategy class would include all methods called from the Plant class, and all methods that would be universally required.
This will simplify adding strategies that differ from FF16, but avoid a lot of the duplication that occurred in FW20.