The metaprogramming in the exploration pipeline has gotten quite gnarly. If we want to hand a version of this repo off to STLT partners, it would be worthwhile to invest in simplifying this. This thread is here to collect possible ways to do this.
Some notes:
The ONE_AHEAD_FORECAST_NAME = forecast_by_ahead global variable seems like unnecessary flexibility, while making it harder to find where the actual prefix is used
There is a lot of misdirection in the creation of the pipeline and those functions depend on global variables. For instance, I wonder how much of targets_utils.R should live in covid_hosp_explore.R; there's the argument that it's duplicated code with flu_hosp_explore.R, but we haven't actually run tests on that data and the non-locality is pretty cumbersome
Could we use dynamic branching across aheads instead of having to do it manually? It should automatically take care treating each ahead as a separate target, caching it, and then aggregating under the same forecaster name afterwards.
Ensembles and ensemble grids complicate things and we don't even use them
Try using eval_select in other situations where we need to aggregate a subset of earlier-mapped targets, see here and the linked discusionss 82
The metaprogramming in the exploration pipeline has gotten quite gnarly. If we want to hand a version of this repo off to STLT partners, it would be worthwhile to invest in simplifying this. This thread is here to collect possible ways to do this.
Some notes:
ONE_AHEAD_FORECAST_NAME = forecast_by_aheadglobal variable seems like unnecessary flexibility, while making it harder to find where the actual prefix is usedtargets_utils.Rshould live incovid_hosp_explore.R; there's the argument that it's duplicated code withflu_hosp_explore.R, but we haven't actually run tests on that data and the non-locality is pretty cumbersomeeval_selectin other situations where we need to aggregate a subset of earlier-mapped targets, see here and the linked discusionss 82