1 / 12

A Virtual Implementation of VELA (CLARA)

A Virtual Implementation of VELA (CLARA). Duncan Scott, Tim Price, Rory Clarke. Design Goals / Specification. A virtual implementation of all the parts of VELA (CLARA) required for Physics simulations Self-contained ‘out-of-the-box’ package, that ‘ just works ’ Individual Local Copies

minnies
Download Presentation

A Virtual Implementation of VELA (CLARA)

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. A Virtual Implementation of VELA (CLARA) Duncan Scott, Tim Price, Rory Clarke

  2. Design Goals / Specification • A virtual implementation of all the parts of VELA (CLARA) required for Physics simulations • Self-contained ‘out-of-the-box’ package, that ‘just works’ • Individual Local Copies • Seamless integration with existing tools • Hardware Controllers, VELA EPICS PVs

  3. Example Uses • Prototyping Control Room Applications • High Level Software Development from your office / living room etc. on machine you can’t break and is always available • Online machine set-up • Moving from one machine state to another • Virtual Experiments • Finding user required set-ups • ANY OTHERS?

  4. Current Status / Open Questions • VELA Hardware Controller • Mainly exist, Python / c++ modules • Is it a priority to extend the source to other languages? hopefully not… ;-) • Data saving? • Online Model (Bruno’s ASTRA simulation) • Finding the correct ASTRA parameters • Integrate and continue Model Validation project • How do we ‘chunk’ it? • Speed: gun simulations are slow… • Implement Pre-computed set-ups (especially gun) • Future integration with other codes / Magical Project Data-bases? • Incorporate latest ‘real-word’ data, lattice decs etc.

  5. Current Status / Open Questions • Virtual Environment • Virtual Linux containing a version of EPICS with all relevant process variables • What do we need? Magnets, RF phase / amp, BPMs screens … ? • All accessible though same Hardware Controllers as real machine • ASTRA model sits in virtual environment • A ‘Manager’ interface handles the EPICS / ASTRA interface,

  6. EPICS provides a common control interface and interlocks between the hardware and the user. Its communication layer is via Process Variables (PVs). The user can set and read to these PVs of which there may be thousands. VELA’s magnets and interlocks have been taken as a model and converted into a simulation. This EPICS simulation is running on a virtual machine. We have to be careful to follow a naming convention with the simulation PVs that follows a different syntax than the real machine’s PVs to avoid clashes. EPICS VM example:BSOL @ 5A Noise and ramping current have been added to the simulation of the virtual magnets. Noise is adjustable. Here it is about 5% Amps Time

  7. Structure for ‘Real’ VELA epics VELA IOCs that exit on real machine Machine Hardware components Hardware Controllers Hardware Controllers User GUI 1 User GUI 2

  8. Structure for Virtual VELA epics manager model • Python script • ASTRA IOCs (mimic real VELA) Virtual Linux Hardware Controllers User Computer (desktop PC) User GUI

  9. Manager Conversions (EPICS) RF Amp. to ASTRA Gun Gradient: beam_momentum [MeV/c] = 0.0644 * gun_gradient [MV/m] + 0.505 (on crest) (Some work Frank did, see wiki ‘Gun’ page) Gradient = Amp÷29.016 For example: 1800 ÷ 29.016 ~ 62 MV / m gives 4.5 MeV / c This is rough as record beam setup in the past has not been sufficient to get a strong relationship. Current to K Value: I = Current of magnet [A] (Set to and read from epics) • p = momentum [MeV][c]-1 (calculated before simulating path through quads) L = Magnetic Length [mm] a = Intercept [T] predefined values from excel spreadsheet (value contained in python script) m = Gradient [T][A]-1 (http://projects.astec.ac.uk/EBTFManual/index.php/Category:Magnets)

  10. Current VM Functionality • Set QUAD currents • Monitor QUAD currents • Run ASTRA from ‘outside’ Virtual Machine • Convert ASTRA distributions into ‘x’ and ‘y’ signal for BPMs • Example GUIs monitoring EPICS PVs

  11. Future: Plan for VM • More EPICS parameters in VM • Magnet polarity switches, cameras, BPMS, etc. • Screens: • ability to output ASTRA distribution as EPICs PV • moments, or ‘fake’ images using the moments • Use predefined distributions instead of run simulation through Gun each time. • ASTA simulation database • Dipoles? • Include more sections of VELA ?

  12. Future: Plan for your applications • Area Leaders Plan their own Applications on paper. E.g. • GUI layout • Procedures (set-up, what to scan, what DAQ etc) • Analysis • Data saving • Discuss application with TP / DJS etc (maybe in this meeting) • Decide who will be responsible for which parts • Prototyping and development • Requires toolset installed: Python, VM, Hardware Controllers, • Go through some worked examples of GUI building etc.

More Related