1. The Virtual Accelerator Allocator Status PR-101208-a-CTM, December 8 th, 2010 Cesar Torcato de Matos 1 R. Gutleber

2. Overview Concepts Virtual accelerators Architecture Overview VAA commands Status Work done Planed work till next MACS week 2 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

3. 3 CONCEPTS Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

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 4 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

5. Virtual Accelerator Allocator (VAA) Scheduler that allocates VAccs for exclusive usage Scheduling based on availability, request time and priority Receives requests from clients (BDCS or ProShell) Responsible for configuring all components of the VAcc Forwards commands (StartCycle, NextCycle,...) from clients to the MTS 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 5 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

6. 6 ARCHITECTURE Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

7. General Architecture 7 VAA Forwards requests to the MTS (NextCycle, StartCycle etc..) Single entry point for allocation in the system (safety!) Serializes requests to MTS and PVSS (avoiding race conditions) Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

8. VAA Request State Machine Each allocation request is handled by a single VAA request state machine. 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 8 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

9. Allocation The VAA performs the following actions when receiving allocation request: 1.Check that none of the resources is in failed state 2.Check that all resources are in the requested mode (clinical, QA, physics, service) Reject request if mode does not match 3.Check availability of all resources Keep request pending if resources are in use by another request to avoid starvation. 4.Check devices in checklist 5.Allocate all resources 6.Configure MTS execution slot (runfile, list of cycle-dependent devices) 7.Configure all resources to listen for MTS events in selected execution slot 8.Send ActivateRun command to MTS To trigger loading of cycle-dependent values (waveforms) – May take time! 9.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! 9 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

10. Activation The VAA will perform the following actions on activation requests: 1.Check state (red,orange,green) of the Patrol Control System (PCS) 2.Sends „Activate“ command to all devices except beam transfer elements that connect to WSs outside of the Vacc. a.Move out beam stoppers b.Unground and magnetize all switching dipoles Note: Subsequently the BDCS may request cycles for this VAcc 10 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

11. Deactivation The VAA will perform the following actions on deactivation requests: 1.Send „Deactivate“ command to all components in the VAcc a.Move in beam stoppers b.Ground and degauss all switching dipoles 2.Configure components to not listen to MTS events anymore Note: Subsequently the BDCS may not request cycles for this VAcc anymore (Irradiation is paused) 11 Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

12. Deallocation Cesar Torcato de Matos 12 The VAA will perform the following actions on deallocation requests: 1.Free MTS execution slot 2.Send „Finalize“ command to all devices ( degauss and ground magnets etc...) 3.Deallocate all components 4.Trigger rescheduling for pending requests PR-101208-a-CTM, December 8 th, 2010

13. 13 Status And Outlook Cesar Torcato de Matos PR-101208-a-CTM, December 8 th, 2010

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 PR-101208-a-CTM, December 8th, 2010 Cesar Torcato de Matos 14

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 PR-101208-a-CTM, December 8th, 2010 Cesar Torcato de Matos 15

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 16 PR-101208-a-CTM, December 8 th, 2010

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 17 PR-101208-a-CTM, December 8 th, 2010

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 18 PR-101208-a-CTM, December 8 th, 2010