Containerisation

[quantumjot]

As mentioned in #99, it might be good to have an easy-to-set-up containerised version of scivision. In particular this would be useful if we want to deploy (or scale) models on HPC (e.g. Baskerville uses Singularity/Apptainer), in the cloud or as part of a reproducible scientific software pipeline.

Given that scivision currently makes no assumptions about any particular ML framework, this could be quite tricky in practice. Is this something others would find useful?

[ots22]

I've just added some thoughts to the issue.

[edwardchalstrey1]

I think the route we go down on this question will be determined by discussion of how scivision itself should work. If the main USP is the catalog (i.e. dataset-model matching) then perhaps the automation of getting a selected model to instantly run on a selected dataset is a lower priority - this would mean there could be fewer constraints on what constitutes a "model" and that could include say a singularity container that only works on a certain type of HPC setup - but the user knows from the match that this could be useful for their dataset/research question, it's just still up to them to make it work

[ots22]

And in the first case, we know what the container should be able to run - everything in the catalogue!

[edwardchalstrey1]

I was thinking more in this case that a container running a single specific model (with complex requirements making a container valuable) would be referenced in the catalog - matching a dataset to this entry for the model container indicates that it should be possible to get the container's model to run on your dataset

[edwardchalstrey1]

So there are 2 slightly different things discussed here:

1. A scivision image for making containers that run any model in the catalog
2. Allowing model devs to link to a container repo (e.g. DockerHub) as their model url in the catalog, which includes instructions on usage for scivision users who come across it