1 / 18

The Virtual Accelerator Allocator Status

The Virtual Accelerator Allocator Status . R. Gutleber. Overview. Concepts Virtual accelerators Architecture Overview VAA commands Status Work done Planed work till next MACS week. CONCEPTS. Virtual Accelerators (VAcc). Consists of a list of machines

sandro
Download Presentation

The Virtual Accelerator Allocator Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related