Hi Sofia,
This kind of "dynamic" input selection is not currently possible to achieve using only the command definition. When resolving the inputs to launch a container, the container service expects that there will be a single object for each input. (For example, if it's a scan input, at launch time it expects to find only a single scan.)
I think what we have done for cases like this in the past is to mount the session input—which gives your container all the scan files, even ones you don't need—and push the logic of determining which scans you need into your script that runs within the container.
It's not a super satisfying solution, I know. The ability to have multiple objects for an input is absolutely something that I wanted to do and spent a lot of time thinking about, but it is a tricky problem to solve. The possibilities for what you could potentially want to do are almost endless and all of them are difficult to handle correctly.
(NOTE: What follows is me detailing a lot of the difficulties that this kind of feature would present. Feel free to stop reading now! I thank you for asking the question. It would be super cool if things worked like this and I'm sorry that they don't already. Plus, this is an area of interest for me and I love having the excuse to write about it.)
For instance, let's say you have a scan input that ends up at launch time resolving to N matching scans. What does the container service do with those?
- If the command says the scan input provides files for a mount, CS would need to actually create multiple mount points at different subpaths. That's not something it does right now, but it's potentially doable.
- What if the command has a template in the CLI string that uses some property of that scan input? Does CS repeat the template with each scan object, separating them by spaces? Or does it fill the template in once, joining the N values with commas or some other separator?
- What if the command also derives another input from the scan, like a resource? Then the N scan objects -> N resource objects (assuming all scans have a matching resource). CS would similarly need to have unique subpaths for each resource within the single mount. But if all the resources have the same label, like DICOM, then all those subpaths would collide unless we also included the scan ID in the path. That means CS would need to remember the whole history of how an input was derived when deciding how to deal with it. And does the command need to specify how to construct those subpaths, or is that a standard thing CS always does the same way?
All of the above assumes you want to launch a single container even when an input matches N objects. But what if you don't? What if you want your N matching objects to turn into N container launches, each with only one of the matching inputs? So if I got N matching scans I would launch N containers with one scan each. Further, what if the command has multiple levels of derived inputs that have different numbers of matching inputs; like the root/external input is a subject from which are derived sessions and scans, and I expect that to turn into (number sessions)x(number scans) container launches with 1 session and 1 scan each? Leaving aside the difficulty in actually implementing that, which is considerable, how would I specify in the command the kind of behavior I expect, either N objects -> 1 launch or N objects -> N launches?
Again, thank you for the question! And thank you for pushing against the limits of the container service and the command. I would be happy to hear your thoughts—or the thoughts of anyone else reading this—on how you would expect the container service to handle this. What would you think you would need to write in the command to control this behavior?
John Flavin