Tool that allows Functional Mock-up Units (FMUs) to be accessed through language independent RPC calls by wrapping the original FMU into a new one with network capabilities.
While immensely powerful, the JSON-RPC support is difficult to maintain. Especially if supported by multiple server implementations. As far as I know, this feature is not used. Should it just be removed?
Having both single and bulk read definitions in the RPC adds a lot of extra code. The FMI standard itself only have bulk read, and real production code will have to rely on bulk read for efficiency.
Hi,
I would very much like to hear from you, the person reading this.
Why are you interested in this project, have you tried it?
What is unclear, what can be improved?
Bulk read/write should lead to considerable performance gain as fewer RPC calls per time-step are required.
FMI does not support this operation, but FMI4j is working on an extension in NTNU-IHB/FMI4j#125.
However, only frameworks that uses the extension, like Vico, will benefit from this.
Hello,
First of all, great work! The fmu-proxify feature is awesome! Working great when running all in the localhost.
I am getting "no main manifest attribute, in FMU-proxy.jar" both in windows 10 and Linux when I trying to "java -jar FMU-proxy.jar " on the target computer.
In practice there is no need to support two server implementations other than as a proof of concept. The JVM server is the preferred choice. This will make it easier to introduce new features.
Some co-simulation framework does not perform caching of variables. Thus it may repeat calls on getXXX. This is ok when network calls are not involved, but adds considerable overhead when getXXX leads to a RPC call.
I run a setup using the Cosim demo app together with FMU-Proxy version 0.6.2.
The FMUs are hosted in an Nginx docker container and served to another container running the Cosim demo app through http.
FMU-proxy runs in a third docker container.
However, when running this setup I am not able to change the value of boolean inputs to the FMUs, and some boolean values are flickering between true and false.
I have confirmed that the same setup works when running the FMUs directly in the same container as the Cosim demo app.
As suggested in #71 , it would be nice if we were able to wrap one of the clients as an FMU.
This would allow distributed simulation to any FMI compliant tool without modification.
Obvious problem: The modelDescription.xml refers to a specific model.
Solution: Do not provide a modelDescription.xml. Let the user copy it from the target FMU and paste it into the archive we provide.
Similarly the IP and port could be put into a .txt file inside the archive.
https://www.appveyor.com/ is an option.
BUT
The initial un-cached run will take over 60 minutes, making the (free plan) build fail. I had the same problem with CircleCI (out-of-memory). The solution there was to use a docker image.
Supporting vcpkg is time-consuming since it always changes.. Lets use conan only.
I.e thrift is constantly changing, and sources generated with 0.12.0 is not compatible with vcpkg thrift.
These transports have had a history of causing hang-ups during testing. Better to remove them. It's easy to re-add them later if there is a strong wish for them to be present.
Currently, you spawn one proxy per FMU. The original reason for that was that the proxy provided instance specific getter and setters for variables. This feature has since been removed as it is considered to hard to use by the end user.