During the informal SPS telecon 2021-05-20, cloomis stated strongly against updating GFM with this information. It needs to be stored elsewhere.

opDB?

Craig will provide a proposal this ticket in the next day or so.

• Most consumers only need the full end-to-end throughput.
• In many cases, we will only to have measures of the full end-to-end throughput
• We can then fill in per-segment numbers as we learn more.

So I propose a pfs_instdata table (csv-like?) with one row per fiber, and four+ columns, all 0.0 to 1.0. And, of course, a class/function in pfs_utils.

• one total throughput column
• columns for each segment.
• some flags columns (always needed!)

The question is then how to manage the possibly inconsistent total throughput measures and product-of-segments measures.

One scheme would be to declare that if the total throughput column is <= 1.0, *only *the total throughput column should be used: the per-segment numbers would be purely informative. Otherwise we use the product-of-segments.

Thoughts?

pfs_instdata sounds good to me.

One think we should keep in our mind is that throughput of each segment is measured using green LED (~550nm: TBD). On the other hand, end-to-end throughput will be measured by spectrograph, I think.. So it may be helpful to list total throughput at a couple of wavelength (e.g. per arm).

A table in pfs_instdata sounds good to me too, and adding wavelength information sounds like a good plan also.
Would the numbers in the table be over-written every time a measurement is performed, or would a new table be created and saved into a new file so that one can trace the history?

Regarding the inconsistency between total throughput and integration of individual segments, I have no good answer of what to do. I suspect it could take a while to find a good way to interpret and reconcile it if they are found inconsistent. In any case, recording them as proposed would give us a chance to deal with it in the future?