Characteristic flows?

[RomeshA]

In some cases, it could be useful to consider flows into or out of a compartment group, as defined by a characteristic. Would it work to support link syntax for characteristics without denominators? For example

Compartments:
sus_unvac
sus_vac
inf_unvac
inf_vac

Characteristics:
sus - sus_unvac, sus_vac
inf - inf_unvac, inf_vac

Flows
:inf - equivalent to [:inf_unvac , :inf_vac]

[RomeshA]

@Rowanmh I kind of like this idea, and the easy way to conceptualise it would be to say the syntax is src:dst:par where src is a collection of compartments and dst is a collection of compartments, and a link will match this if the link's source is in the set of src compartments and the destination is in the dst set of compartments. If the user enters a compartment for the src or dst then the collection consists of only that one compartment. But if the user enters a characteristic, then src or dst will be the list of compartments included in that characteristic.

That also neatly resolves the question of what should happen if the user enters a compartment for one variable and a characteristic for the other e.g., sus_unvac:inf.

However, this syntax will also match links that are internal to the characteristic. For example, if the user entered sus:, :sus, or sus:sus then the link from sus_unvac:sus_vac would be retrieved. This might be confusing? It might make sense to exclude links where the source and destination compartment belong to the same characteristic. But what if there was another characteristic

vac - sus_vac, inf_vac

If we requested sus:vac it would be sensible to return the link from sus_unvac to sus_vac. But sus_vac belongs to both sus and vac, so how would we know that we are supposed to accept this link even though it the link's destination is in the source characteristic? Or similarly, at the moment src:dst:par is strictly a subset of src:dst which is strictly a subset of src:. But with the exclusion in place, sus:vac would return a link that does not appear in sus:.

Originally I was thinking it be OK to just implement it in the straightforward well-defined way, which would probably be fine for most of the common use cases - envisaging that this syntax would probably be most useful when the characteristics don't overlap (like the sus:inf example above). But in models with multiple pathways, it would still be easy to accidentally slice them in dimensions that do have internal links. For example, in the TB model with DS/MDR/XDR, it might make sense to consider flows from undx:dx that encompass all of the streams simultaneously. But instead working with ds: would result in encountering the issue above.

So the question would be, would users be able to understand what's happening easily enough? Or would this be more confusing than it is useful?

[Rowanmh]

Right, so the goal here is that instead of specifying a current function that looks like:
spds_undiag:spds_diag + spmdr_undiag:spmdr_diag + pxdr_undiag:spxdr_diag + snds_undiag:snds_diag + snmdr_undiag:snmdr_diag + snxdr_undiag:snxdr_diag

You could instead just write:
tb_undiag:tb_diag

which would match 36 possible combinations, of which the 6 above have a value?

Not sure I understand all the issues with internal link edge cases?

Sort of seems like it might make for some cleaner syntax functions (especially for maintenance when e.g. adding or removing streams) if anyone can remember the option exists, but also introduce bizarre outputs that make no sense but aren't technically wrong if you find the edge cases?