WIR SCHAFFEN WISSEN – HEUTE FÜR MORGEN Overview high-level applications and code management Didier Voulot :: Paul Scherrer Institut … with a lot of input from Controls SwissFEL Commissioning Workshop, 22 March2016

SwissFEL Control Infrastructure Page 2 "FEL-DV85-004_SwissFELControls ITInfrastructure.pdf" Alfresco AFS -> commissioning Read/write access Acl access lists More flexible for fast changes High-Level Applications NFS -> operation Restricted access (ssh + membership to sf group) Higher availability IOC/EPICS/qt Tools provided by controls Eventually all operation software should be there

/afs/psi.ch/intranet/SF | /Applications -> scripts/programs for commissioning | /application1 /application2 | / > in each folder several versions may coexist / > version number only = official version /1.0.1 _didierscooltest-> version + comment = test version latest -> link pointing to the current version /config /data -> application output (link to data volume) /log /Beamdynamics /Controls /Diagnostics /Laser /Magnets /Operation /Photonics /RF /TimingSynch /Undulator /Vacuum File structure AFS Page 3 Standard afs access One group per volume Volume match technical groups Application is accessible by all groups

/sf | /controls | /bin /config -> archiver, strip tool... /iocBoot | /ioc | / -> contains templates and substitution files /op | /bin -> wrapper scripts (path information should be kept there) / -> application folder (versions + link to current version) /config | /qt -> operation panels /launcher-> launcher configuration / -> application config files /data-> for application data (separate volume, R/W access form machine network) /ioc | / -> used at start-up of IOCs File structure NFS Page 4 Single unix group for SwissFEL: unx-sf9104 Some folder restricted (?)

Use source op to set-up operation environment (default for sfop ) /sf/op/bin Minimise use of environment variable Keep $PATH short and free of AFS locations Wrapper scripts & config files Page 5

Simple panels  caQtDM  Style guide and style-sheet (Alfresco )  All device interface that do not require complex logic Generic tools  Tools provided by controls that are not specific to SwissFEL  Save&Restore, Archiver, Generic Scan-tool… High-level applications  All applications that require physics and/or complex logic  Matching-tool, Emittance, Longitudinal set-up, Bunch compression tool… Inventory of control applications Page 6

RF, magnets, beam diagnostics, timing, T&S, laser… For each device define user interface:  User channels (attribute names)  Panel layout Status  Magnets -> new caQtDM ‘pep’ panels, ready for test  Diagnostics -> panel defined, virtual panel exist  Timing -> user panel in operation  RF, laser -> panels defined  … Panels Page 7

SINEG01-MQUA140 : I-SET. EGU device name attribute | | | | | record name field | | | process variable (PV) Reminder EPICS terminology Page 8 From Holy-listGiven by EPICS SwissFEL Naming Convention, FEL-ZE SwissFEL motors and actuators naming convention, FEL-DV

Responsibility: Controls, HLA group Launcher Save and restore  New configurable save and restore application  Include some SwissFEL specific features (scaling, partial reload)  Will eventually be used on all machines (will be tested on SLS) Pshell  Java based scan tool  Very versatile: user scripts (python), API, all possible scans Snapshot tool  Lightweight Save&restore Archiver  Web user interface / programmatic API  Epics already running / BSDAQ still under test … Generic tools Page 9

SwissFEL launcher (pylauncher) Page 10 New python application (pylauncher) Same features as old Tcl/Tk launcher Configuration files in /sf/op/config/launcher Nested json text files, each sub menu in a separate file Start: type launcher in a terminal or use icon on the consoles Menu structure : Global/System/Expert Single launcher for operation and experts Separate launcher for simulation tools from the virtual accelerator (under discussion)

A good example of how to organise the work flow Responsibilities  Controls provides and maintains the tool, implement new features etc  Operation maintains the config files (master version)  Everybody contributes to the config files Use git.psi.ch to maintain a master versions and upload changes (see 1.Make a copy (fork) 2.Pull to work folder, make changes and test, push to repo 3.Make a merge request 4.Merge to master and upload to /sf/op/config/launcher Similar approach can be used for other ‘collaborative’ items e.g. alarm handler configs pylauncher Page 11

Inventory of application requests  5 Categories: Machine calibration, Linac set-up, FEL set-up, Measurements, Feedbacks  33 entries -> contact person, description, priority Responsibilities  Beam dynamics to provide specifications  Beam dynamics provides commissioning applications  Controls/operation ensure long term maintenance Language = python In practice controls provides several key modules on which to build applications:  Scan module: Pshell -> existing  Camera tool: under development, first version exist Online model  Another key component needed by many high-level applications  Developed by Beam dynamics, needs some reorganization High Level Applications Page 12

Page 13 Wir schaffen Wissen – heute für morgen A lot of progress A clear strategy Responsibilities defined Infrastructure in place Some items will not be ready at the start of the commissioning … but all basic/necessary tools will be there