Detailed PVs

[ax3l]

Instead of just using a generic MetaP attribute (#48), we need add a very well defined PV property for control system identification.

[DavidSagan]

I agree. PVs should have a separate (and well defined) structure separate from MetaP.

[zhanghe9704]

I would like to provide a specific case. At JLab, we are working on our demo problem on RF cavity radiation. For this problem, we found the need to include at least the following information for each element in PALS format.

1. EPICSName - the name of the element in EPICS
2. Data channel names - the name of the data channel of time series data. These are often referred to as "PV"s by my colleagues.
3. S coordinate - This is redundant because it can be calculated from the lattice. However, it could be convenient for data scientists because they may not use the whole lattice but filter out some elements they need. However, they still want to know the relative location of the elements.

Any suggestions on how we should proceed? Thanks.

[DavidSagan]

The s-coordinate will be provided by the PALS translator. In terms of EPICS, there will need to be a PR to establish a standard. If you want to work on this, there could be a discussion as to how to structure things.

[zhanghe9704]

I'm not sure if I'm the right person for this since I don't have much experience with EPICS. However, if no one more experienced is available right now, I can start working on a prototype. Is there any guidance for beginners? I'd also like to have a discussion about it.

[DavidSagan]

Personally I don't know of anyone working on this. @jlvay Perhaps this should be discussed at a PALS meeting?

[ax3l]

@zhanghe9704 commented today:
We need attributes for:

• control system software name
• software version
• connection URI (e.g, IP address/port)
• etc.

@roussel-ryan will add some example/work we can refer to at SLAC

[roussel-ryan]

See examples here from slac-tools: https://github.com/slaclab/lcls-tools/blob/main/lcls_tools/common/devices/yaml/GUN.yaml

[zhanghe9704]

How about we define Control Parameters as follows?

ControlP:
  ControlSystem: control system name              #[String]
  Version: control software version               #[String]
  URI: IP address/port                            #[String]
  PVs:
    user_defined_keyword_1:user_defined_value_1   #[String] Could be data channel name
    user_defined_keyword_2:user_defined_value_2
        ...

I'm not sure whether we want user-defined keywords. However, it may be hard to pre-define all the keywords if we want a general ControlP for all elements. Sometimes there are tens of data channels affiliated with a single element in JLab's historical data archiver.

[ax3l]

Meeting Dec 10th: @roussel-ryan volunteers to start with defining a diagnostics beamline and then iterate and improve.

[roussel-ryan]

I have a couple of prototype options for a SLAC quadrupole example:

The needs that this aims to satisfy:

• list control names associated with a given element
• connect listed control names with element attributes where applicable (along with scaling coefficients to simulation units)
• add in useful descriptions of each control name (thinking ahead to LLM based reading of data

This exercise opens up a number of questions:

• the current approach seems a bit verbose, so this could be specified in another file?
• How do we link multiple control parameters with a single element attribute?
• What about control parameters that do not relate to beam dynamics simulations? If there are many, it may overwhelm simulation info -- maybe this should all go in a separate file / database
• what names should we refer to for "bact/bctrl" etc? These may be SLAC specific and so wouldn't be compatible with other facilities

I would love to get thoughts from @schr476 and the NARAD team. This highlights the importance of graph structures, databases that may extend beyond a YAML format. Thus it may make sense not to support the nomenclature in PALS directly, but include the ability to incorporate connections to other software tools.

qcm01:
  kind: Quadrupole
  length: 0.23000000417232513
  MagneticMultipoleP:
    Kn1L: 0.0
  ControlP:
    bact:
      name: KICK:DIAG0:110:BACT
      parameter: MagneticMultipoleP.Kn1L
      scale: 1.0
      description: "Quadrupole strength actual"
    bctrl: 
      name: KICK:DIAG0:110:BCTRL
      parameter: MagneticMultipoleP.Kn1L
      scale: 1.0
      description: "Quadrupole strength control"    
    bmax: 
      name: KICK:DIAG0:110:BMAX
      scale: 1.0
      description: "Quadrupole strength max"
    bmin: 
      name: KICK:DIAG0:110:BMIN
      scale: 1.0
      description: "Quadrupole strength min"
    ctrl: 
      name: KICK:DIAG0:110:CTRL
      description: "Quadrupole control status"

[satogata]

Hi @roussel-ryan -- I have been thinking something very similar to "Thus it may make sense not to support the nomenclature in PALS directly", and wrote a draft document earlier today trying to make PALS-Ext facility agnostic with signal names, and an additional facility-specific mapping layer for signal instances. For example, in the type library:

SignalInterfaces:
  quadrupole:
    signals:
      - id: strength.setpoint
        role: setpoint
        parameter: MagneticMultipoleP.Kn1L
        units: 1/m
      - id: strength.readback
        role: readback
        parameter: MagneticMultipoleP.Kn1L
        units: 1/m
      - id: strength.max
        role: limit_max
        units: 1/m
      - id: strength.min
        role: limit_min
        units: 1/m
      - id: control.status
        role: status

This defines certain signals like quadrupole.gradient.readback and quadrupole.gradient.setpoint that are independent of low-level implementation, and supports a separate facility-specific binding graph that includes something like this for a quadrupole with (facility-specific) name qcm01:

Bindings:
  - signal: qcm01.quadrupole.strength.readback
    endpoint:
      type: EpicsPV
      name: KICK:DIAG0:110:BACT
    scale: 1.0
  - signal: qcm01.quadrupole.strength.setpoint
    endpoint:
      type: EpicsPV
      name: KICK:DIAG0:110:BCTRL
    scale: 1.0
  - signal: qcm01.quadrupole.strength.max
    endpoint:
      type: EpicsPV
      name: KICK:DIAG0:110:BMAX
  - signal: qcm01.quadrupole.strength.min
    endpoint:
      type: EpicsPV
      name: KICK:DIAG0:110:BMIN
  - signal: qcm01.quadrupole.control.status
    endpoint:
      type: EpicsPV
      name: KICK:DIAG0:110:CTRL

It has the benefit of not loading down PALS itself with all the control point instances and implementations, and supporting hierarchical controls definitions that will also improve generality. Of course it is at the expense of adding an extra indirection/layer in the binding graph, but with the benefit of clearly separating facility description/design intent vs facility implementation.