Reserved argument for checking viability of execution

[Lestropie]

Redirected from comment in BEP027 Google Docs page per prompt from @effigies.

It's possible that the suggestion may still be premature given the current state of the specification; I've not kept up to date with the developments here. Just writing out the proposal and you can do with it as you see fit.

Imagine you are someone who provides to end users a computational service. They have a set of BIDS Apps that they maintain. A user comes along, and they have different data that have used different acquisition protocols. They want to know which analysis pipelines are applicable to different subsets of their data.

As a first pass, you could simply say: "If you have MR data of modality X, then pipeline A is applicable. If you have data of both modalities X and Y, then pipeline B is applicable.". However the situation could potentially be far more complicated. Pipelines could be dependent on the presence of specific metadata, which may not be present in all circumstances depending on eg. scanner OS version. It may be that just the presence of data of a specific modality is not sufficient to guarantee pipeline applicability, there could be weird requirements esoteric to that specific modality / pipeline; eg. compulsory availability of image data with which to do EPI distortion correction.

What might be convenient from the perspective of that service provider would be as follows. The BIDS Apps interface specification has a reserved flag argument name for this purpose; let's call it "--viability" for now. If that argument is specified, then the App will do as much of its internal processing as possible to construct the execution graph, which may be dependent on data availability / metadata contents / any weird esoteric knowledge. But it will then terminate, yielding a return value indicating whether the construction of that graph was successful, and not commence any expensive data processing computations. In this way, a computational service could automatically determine for any given dataset which pipelines are applicable. Further, any potential incompatibility between a given input dataset and some set of arguments could also be verified.

Over and above this potential utility, it would also discourage design patterns that just proceed with expensive computations and maybe encounter some error partway through, encouraging instead the use of more robust workflow construction mechanisms.

While any individual App could hypothetically implement such a feature in a standalone manner, the real utility of the idea only comes if the interface to the mechanism is described in the specification.

It may be that some simpler Apps just don't implement support for it; whereas for others that are already using robust workflow management engines, it would likely be a few lines of code to insert a premature termination between workflow construction and commencement.

[effigies]

I think --dry-run is an extremely common flag for this sort of behavior. I would suggest adopting that.

[effigies]

Is there a reason to move this from execution-spec?

[Remi-Gau]

yes because we are moving the execution spec to the new bids website and will be shutting it down.

[Remi-Gau]

https://bids-website.readthedocs.io/en/latest/execution/src/index.html

[effigies]

Oh. I hadn't realized that spun-off specs were part of the websites might be consolidated. The website IMO is for public communication, so the starter kit for instance makes sense. Specifications that are (or should be) versioned and provide (or should provide) dedicated tooling seem like poor fits to me. For example, stats-models was written as a JupyterBook along with a Pydantic model that could generate JSON schema. That seems like a very poor fit for an mkdocs site.

[effigies]

Moving discussion to a new issue: bids-standard/bids-website#432.