Add a `virtual` mode and change the standard name for a simulator from `design` to `model`

[TeresiaOlsson]

I think some updates are needed to the standardized names of the control modes.

1. We are currently missing a virtual mode and are using the name live for configuration for a twin. I think this will cause problems when people start to use pyAML in their control rooms and would like to have both configuration of real machine and twin in the same configuration.

   It also means that there is currently no standardized name for the virtual accelerator mode if you want to write applications which specifically uses that mode.

   My suggestion is to add virtual as standardized name and reserve the name live for the real accelerator.

2. The name design for the simulator is not good because it doesn't work for all machines. For example, for BESSY II and MLS there is no such mode at the moment so it doesn't make sense for us to configure a mode with that name.

   It also causes problems for machines that have several operational modes where there might be low alpha design, low emittance design, etc. There are also many machines which uses this not for different operational modes but for different runs, e.g. run 1 2026, run 2 2026 etc.

   I suggest to instead change it to model. This is also in preparation for eventually be able to implement the possibility to use different operational modes by being able to change what model points to. For example, model could point to design, errors, run 1 2026 etc depending on what simulator the user would like to use at that specific point.

   I think for this the standardized name design can remain. It just when writing applications it shouldn't be considered a mode which all accelerators have.

[gubaidulinvadim]

I don't understand what is this issue about, if I rename design to model in the config file, everything is already possible

you can do the same for `virtual'.

[GamelinAl]

For now I don't see any point in a virtual mode.

For the operation modes, that's another topic but I think we agreed to say for now "one mode = one configuration" no?

[TeresiaOlsson]

I don't understand what is this issue about, if I rename design to model in the config file, everything is already possible

you can do the same for `virtual'.

So sr.model is also available with tab completion? I thought that was the reason why live and design are handled as special cases? If not, why do we have live and design as special cases in the accelerator?

I also thought the point of having the design standardized name was that applications like LOCO can use it. But instead you want applications to include a configuration parameter to say which simulator to use? If so, why is design still needed?

[TeresiaOlsson]

For now I don't see any point in a virtual mode.

For the operation modes, that's another topic but I think we agreed to say for now "one mode = one configuration" no?

No, we haven't agreed on that. I think I have been very clear already from when writing the specification that it will not work for us. We don't want to have to load a separate configuration for different modes. That's the MML way of doing it and it is bad.

If there is no virtual mode how are you then planning in your configuration to have modes for both real machine or twin? Or you are not planning to have those two modes in the same configuration but separate files and call it live in both cases?

[gubaidulinvadim]

For now I don't see any point in a virtual mode.
For the operation modes, that's another topic but I think we agreed to say for now "one mode = one configuration" no?

No, we haven't agreed on that. I think I have been very clear already from when writing the specification that it will not work for us. We don't want to have to load a separate configuration for different modes. That's the MML way of doing it and it is bad.

If there is no virtual mode how are you then planning in your configuration to have modes for both real machine or twin? Or you are not planning to have those two modes in the same configuration but separate files and call it live in both cases?

I repeat, that there's a `virtual' mode already present if you configure it.

[TeresiaOlsson]

For now I don't see any point in a virtual mode.
For the operation modes, that's another topic but I think we agreed to say for now "one mode = one configuration" no?

No, we haven't agreed on that. I think I have been very clear already from when writing the specification that it will not work for us. We don't want to have to load a separate configuration for different modes. That's the MML way of doing it and it is bad.
If there is no virtual mode how are you then planning in your configuration to have modes for both real machine or twin? Or you are not planning to have those two modes in the same configuration but separate files and call it live in both cases?

I repeat, that there's a `virtual' mode already present if you configure it.

I know but the point is to make it a standardized name so you can write sharable applications which for example uses live and virtual in the same script.

[gubaidulinvadim]

Yes, it appeared in tab completition and it is no different from live or design mode. Those are just names. Currently, the measurements are attached to the mode. You run the same measurement by calling sr.design.orbit.set() or sr.model.orbit.set(). So, everything is in place already to satisfy this requirement. There's no hardcoded sr.design calls inside, as far as I know. The only possible issue is to have orbit configured differently between live and virtual. But I haven't looked at it, it is quite possible this is also already possible.

Edit: and this kind of issue of, for example, handling wait in different modes is a problem for "measurement execution engine".

Edit2: Yes, LOCO will need have access to both. But I imagine that a good way to do it is having names of the modes in LOCO config. But we are far from having LOCO in pyAML right now. I don't think any work on integrating pyLOCO was started yet @kparasch .

[TeresiaOlsson]

Yes, it appeared in tab completition and it is no different from live or design mode. Those are just names. Currently, the measurements are attached to the mode. You run the same measurement by calling sr.design.orbit.set() or sr.model.orbit.set(). So, everything is in place already to satisfy this requirement. There's no hardcoded sr.design calls inside, as far as I know. The only possible issue is to have orbit configured differently between live and virtual. But I haven't looked at it, it is quite possible this is also already possible.

Then what is the reason for having:

            for c in controls:
                if c.name() == "live":
                    self.__live = c

and

                if s.name() == "design":
                    self.__design = s

in the accelerator?

If all modes are added as dynamic attributes which works with tab completion it seems to me like it can be removed to simplify the code and handle all control modes the same?

[gubaidulinvadim]

I wouldn't know. @gupichon @JeanLucPons is __live and __design used anywhere still as a special name? I checked very briefly and saw no difference between a custom name sr.model' and sr.design. ' Maybe tuning tool shortcuts, such as, sr.design.tune are only attached to special names?