I just realized that the two-way connection of unifmu with ZMQ is never sending the 'Fmi2Instantiate' message (on its FMI2 version, probably also on its FMI3 version).
The order of the messages sent for initialization:
Fmi2SetupExperiment
Fmi2EnterInitializationMode
Fmi2ExitInitializationMode
But Fmi2Instantiate is never called, which should come first (before Fmi2SetupExperiment).
This was probably designed since unifmu was intended to contain the white-box Model and not a black-box FMU on the model backend side.
The template for Python is indeed empty:
if group == "Fmi2Instantiate":
result = Fmi2EmptyReturn()
The template for Java has no case for 'Fmi2Instantiate' and the template for C# is also empty:
case Fmi2Command.CommandOneofCase.Fmi2Instantiate:
{
var result = new Fmi2EmptyReturn();
message = result;
}
break;
According to this, the Model class (or any other black-box FMU) should be instantiated when the message 'Fmi2Instantiate' arrives. It wouldn't affect the overall functionality of the backend.
I just realized that the two-way connection of unifmu with ZMQ is never sending the 'Fmi2Instantiate' message (on its FMI2 version, probably also on its FMI3 version).
The order of the messages sent for initialization:
But Fmi2Instantiate is never called, which should come first (before Fmi2SetupExperiment). This was probably designed since unifmu was intended to contain the white-box Model and not a black-box FMU on the model backend side.
The template for Python is indeed empty:
The template for Java has no case for 'Fmi2Instantiate' and the template for C# is also empty:
According to this, the Model class (or any other black-box FMU) should be instantiated when the message 'Fmi2Instantiate' arrives. It wouldn't affect the overall functionality of the backend.