The Virtual Accelerator Allocator Status

1. The Virtual Accelerator Allocator Status R. Gutleber Cesar Torcato de Matos

2. Overview • Concepts • Virtual accelerators • Architecture • Overview • VAA commands • Status • Work done • Planed work till next MACS week Cesar Torcato de Matos

3. CONCEPTS Cesar Torcato de Matos

4. Virtual Accelerators (VAcc) • Consists of a list of machines • addressed with a unique identifier (e.g. CS-02-001-ACC) • VAcc may be only in one mode at a time • All Machines (Working Sets) have to be in that same mode • Overlapping VAccs cannot be used at the same time. • Non-overlapping VAccs can be used at the same time • And may be in different modes Cesar Torcato de Matos

5. Virtual Accelerator Allocator (VAA) • Scheduler that allocatesVAccs for exclusiveusage • Schedulingbased on availability, request time and priority • Receives requests from clients (BDCS or ProShell) • Responsible for configuring all components of theVAcc • Forwards commands (StartCycle, NextCycle, ...) fromclients to theMTS • VAA will not automatically change the mode (clinical, QA, physics, service) of any resource • Avoid unintendend mode changes • An operator procedure will be required to move a device in a certain state and mode Cesar Torcato de Matos

6. ARCHITECTURE Cesar Torcato de Matos

7. General Architecture • VAA • Forwards requests to the MTS (NextCycle, StartCycle etc..) • Single entry point for allocationin the system (safety!) • Serializes requests to MTS and PVSS (avoidingraceconditions) Cesar Torcato de Matos

8. VAA Request State Machine Eachallocationrequestishandledby a single VAA requeststatemachine. • Pending – request is waiting for resources • Allocated – all resources are claimed • Active – all resources are configured and irradition may start • Failed – when one resource moved to failed • Deallocated– request is finished Cesar Torcato de Matos

9. Allocation The VAA performs the following actions when receiving allocation request: • Check that none of the resources is in failed state • Checkthat all resources are in the requestedmode (clinical, QA, physics, service) • Reject request if mode does not match • Check availability of all resources • Keep request pending if resources are in use by another request to avoid starvation. • Check devices in checklist • Allocate all resources • Configure MTS execution slot (runfile, list of cycle-dependent devices) • Configure all resources to listen for MTS events in selected execution slot • Send ActivateRun command to MTS • To trigger loading of cycle-dependent values (waveforms) – May take time! • Sends „Prepare“ command to all devices except beam transfer elements that connect to WSs outside of the VAcc (will unground and magnetize magnets etc..) Note: Beam Transfer Elements are still disabled! Cesar Torcato de Matos

10. Activation The VAA will perform the following actions on activation requests: • Check state (red,orange,green) of the Patrol Control System (PCS) • Sends „Activate“ command to all devices except beam transfer elements that connect to WSs outside of the Vacc. • Move out beam stoppers • Unground and magnetize all switchingdipoles Note: Subsequentlythe BDCS mayrequestcyclesforthisVAcc Cesar Torcato de Matos

11. Deactivation The VAA will perform the following actions on deactivation requests: • Send „Deactivate“ command to all components in the VAcc • Move in beam stoppers • Ground and degauss all switchingdipoles • Configure components to not listen to MTS events anymore Note: Subsequently the BDCS may not request cycles for thisVAcc anymore (Irradiation is paused) Cesar Torcato de Matos

12. Deallocation The VAA will perform the following actions on deallocation requests: • Free MTS execution slot • Send „Finalize“ command to all devices(degauss and ground magnets etc...) • Deallocate all components • Trigger rescheduling for pending requests Cesar Torcato de Matos

13. Status And Outlook Cesar Torcato de Matos

14. VAA Skeleton Implementation • Reacts to the basic commands over network (allocate, activate, get_status etc...) • PVSS test project with 5 VAccs , 13 WS , 2000 devices and 11 beam transfer elements Cesar Torcato de Matos

15. Interface to PVSS • Gets all data of available WS and VAccs from PVSS • Allocates and checks all conflicts down to the device level • VAA datapoint in PVSS defined • Reacts to commands following “generic device interface” • Displays status of all requests and VAccs in PVSS • Will be integrated with WS and VAcc PVSS scripts and state machine in the incoming weeks Cesar Torcato de Matos

16. Current Status • Requirements and design in Enterprise Architect • Requirements gathering and architecture design (a lot of details added) • Ways of automatically identifying beam stoppers, beam transfer elements in PVSS defined • Conflict checks with VAccs and WS refined • Interface with PVSS defined • Can allocate WSs and VAccs performing conflict checking (some new requirements added that are being incorporated) • Can receive commands and post information into PVSS (execution status, VAcc status, request table) Cesar Torcato de Matos

17. Planed Work till next MACS week • PVSS “distributed project” enable VAA (dpGets and dpSets) • Generic device interface into VAA (partially done: performs commands from PVSS) • Transition of requests from “Activated” to “Allocated” (pause irradiation) • Interface with VAccs and WSs using PVSS scripts (currently looping over devices) • STM communication (currently using DIM to simulate it) • Extra conflict checking (check-list datapoint-element) Cesar Torcato de Matos

18. Status • Ahead Schedule • None • In Time • Architecture Design • PVSS interface • Skeleton: Basic commands and basic conflict checking • Behind schedule • Updating requirements document • More advanced conflict checking • Activate and prepare command implementation (currently only log entries) Cesar Torcato de Matos