Closed phipsitn closed 4 months ago
The core goal of the tool is to provide a means for specifying how to spawn a process that handles incoming calls to the FMI api.
You can use any tool to spawn the FMU by modifying the launch.toml
file stored inside the resources
directory of an FMU:
For instance, the docker FMU is implemented by modifying the launch.toml
file such that it spawns a container, which then executes the same code inside.
If you have some other means of deploying like Shiv the code you would modify this code to something along the lines of:
`linux = ["shiv", "command that installs dependencies and executes backend.py"]
Remote deployment can be implemented without modifying the C-binary by modifying whatever files are lunched by the launch.toml
.
In a nutshell, whenever a UniFMU FMU is instantiated the following happens:
launch.toml
and executes the command for the appropriate OSThe idea would be that in step 3 you could specify a command that launches a process on a remote machine. I'm sure that there are plenty of existing tools that can be used for this. If you want to roll out your own solution, you could make a bash script that SSHs into a remote machine and executes a script that implements the FMI.
Eventually I would like to document this behavior but have simply not found the time. In case you are interested you can reach me via mail (see my contact info on my website christianlegaard.com)
I came across your tool and am intrigued by the use of Dockerized python in an FMU. I've tended to steer away from docker if i'm certain that python will be on the end user machine and instead use Shiv by LinkedIn. Shiv eliminates the need to include python but does include the dependencies in a PEP441 zipapp. I'm also interested in your concept from the modelica conference about using a remote docker container connected to an FMU. If you have a paper on that where could I find that? Thanks.