It would be very useful to track the transmission/throughput capability of individual fibers. This was discussed briefly within the Princeton Group 2021-05-03. One possibility is to update the grand fiber map with an additional floating point column with the transmission information of certain fibers. Please provide this or an alternative.
Attachments
Issue Links
relates to
INSTRM-1729Cobra .xml file is missing two broken fiber of SM1
Done
INFRA-207Create repo(s) for varying instrument characteristics
hassan
added a comment - During the informal SPS telecon 2021-05-20, cloomis stated strongly against updating GFM with this information. It needs to be stored elsewhere.
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.
cloomis
added a comment -
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?
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).
yuki.moritani
added a comment - 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?
naoyuki.tamura
added a comment - 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?
Task
Normal
During the informal SPS telecon 2021-05-20, cloomis stated strongly against updating GFM with this information. It needs to be stored elsewhere.