Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI software / model selection #14

Open
Lestropie opened this issue Jun 11, 2024 · 2 comments
Open

CLI software / model selection #14

Lestropie opened this issue Jun 11, 2024 · 2 comments

Comments

@Lestropie
Copy link

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
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants