Where and how do we deploy the model?

[Lokkij]

At some point, we'll want to deploy our model somewhere so it can be used by others and with sufficient compute resources so that runs complete quickly. This isn't a huge issue right now, but it's worth thinking about in advance. I'll describe the method we usually use in our department, but of course we can make different choices.

TNO has a contract with Azure, which means we can easily get an Azure subscription (with costs going to a project number). This is where we usually deploy our projects. I think this would be a good option for Tulipa as well, but there are other options if Azure is unsuitable: we have a HESI lab and a sensorlab with a bunch of servers we can use, for example. My proposal would be to go with Azure.

We usually containerise our projects with Docker. This generally removes a lot of the hassle of running the project on different machines/configurations. We can then also set up a continuous deployment pipeline - I have examples for this on Gitlab, but I think Github has a different system for this (GitHub Actions?). For smaller projects like Tulipa simply using Docker compose usually suffices. My proposal would be to use Docker (with compose) for Tulipa.

Any thoughts/opinions? Other options that I haven't mentioned?

[suvayu]

I think this depends a bit on the kind of outcomes we want. For example, a containerised workflow is great when the final result is an application/product that is going to be used a lot. Whereas, it is a hindrance when the goal is to build a collaborative community. What I mean by that is, the community values ease of experimentation, or we want to include subject matter experts who are not very technical, or would like to foster good samaritan contributions.

So the final choice should depend on how we want others to interact with Tulipa, as consumers of the model, or as potential future contributors to the model.

It also depends a bit on what is meant by the model; i.e. is it the same model if someone changes one of the inputs a bit (say a different climate scenario), or maybe extend it to a different economical scenario?

[clizbe]

For dev, locally. For runs, on a server.