o-smirnov
commented
2 weeks ago Schema-muting parameters can contain substitutions, but they must be resolvable at prevalidation time.
So this distinction popped up in breifast, where wsclean is invoked as:
intervals-out: =steps.ms-info.num-intervals / recipe.htc.cadence
pol: =recipe.stokesThe pol input is resolvable at prevalidation time, so it knows whether to configure multistokes-style outputs. The intervals-out input is only resolvable at runtime, as it depends on another step. Thus at prevalidation time, the dynamic schema evaluator doesn't necessarily know that wsclean is being invoked in multi-interval mode (even though the recipe dev knows that this must be the case.)
The solution (which I already had in the cab a while ago to address a similar problem with channels-out) is to add "hinting" inputs called multi.stokes, multi.interval and multi.chan. There are not passed to wsclean (they're marked as skip: true in their policies), but they tell the dynamic schema evaluator "trust me, I know, this is going to be invoked in multi-interval mode, please set up outputs accordingly".
Anyway I'm reasonably happy with this solution, so please feel free to merge the associated PR.
This is the root cause of https://github.com/caracal-pipeline/cult-cargo/issues/48.
This was a known limitation when I implemented dynamic schemas:
Dynamic schemas must be resolved at prevalidation -- can't change at runtime!
Any schema-muting parameters must be constants (e.g.
pol: IQUV). They can't be formulas/substitutions, as I thought things would just get too arcane otherwise.Now I've gone and tripped myself up with
pol: =recipe.stokes, which actually seems like a very reasonable use case...After a bit of twiddling, I can see a more relaxed set of limitations can be supported with little effort:
Dynamic schemas must be resolved at prevalidation.
Schema-muting parameters can contain substitutions, but they must be resolvable at prevalidation time.