-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
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:
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 " If, for a single App invocation, the same model is to be fit using multiple different softwares, then in that case the |
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.
The text was updated successfully, but these errors were encountered: