Meaning of virtual accelerator

[TeresiaOlsson]

Sorry, I'm confused about what "virtual accelerator" currently means. I read in the user interface specification but I still don't understand.

It says:

Virtual Accelerator
A virtual control system can be used instead of the one used for operation and controlling real hardware.
This different control system is assumed to be available and its unique name (tango host for TANGO
or prefix for EPICS) is specified in the pyAML main configuration file.
The virtual control mode also requires that the user of a specific control system implement
simulated Power Supply and diagnostic devices. The PS devices do not act on any hardware but
have the same interface/attributes as the real ones. The simulated diagnostic devices are filled by a
Simulator Control Mode Class instance running as fast as possible and updating based on the latest
variation of strengths, RF, apertures, etc...

This I understand. But then there is also a case without the user having to implement any simulated devices. Just the control system layer directly accessing the model and the model continuously updating based on how PVs change.

What is this mode currently called? Or it it doesn't exist? For me that was what "virtual accelerator" meant but recently I have learned that some labs also have models of their power supplies and "virtual accelerator" for them means to also include those models in the simulation.

Can someone perhaps explain?

[gubaidulinvadim]

Just add this another case to the user specification document. From my understanding this case is not really very different from the real control system. You just have a different EPICS PV prefix for the names or a different TANGO host. Unless, I'm mistaken, we have this case covered "for free"

[TeresiaOlsson]

Exactly. But you still need to implement the part of the virtual accelerator which automatically updates and speaks to the model inside which is quite a lot of work. Only just not the layer of simulated devices where you plug in models of individual devices.

For me it's like a basic virtual accelerator which is much easier to make generic and can automatically be initialized using components that anyway need to exist in pyAML. And in that way everyone can get a virtual accelerator, shadow etc even if they don't have resources to implement simulated devices.

I guess that can be implemented in different ways. Maybe there is one way where you can start with this case for those who don't have simulated devices and they over time can add simulated devices to their virtual accelerator.

[MJGaughran]

I don't think the 'Virtual Accelerator' should be considered a single product.

Instead, I would hope PyAML provides a toolbox to build a virtual accelerator customised to your particular task. There could be some kind of generic configuration that gets you started, but I suspect control system naming conventions will be difficult to make generic across all facilities.

As an example, here they go into the performance (and other) tweaks required for a couple different use cases in the 'Current Status' section.

The common attributes of a Virtual Accelerator could be something like:

• An underlying lattice simulation
• A control system interface (e.g. EPICS, Tango, etc.)
• Inclusion of all 'standard' lattice components
• A standard set of 'basic' diagnostic measurements
• No interaction (in either direction) with the live machine

Any further levels of detail should be optional, but still possible to implement. As long as it has the attributes above, it is considered a Virtual Accelerator.

[PierreSchnizer]

I think that typically virtual accelerators with different levels of details should be possible and "live" next to each other.

Device artifacts and failure injection come to mind.

[JeanLucPons]

The virtual accelerator is described in the document in the drawing made by @simoneliuzzo.
To me, the description given by Vadim is correct.
The SimulatedPowerSuppy is a set of Tango server or Epics IOC that use AT to fill diagnostics SimulatedDiagnostics servers.
I agree with Teresia, this is a lot of work to have it and IMHO it's worth to do it in order to help software developper to write application.
However, if you don't write needed servers, it will just prevent to use virtual.

[TeresiaOlsson]

Okay. I think I'm starting to understand what you mean by virtual accelerator and how it compares to the HZB twin.

Sorry, one more question. The power supply models you have in the ESRF-EBS twin, what level are they at? I imagine they can be on a range from a full scale simulation of the power supply (basically a twin of the power supply) or something very basic which just provides the same response time as the real power supply?

[JeanLucPons]

The SimulatedPowerSupply just mimics a slow PID (it is tunable but we didn't tune them all very accurately). It was especially usefull to test the set_and_wait() and at the end it was very usefull for mini-cycling tuning.
To make the distinction clear between live and virtual, virtual has an additionnal diagnostic device that returns optics functions. This is what simone illustraded in his scheme.

[TeresiaOlsson]

Okay, thank you :) Now I have a much better idea of what implementing the simulated power supplies would mean for each individual lab.

[Sulimankhail]

We’ve implemented a virtual accelerator setup here at HZB that might be relevant to this discussion.

In our case, the virtual accelerator is built from any lattice plus configuration data. Once that’s provided, a virtual representation of the machine is automatically created. Most of the relevant PVs that exists in the real machine are recreated in the virtual environment with an additional prefix (e.g., VA:), so higher-level applications like ORM or Tune Correction that we run on real machine, can also run unmodified on the virtual accelerator— the only difference is the PV prefix.

This setup doesn’t simulate individual device dynamics like power supplies, but it does provide a functional model that integrates seamlessly with the control system layer. It’s been effective for testing and development, especially when resources for building full simulated devices are limited.

From this perspective, it might be helpful to distinguish between different levels of virtual accelerator.

[TeresiaOlsson]

I think this would be a really nice option to provide a virtual accelerator also to small labs who don't have resources to implement simulated power supply and diagnostic devices themselves. Then they can also get a shadow which might otherwise be out of reach for them because of lack of resources. For us it has already been useful for software development. We haven't really needed the exact response of the machine. Just a virtual accelerator which has the PVs as in the machine and returns the orbit and twiss.

@Sulimankhail and @PierreSchnizer are already working on making it generic so it can be used for both BESSY II and MLS (EPICS) and MAX IV (TANGO) since we since last week have a memorandum of understanding between HZB and MAX IV to collaborate on many things, including topics related to software.

[JeanLucPons]

There is a harware link already forseen for this. You can bypass the UnitConv and access directly a control system server that give access to magnet strength. So virtual can, in fact, either use SimulatedPowerSupply or SimulatedMagnet or even a combination of both.

[gubaidulinvadim]

This development is interesting for pyAML (my opinion). Like I was saying above, in the case of such virtual accelerator/twin/shadow/whatever, pyAML should be able to access it `for free' since it only differs via a prefix in the name of the EPICS PV.

[JeanLucPons]

@Sulimankhail Do you think your virtual accelerator can be used for PyAML CI/CD unit test ? I mean deploying one lattice plus associated EPICS PV and run it in a GitHub runner ?

[TeresiaOlsson]

@Sulimankhail Do you think your virtual accelerator can be used for PyAML CI/CD unit test ? I mean deploying one lattice plus associated EPICS PV and run it in a GitHub runner ?

Answered in #13