LSA Basic concepts - CERN Indico

Delphine Jacquet

Many thanks to Andrea, David, Denis, Greg, Jean-Francois, Matteo, Michi, Roman, and Stephane for the

feedback and help.

OP shutdown lecture 2020

LSA Basic concepts

1

Outlook• How it all started

• LSA basic concepts• Accelerator static configuration

• Elements

• HW Devices : device types, properties and fields

• HW parameters

• Accelerator zones/ Particle transfer

• Beam and equipment behaviour modelling• Beam devices

• Logical devices

• Parameters and parameter types

• Parameter relations and makerules

2

Outlook• Exploitation of the accelerator

• Contexts : Cycle and Beam processes

• Settings generation and optics

• Corrections

• Parameters of type KNOB

• Beam out and link rules in the SPS (slides from Stephane)

• LSA main tools (brief overview)

• LSA software

• Settings management specificity in LHC (given by Matteo)

3

Slides from LSA team in BE-CO technical meeting may 2018

LSA is very complex to implement• Many accelerators, everyone particular• Many parameters to control• Many different beam operations• All with the same core system

4

How it all started….

1999: SPS2001 project team OP + CO• Mandate : “reengineer the SPS application software to

allow efficient operation and to cover specific needs of the SPS as LHC injector”

• Endless discussions and arguments : agree on the basic concepts for a new control system of the SPS

• Based on past experience and new requirement for SPS as LHC injector.

2001: LSA (LHC Software Architecture) replace SPS2001 (still OP + CO)• Adapt /add concepts to fit LHC operation• Start software implementation for SPS, LHC and LEIR

5

How it all started….

2007: INCA project team OP + CO• Renovation of the injectors control system• LSA implemented for injectors with an additional acquisition

package to fit injectors needs

Today: LSA used for all accelerators or facilities(despite its name….)

6



• Elements


• HW parameters



• Logical devices



7

Elements installed in the tunnel

Layout Database MadX elements sequence LSA database

elements

Elements: equipment installed in the accelerator

8

Hardware devices: control of the tunnel equipment

Defined in controls configuration databaseClassProperty-fieldsdevices

Operationaldevices/properties/fields imported into LSA

Device typeProperty/fieldsDevices

RF control devices Instrumentation control devices

HW parameters

9

Hardware parameters: control of the HW devices settings

Device Type

Property 2

Property 3

Property 4

Property 1

Field 1

Field 2

Field 3

Device 3

Device 4

Device 5

Device 2

Device 1

10

Hardware parameters: control of the HW devices settings

Device Type

Property 2

Property 3

Property 4

Property 1

Field 1

Field 2

Field 3

Device 3

Device 4

Device 5

Device 2

Device 1

Parameter : device5/Property3#Field1

11

Accelerator zones and particle transfers

• The accelerators are divided in zones that represents a physical part of the accelerator

• Each elements and HW devices are defined in one and only one accelerator zone

TT21

TT22TT23

TT24TT25

TT40 TT41

TI8SPS

TT60

TI2

TT66

TT10TT2

12

TT21

TT22TT23

TT24TT25

TT40 TT41

TI8SPS

TT60

TI2

TT66

TT10TT2

SPS Injection

• Particle transfer: a possible path of the beam through different accelerator zones to serve a purpose (inject the beam, send beam1 to Lhcetc..)

• A given accelerator zone can belong to many particle transfer


• Accelerators divided in zones representing a physical part of the accelerator


13



TT21

TT22TT23

TT24TT25

TT40 TT41

TI8SPS

TT60

TI2

TT66

TT10TT2

AwakeTransfer









14

TT21

TT22TT23

TT24TT25

TT40 TT41

TI8SPS

TT60

TI2

TT66

TT10TT2

LhcB2Transfer






15

TT21

TT22TT23

TT24TT25

TT40 TT41

TI8SPS

TT60

TI2

TT66

TT10TT2

SPSRing • Particle transfer: a possible path of the beam through different accelerator zones to serve a purpose (inject the beam, send beam1 to Lhcetc..)





16



• Elements


• HW parameters



• Logical devices



17

• Accelerator operation is not just about HW equipment control

• It is more about controlling the beam characteristics and stability to serve our users

• For this we need to understand and model the effects of the equipment on the beam

• To represent this model, we use abstract high level devices and parameters

• Let’s explore this into detail through a simple example

Beam and equipment modelling

18

Typical example: control of the tune

Tune H and V are measurable characteristics of beam. In LSA Tunes are modelled as parameters:

H

PSBEAM

PSBEAM/Tune#HPSBEAM/Tune#V

Virtual device that represent the beam

Parameter type: TuneThe parameter type characterize a parameter from the model point of view.It allows to group parameters representing a similar concept and with a similar behaviour

Tune H and Tune V parameters

TUNE Vproperty/field that represent the tune H and V

19


To control the tune value, we need to control the strength in the quadrupoles

Focalizing strength K

Defocalizingstrength K

Quadrupole F Quadrupole D

Focalizing strength K

Defocalizingstrength K

Quadrupole F Quadrupole D

Logical.QFLogical.QD

K

Logical.QF/KLogical.QD/K

Beam

Devices that represent the quadrupoles magnets

property that represent the strength in a quadrupole

K parameters for each device

Parameter type K (shared by all parameter representing a magnet strength)

20


To control the strength in the quadrupoles, we need to control the current I in the quadrupoles

Quadrupole D

Logical.QFLogical.QD

I

Logical.QF/ILogical.QD/I

BeamQuadrupole F Quadrupole F

Current I Current ICurrent I

Quadrupole D

Current I

To control the current in the quadrupoles, we need to control the hardware settings of the power converters (see part 1)

We get the devices, properties, fields from CCDBHW parameters

QF/REF_TABLE#valueQD/REF_TABLE#value

property that represent the current in a quadrupole magnets I parameters

21

We have to model in LSA:

The relation between parameters

PSBEAM/Tune#H PSBEAM/Tune#V

Logical.QD/KLogical.QF/K

Parameter relation

source

dependent

Parameter relation

source

dependent

Parameter hierarchy and makerules

22




Logical.QD/ILogical.QF/I

PSBEAM/MOMENTUM

QF/REF_TABLE#value QD/REF_TABLE#value



23



source

dependent

MAKERULE

source

dependent

Each parameter relations is associated with a Makerule• Usually defined from a source parameter_type to a dependent parameter type• Can be also defined for a specific parameter relation• java class in LSA• From the settings of the sources parameters, compute the settings of all dependent

parameters




The settings calculation : makerules

24



Bi-directional parameter relation is allowed• Not always easy or possible • Makerules are defined independently• To be used with prudence


source

dependent source

dependent

source

dependentsource

dependent

25


Each time a parameter settings is changed (trim)• All the dependent parameter settings are re-computed from

their new source value• If the dependent has itself dependent parameters, they are

recomputed as well

26




recomputed as well

27




recomputed as well

28




recomputed as well

29




recomputed as well

30




recomputed as well

31




recomputed as well

32




recomputed as well

33




recomputed as well

34

Recap

“REAL WORLD”

elements

HW devices

Logical/virtual devices

Represented by

Control of

beam Beam devicesRepresented by

ParametersProperty/fields

Parametertypes

With attributes defined in

Value controlled by

Property/fields

HW parameters

PART OF THE ACCELERATOR “MODEL”

Characterized by

Defined in hierarchies andused to compute settings for

35

Act on




• Corrections




• LSA software


36

Exploitation of the accelerator

• Inject, accelerate and distribute the beam to the users

• With a control of the beam characteristics along the process

• Maximising beam quality and reducing the losses

CONTEXTS: Cycles Beam processes

37

ContextsBeam process : • Represent an individual process applied to

the beam.• Linked to a particle transfer : where this

process applies• Holds all the settings of all parameters

defined for the particle transfer

Beam process SPS injection

SPS Injection

38





SPSRING Beam processes in SPSRING

Injection PlateauBeam acceleration

Extraction Plateau

39





Beam process T2Transer to send beam to T2 target

T2 transfer

40





BP T4Transfer and T6Transfer to send beam to T4 target and T6 target

T6 transfer

T4 transfer

41

Contexts

Cycle• Set of beam processes necessary to achieve

a full beam operation• Scheduled in time

Injection PlateauBeam acceleration

Extraction Plateau Beam out

42

Context and parameter settings

The value type of a parameter is defined by the value type of its field• Function of time → Function parameter

Value change along the beam process• Scalar (Double, array, float, string…) → Discrete parameter

The value is the same along the beam process

Property FieldDevice

Parameter : device5/Porperty3#Field1

Parameter type

Some parameters have the same value whatever the accelerator is doing• i.e : interlock thresholds• They are called NON_MULTIPLEXED or NON_PPM parameters

43

Multiplexed or PPM

Context types

Cycle typeMeta-information:• Length• Beam type etc….

Scheduled BeamProcess types

Optics

Particle transfer

Meta-information:Anything necessary to fully describe a beam process

Length

The BP types can overlap in time if they are not defined for the same particle transfer (no shared parameters)

Incorporation rules : defines how a punctual trim is integrated in the

beam-process function (see Matteo’s lecture on hypercycles)

44

Beam Process typeBeam

Process typeBeam

Process typeBeam Process typeBeam

Process type

Context types vs Context

Cycle type

Beam Process type

Beam Process type

Beam Process type

Beam Process type

Beam Process type

Cycle1

Beam Process type

Beam Process type

Beam Process type

Beam Process type

Beam Process 1.1

Cycle2

Beam Process type

Beam Process type

Beam Process type

Beam Process type

Beam Process 2.1

Cycle1

Beam Process type

Beam Process type

Beam Process type

Beam Process type

Beam Process 3.1

CONTEXT TYPES:• Provide full description of a context• Shared by several context• BP types shared by several cycle types • Doesn’t hold any settings• “OFF line” definition

CONTEXTS:• All unique (BP are not shared between cycle)• Always have an associated context type (shared with other BP or cycles)• The beam processes contain all settings changed daily in operationStandalone context: a context is standalone if it is independent and self contained• Here cycles are standalone, can be played independently• The Beam processes are no standalone, they exist only inside a cycle. 45

Different categories of context

Discrete Beam processes• No length, no scheduled time in cycle (set to 0)• Contains scalar settings of the discrete parameters of the particle transfer

Function Beam processes• Has a length, scheduled at a defined time in the cycle• Contains function settings of the function parameters of the particle transfer• When necessary scalar settings can also be defined in the function BP• Function beam process are defined as beam-in or beam-out (explained later)

Non-Multiplexed (or non-ppm) context• Contains all the settings of non-multiplexed parameters

46

Discrete BP types

Function BP types

47

Creating new context

From scratch1- Create necessary Beam Process types

Generation application

2- Create necessary Cycle types with scheduled BP types

3- Create new contexts from the cycle type

• For each scheduled beam process type, a beam process is created, associated to the BP type

• New cycle context containing the BP as scheduled in the cycle type

• At this stage the new context doesn’t contain any settings (see next chapter on settings generation)

1 and 2 can be skipped if the types already exist 48

Creating new contexts

From an existing context : clone• It will create a copy of the

cycle and all the beam processes it contains

• The settings will be copied as well

• If “clone type” is selected:• The types (cycle type and each

bp types) associated with the source cycle will be cloned

• The new contexts will have their own, unshared types

• Else the new contexts will share the context types with the source contexts

49

Resident contexts and users (not valid for LHC)

A cycle can be played only if• Its settings are loaded into the hardware• It is associated (mapped) to a timing user

When it is the case, the cycle is resident• Ready to be played when its associated user is scheduled in the timing sequence• Any change of the device settings are immediately sent to the hardware

We can make resident as many cycle as they are users available per accelerator• For example in PS, 32 users will be available• Each hardware can contains the settings for 32 cycles

Non-multiplexed cycle : only one can be resident at a time as the non-multiplexed devices contain only one setting. Not associated with user as independent of timing.

50




• Maximising beam quality and reducing the losses

Settings generation and OPTICS

51

Settings generation

As we have seen, when creating a context from scratch, it doesn’t contain any settings

Our new cycles are usable only if all the parameters have settings

We have seen that our parameters are organized in a hierarchies

We have already seen how to compute dependent parameters settings from its source parameter settings: MAKERULES

MAKERULES

MAKERULESMAKERULES

MAKERULES

MAKERULES

MAKERULES

MAKERULES MAKERULES

One thing left to be defined:How to compute parameters settings when they don’t have any parent?

52

Settings generation : meta-info in the types

To generate top level parameter settings, we use information defined in the contexts types

Beam process type for beam acceleration

Length of the functions to generate (used for all function parameters)

Particle type used for example for RF settings

Describe momentum time evolution to generate Brho and momentum parameters

Optics to be used during the acceleration: Generation of Optics parameters like chromaticity or tune parametersContain the value of K parameters for bending and quads

53

Settings generation

Timing info to generate timing settings

Cycle type for north area operation

Settings generation : meta-info in the types

54

Schedules BP to generate the full cycle settings

Settings generation : value generator

When LSA receives a request to generate any parameter

First the system will look if the parameter is associated with any ValueGenerator• As for MakeRule, it is a java class in LSA server• The code defines how to compute the settings with the contexts types as input• They can be generic like constantValueGenerator, ZeroValueGenerator• Or specific to the given parameter

If no value generator is found• The parameter has source : its value is computed with the makerule from the source settings• The parameter doesn’t have source : LSA throw an exception as the settings can’t be generated

55

Settings generation : tools

From Generation application From LSA-app suite / settings management

56

Optics in LSA

Used mainly to• Compute the magnet settings (from defined tune, chroma and magnet strength)• Compute the collimator settings• Compute corrections (YASP)• Interpret measurement (i.e emittance measurement)

Optics definition is under the BE/ABP group responsibility• Madx files• Stored now in GitLab

OP imports the optics needed for Operation into LSA• Creation of optics model in Gitlab with files from APB directories• Tool to generate twiss files and import into LSA

57

• Attached to a particle transfer • Contain twiss parameters (Beta, gamma, alpha, dispersion)• The strength by logical devices of the magnets

Optics in LSA : upload optics tool

Select the model that contains the optics to upload

Available optics in the model

58

Optics in LSA : upload optics tool

Select the model that contains the optics to upload

Generate twiss with JMAD

Existing LSA optics

Generated optic is saved into LSA database

59

Optics in LSA

In BP types, several optics can be defined at different time• Linear interpolation of twisses parameters and K

between 2 defined optics

• Most meaningful example : LHC ramp and squeeze beam process

Ramp and squeeze Beta X function in IR5Ramp and squeeze K for matching quads 60




• Maximising beam quality and reducing the losses CORRECTIONS

61

Applying correction : trim parameters

Even if the cycle (or BP) settings are generated from a model, the machines are not perfect and corrections need to be applied• To bring beam characteristics to target values• To optimize losses • To optimize trajectories • Etc…

As we have seen already, the parameter hierarchies allows to correct parameters representing directly a physic or measurable quantity

• Tune• K• Global RF voltage etc..

The corresponding changes at hardware level are automatically computed

62




PSBEAM/MOMENTUM


Applying correction : trim parameters

Measurable quantity that we correct

Computed hardware settings that are sent to equipment

63

Target and correction concepts

In order to distinguish between • the wanted value of a parameters • and the needed correction to reach this valueThe concepts of target and correction were implemented in LSA

SPSBEAM/Tune#H

TARGETCORRECTION

Settings generationTrim

We want a tune H with constant value of 26.62 along the cycle

To maintain the measured tune at 26.62, the following corrections needed to be applied along the cycleValue of a parameter setting = Target + correction

64




PSBEAM/MOMENTUM


Target and correction concepts TARGET CORRECTION

VALUE

TARGET CORRECTION

TARGET CORRECTION TARGET CORRECTION


TARGET CORRECTION


VALUE

VALUE

VALUEVALUE

VALUE VALUE

VALUE VALUE

Sent to hardware

Generation Trim

Generation Trim Generation Trim

Trim Trim

Trim Trim• The settings computed with makerules from source parameter become the new target of the dependent.

• Parameters can be trimmed directly at any level: the delta from this direct trim is stored as correction

• The value(target+ correction) is used to compute the new settings of the dependent

• The value of HW parameters are sent to HW 65

Target and correction concepts

These concepts are very useful• The reference values are kept in the settings • We can distinguish between the wanted value of a parameter and the

real settings that take into account the imperfections or misbehaviour of equipment and devices.

But not compatible with bi-directional hierarchies• We can see that going backward into the hierarchy we lose the notion

of target• This concept is then disabled in the injector (PS, PSB, AD…), where

trim, generation and makerules are all applied to target.

66

Changing several parameters in 1 trimMost common case: apply a trajectory correction with YASP• Several independent parameters changed at the same time• For LSA system, this is seen as a single trim

Correction calculated per YASP for 4 correctors

k1 k2 k3 k4

I1 I2 I3 I4

FGC-1 FGC-2 FGC-3 FGC-4

1 trim

TRANSACTIONAL BEHAVIOURTrim should be applied to all parameters or roll backedWe should avoid that only a part of the devices are playing the new settings (can be dangerous)

X

67

Trim rejected when the makerule is applied : Lsadoes the roll back, noting is sent to hw

Changing several parameters in 1 trimMost common case: apply a trajectory correction with YASP• Several independent parameters changed at the same time• For LSA system, this is seen as a single trim

Correction calculated per YASP for 4 correctors

k1 k2 k3 k4

I1 I2 I3 I4

FGC-1 FGC-2 FGC-3 FGC-4

1 trim

XDrive OK Drive OK Drive OKRejected by HW

Trim can be rejected by one of the HW device : • Settings already sent to other HW• HW wait for a commit message before playing the new

value.• In case one device send an error : LSA send a rollback

message to all the involved HW • The new value is not played by any HW and the trim is

reverted • This requires that the HW devices implement the

transactional behaviour: true for FGC, still work in progress for FESA devices

68




• Corrections




• LSA software


69

A particular type of parameter : KNOB

Not the GUI element from the working set that allows the control of a device

Parameter of type KNOB with a specific behaviour

70


• Knob are mostly high level parameters, representing a physic quantity (orbit bump, chromaticity, tune etc…)

• In which case they are parameters of beam devices, with parameter type KNOB

71

Device : NORTH_EXTRBEAM

5,7.10-74,7.10-7 -1,1.10-51,0.10-5

Linked to their dependent parameters by linear factors

Indicates a bump in H plane postion 216. Factors valid for 1mm bump


• Knob factors are optic dependent• Stored in a table in LSA DB for each optic

• Knob makerule is applied on relative settings change and not absolute knob value• From the delta value that is applied to the knob, a delta value is computed

for each components• This delta is a simple multiplication of the knob delta by the factor• To be noted that the factors can change along the BP if several optics are

defined (linear interpolation between 2 optics)

72




• Corrections




• LSA software


73

BEAM-IN and BEAM-OUT concepts

Beam in Beam out

Beam in Beam outBeam out

For each cycle, we can distinguish 2 parts• Beam in : beam is present in the particle transfer• Beam out : no beam in the particle transferIn every particle transfer, we have one or several beam-in beam-processes and one beam-out beam-process

During these phases the settings management doesn’t follow the same rules

Beam in• The hardware settings are driven by beam parameters• At the top of the hierarchy we use a high-level physic

parameters like (Momentum, tune, Chromaticity, Bucket area etc..) to trim the hardware settings through the make rules

Beam out• The hardware settings are driven only by hardware

constraints and limitations• The aim is to have the HW ready for the next cycle• The high level parameters are not defined, they have no

meaning when there is no beam74

Example of beam in, beam out for SPS Injection

+ =

Momentum defined in BEAM IN

K defined in BEAM IN

Iref defined all along cycle because it

will be sent to the hardware

Iref defined by a link rule for the BEAMOUT part

Iref defined by high-level parameters through make rules for the BEAMIN part

Hierarchy between parameters

from parents to dependents

• Bending magnet in TT10 (MAL1001M, injection line)

75

76

Why is this concept needed in SPS?

High-level parameters only defined when they make sense (BEAMIN)

Free from dependencies and makerules, one can freely define our magnet behaviour during beam out :

• demagnetization• ramp-up to a plateau• Compensate for power converter unwanted overshoots or delays• ramp down taking into account constraints of power converter e.g. MPS (power

limitation)• etc..

The beam-out settings are generated from LINKRULES• Java classes in LSA core• Each hardware devices is associated with a linkrule• They can be shared, default linkrules applies when not specified for a given HW

Linkrules examples

Linkrule for sextupoles : during beam-out demagnetisation and next cycle preparation

Linkrule for MPS: current ramp down accordingly with the power converter constraints

Chromaticity : No setting during beam out Ring Momentum: No setting during beam-out

Linkrule for MAL1001: for ramp up, stay at plateau value, ramp down, back to the correct current for the next cycle

MAL1001/K : no settings during beam-out

77

Why is this concept is not needed in other injectors?

• Less High level parameters for the moment. They are defined along the full cycle.

• Settings are not generated but copied from one cycle to the other

• Less magnetic history constraints

To be seen if this becomes a limitation in the future

78




• Corrections




• LSA software


79

LSA app suite : settings management

• Mainly used to Trim settings• Can also compare • Generate settings• Acquire and drive

80

LSA app suite : copy settings

81

LSA app suite : compare settings

• Visualize the settings difference between 2 contexts parameters by parameters

• Possibility to copy from one context to the other

82

LSA app suite : context manager

• Create context• Clone context• Delete context

• Does not deal with context types

83

LSA app suite : resident context manager

Managed the resident context : • Associate LSA context to

user• Drive the new resident

context settings to HW

84

LSA app suite : configuration

• Create device groups• Create and edit the working

sets and knobs• Request synchronisation

between CCDB and LSA

85

Generation application

• Create/ edit context types• Create context• Generate settings

• Special version for LHC with the hypercycle managment

86

Optics management application

• Update elements from madxsequences

• Create/edit Knobs• Visualise optics• Upload optics

87




• Corrections




• LSA software


88

LSA architecture

Picture from Roman Gorbonosov 89

Slide from LSA team at BE-CO technical meeting may 2018

90

LSA control system

One independent instance of lsa-server per accelerator

Several versions of the LSA database• PRO : contains all data used in operation• NEXT : monthly updated with a copy of PRO. Used to try any

modification before they are applied to pro.• TEST : used for the unit test• DEV : mostly used during LSA core software development by LSA team

Accessing LSA API from java• Add product “lsa-client” in product.xml

• Access all lsa services with :

91

LSA control system

Many lsa “Services” in lsa-client to access LSA functionalities

OP has the responsibility of the makerules and value generators.One lsa-ext-xxx modules per accelerator

92




• Corrections




• LSA software


93

Date post:	10-Jan-2023
Category:	Documents
Upload:	khangminh22
View:	0 times
Download:	0 times

LSA Basic concepts - CERN Indico

Documents