FMU instances with leading numerals

[kgpierce]

In Maestro 1, multi-model configurations permit instances with leading numerals, e.g.

{ "fmus": { "{robot}": "robot.fmu", "{visual}": "visual.fmu" }, "connections": { "{robot}.robotti_global.x": ["{visual}.3d.x"], "{robot}.robotti_global.y": ["{visual}.3d.y"] } }

This is not valid in Maestro 2 due to the leading numeral in the instance "3d":

line 42:6 mismatched input '3d' expecting IDENTIFIER 12:04:52.239 [http-nio-8082-exec-4] ERROR org.intocps.maestro.webapi.controllers.ControllerAdvisor - Internal API Exception ref: b7e9fd92-bf27-46ba-a824-6548918279e1 java.lang.IllegalStateException: failed to parse at line 42 due to mismatched input '3d' expecting IDENTIFIER

Renaming it to e.g. "threed" works fine. There are likely legacy models out there that use "3d" (or similar) due to the nature of many multi-models, so a way to handle this would be good.

[CThuleHansen]

See LegacyMMSupport and add support for this case https://github.com/INTO-CPS-Association/maestro/blob/9d16f56e8c45538b13ce12e78f743085fdfbd302/frameworks/fmi2/src/main/java/org/intocps/maestro/framework/fmi2/LegacyMMSupport.java

[CThuleHansen]

I wonder if this could mess-up websocket related stuff? i.e. the into-cps application might expect these specific keys, and therefore receives some wrong ones. There are two ways to fix this -> store the "original name" throughout maestro2, or return a json mapping with variable renamings, such that the into-cps application can adapt.

[FrederikPM]

It does indeed seem like the into-cps application is unable to draw the graph when the instance names have been changed, but the co-simulation can be executed through the application without other issues. I have implemented a renaming solution in fpm/220, however I think something like the second solution would be better. But that would require a talk with Hugo?