Update to device branching logic

[tangkong]

Context

Currently devices are assigned a singular beamline and z-position. This is all the information that is used to define the system

See this map for our current understanding of the beamlines and branches

Ideas / Approaches

• Try to implement a directed graph of some sort using branching devices as nodes
• add happi information input_lines and output_lines to branching devices?

[tangkong]

I think to properly generate a view of LCLS devices, there need to be some changes to device metadata. I propose happi record:

• beamline: the area/hutch they belong to (for back compatibility)
• input_branches: List[str]
• output_branches: List[str]

In the past we've recorded the input/output paths on the device itself, but this could all live inside happi. input_branches and output_branches can be identical for a simple device sitting on a single branch, while mirrors/LOCDM's will have multiple inputs/outputs. input_branches and output_branches should be strictly enforced in this schema as the L# found in the LCLS naming conventions, since branches are known and static.

I think this would also be facility agnostic, but that's maybe not our highest priority at the moment.

[ZLLentz]

Does this mean we would define a lightpath happi container in lightpath? Currently we're leaning on this container from pcdsdevices: https://github.com/pcdshub/pcdsdevices/blob/master/pcdsdevices/happi/containers.py

[tangkong]

Maybe we just modify the existing LCLSItem to require the new fields?

[ZLLentz]

I think that's correct for us, I was wondering if we needed to add something in lightpath itself to allow usage in other facilities

[tangkong]

Some additional thoughts on this approach (input_branch and output_branch):

Pros:

• Building a directed graph should be simple with this information

Cons / things to think about:

• Requires knowledge or a readily available map of the branches in the facility
• Externally to LCLS, branches may not have consistent names
• Even internally to LCLS, the branch. naming convention is not universally applied (LCLS I vs II)
• Currently some destinations might be confusing for scientists (What is the input branch for TXI?)

[tangkong]

One way to evaluate what structure we want to use is by thinking about what methods we want to support:

Methods to support:

• Given an active source (HXR or SXR)
  • Path from source to destination
• Earliest blocking device
• Incident devices, what is receiving beam.
• Generate views / map of
  • all LCLS (zoomed out)
  • devices along path to a specific beamline

[tangkong]

Directed Graphs:

• edge weights provide a way to use existing path finding algorithms (inserted devices can set outgoing edges to infinite weight)
  • Dijkstra shortest path is one obvious possibility
• graph construction is less well defined, since each node (device) needs to define an input and output.
  • We can work around this by grouping nodes by area (or by similar in/out branches), then sorting by z and creating a linear graph