Add parent "program" + "facility" to beamline?

[padraic-shafer]

Nathanael (Nate) Maytan (@nmaytan) recently suggested that it would be useful to include the beamline's home program (e.g. "IOS" is in the "Spectroscopy" program at NSLS-II) in the payload returned by e.g. the /v1/beamlines endpoint.

Harika Bishai (@HarikaBishai) suggested that perhaps the beamline's facility should be included too. At the moment there seems to be the tacit understanding that all beamlines are "NSLS-II" beamlines (as opposed to CFN, LBMS, CryoEM, etc.). That might be ok, given the name of this repo is "nsls2api" -- but we should probably codify this one way or the other.

[padraic-shafer]

Nathanael (Nate) Maytan (@nmaytan) Could you build out the case for this a bit? E.g., what is the desired or projected use case? What workaround are you using now? What changes would be needed, and what are the downstream impacts?

[padraic-shafer]

What do people think about the need to explicitly include the "facility" vs assume it? If we should be less facility-specific, does beamline program become something more like "group"?

[nmaytan]

The biggest reason to have the program information included in the beamline response is that it makes it possible to programmatically do things per-program rather than having to hardcode a list using the current org chart, which also must be updated later if there are changes or new beamlines come online. We can imagine reasons to do things per-program, such as: the assigned team coordinates to deploy a fix for their beamlines, a DSSI group wants to split up a project by tackling one program at a time, or parallelizing certain jobs (as seen recently with proposal directories).

As to the facility information: this is needed because not all "beamlines" belong to the NSLS2 facility even currently. Instruments like KRIOS, TALOS, etc. are treated as "beamlines" in the API (and I think in PASS? would need to double check my memory). So when we create proposal directories for CryoEM, we have to change the facility argument to LBMS. Similar to above, putting this in the beamline response would make this more graceful and less manual.