Open Lestropie opened 2 weeks ago
Hi @Lestropie,
thanks for pointing this out.
Yeah, that's correct. So far, I thought about simply printing some informational messages like "software X does not support model Y" or something akin to that. However, your suggestion of changing things to one argument that is a software-model pair seems feasible as we could simply include the respectively supported approaches as a list for users to check.
Regarding your second point: this would still result in one directory per software-model pair in the output directory, correct? For example:
derivatives/
fsl-dti/
fsl-csd/
dipy-dti/
dipy-csd/
mrtrix-dti/
mrtrix-csd/
Thanks again.
Best, Peer
Any BIDS App should write its derivatives into a directory that is named based on that App. By creating multiple output directories as you propose there, this would become a kind of "meta-App" for running multiple Apps; which I suppose is a thing that could exist, but it's an expansion of scope for what is supposed to be a demonstration of current capabilities.
I would prefer that this App instead create a single derivatives directory. If the results were presented as you do there, then it's kind of like taking the rejected "model-*/
" proposal and sliding it in at the pipeline level instead. Whereas it should be a demonstrable feature of the specification that it's possible for a single pipeline to write output data from multiple models.
If, for a single App invocation, the same model is to be fit using multiple different softwares, then in that case the _model-<label>
entity is not adequate to disambiguate, and so you would need to either include the software name in the model name, eg. _model-dipycsd_*
and _model-mrtrixcsd_*
, or add some other entity to disambiguate, eg. _model-csd_desc-dipy_*
and _model-csd_desc-mrtrix_*
; probably a slight preference for the latter.
Looking at the code, it seems there's currently two separate command-line options: one chooses the software to use, the other chooses the model to fit. I don't think this is the right choice: not all softwares fit all models, so some combinations won't be permitted, and the magnitude of that problem would only get worse with more softwares / models added.
I think a single command-line option, where each individual choice is a specific combination of software & model, makes more sense.
The other thing that would allow you to do is provide as input to this option a list of software-model pairs. Each item in that list would then be computed and exported to the output directory. This is an important capability to demonstrate: the specification needs to support a single dataset containing the results of multiple model fits; whereas if the only data presented were of datasets with one model each, one might not see the utility of certain design decisions.