For now we don't have a way to express in the yaml file when the input data spec or the wait on tasks should be taken into account. The only workaround is that if an input data target date falls outside of the date range of the specified data, it's ignored. This allows for the restart mechanism where the first cycle doesn't use a restart file. Conversely, the initial cycle can need an input file that no other cycle uses but we cannot express that so far.
Proposition
Add a when keyword that signifies this input data (or wait on task) spec applies when this condition is met. I would use 3 sub-keywords for that: before, after and at that refer to the current cycle date.
I find it confusing this way because we don't know if these conditions are relative to the cycle date or the data date.
Side benefit
The sirocco.core.TimeSeries class would be obsolete. It was designed to allow for the date bounds checking but this would now be explicitly handled by the user so we can just store items in the internal dict which would raise the KeyError if necessary.
The problem
For now we don't have a way to express in the
yaml
file when the input data spec or the wait on tasks should be taken into account. The only workaround is that if an input data target date falls outside of the date range of the specified data, it's ignored. This allows for the restart mechanism where the first cycle doesn't use a restart file. Conversely, the initial cycle can need an input file that no other cycle uses but we cannot express that so far.Proposition
Add a
when
keyword that signifies this input data (or wait on task) spec applies when this condition is met. I would use 3 sub-keywords for that:before
,after
andat
that refer to the current cycle date.A variation of that could be to skip the
when
keyword and directly have thebefore
,after
andat
at the same level aslag
anddate
:I find it confusing this way because we don't know if these conditions are relative to the cycle date or the data date.
Side benefit
The
sirocco.core.TimeSeries
class would be obsolete. It was designed to allow for the date bounds checking but this would now be explicitly handled by the user so we can just store items in the internal dict which would raise theKeyError
if necessary.