PeerHerholz / bids_bep16_conv

A small package to implement conversions between BEP-16 (Diffusion Derivatives) compliant datasets and other/existing software outputs.
https://peerherholz.github.io/bids_bep16_conv
BSD 3-Clause "New" or "Revised" License
0 stars 2 forks source link

CLI software / model selection #14

Open Lestropie opened 2 weeks ago

Lestropie commented 2 weeks ago

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.

PeerHerholz commented 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

Lestropie commented 2 weeks ago

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.