Current Cactus/CarpetX behavior allows conditional expressions in schedule.ccl, but only before a SCHEDULE foo block. This means that routines whose READS/WRITES or other actions/metadata that depend on runtime parameters currently require multiple near-duplicate schedule blocks, one for each branch.

For example, a routine such as function_set_xyz may optionally read or write gridfunctions x, y, and z depending on parameters such as param_set_x, param_set_y, and param_set_z. Scheduling each branch properly would take 2^3 = 8 schedule blocks.

Allowing (single or multiple) conditional expressions after the scheduled routine declaration would let one schedule block cover all branches of behavior. The parser/build system could expand the conditional schedule metadata at compile time, while the actual selected branch would still be determined at runtime from result of the conditionals.

Should be a relatively safe,"opt-in" style feature that requires a thorn to move their conditionals somewhere that previously was invalid. In principle it does admit some risk if used improperly. A thorn could cover all possible branches determined by runtime parameters without explicitly scheduling them, supporting some branches of behavior accidentally.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2956/carpetx-allow-conditional-expressions