Details

    • Type: Task
    • Status: Open (View Workflow)
    • Priority: Normal
    • Resolution: Unresolved
    • Component/s: None
    • Labels:
    • Story Points:
      3

      Description

      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

            Activity

            Hide
            hassan 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.

            Show
            hassan 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.
            Hide
            kiyoto.yabe Kiyoto Yabe added a comment -

            opDB?

            Show
            kiyoto.yabe Kiyoto Yabe added a comment - opDB?
            Hide
            hassan hassan added a comment -

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

            Show
            hassan hassan added a comment - Craig will provide a proposal this ticket in the next day or so.
            Hide
            cloomis 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?

            Show
            cloomis 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?
            Hide
            yuki.moritani 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).

            Show
            yuki.moritani 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).
            Hide
            naoyuki.tamura 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?

            Show
            naoyuki.tamura 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?

              People

              • Assignee:
                cloomis cloomis
                Reporter:
                hassan hassan
              • Votes:
                0 Vote for this issue
                Watchers:
                Start watching this issue

                Dates

                • Created:
                  Updated: