Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-655

Add full well value to Amplifier object

    Details

    • Type: RFC
    • Status: Withdrawn
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      The afw.cameraGeom.Aplifier class currently has a saturation attribute, but that attribute is intended to to hold the numeric saturation in units of ADU. It would be helpful to the commissioning and V&V teams to be able to also hold the physical saturation in units of electrons. It's important to save both since there are configurations that would allow numerical saturation to occur at values less than the full well value.

      This would result in adding a single attribute with associated getters to the Amplifier class.

        Attachments

          Issue Links

            Activity

            Hide
            krughoff Simon Krughoff added a comment -

            OK. If Bo Xin is happy calling it saturation, I'll simply withdraw this RFC and we'll store the full well value in ADU in that attribute.

            Show
            krughoff Simon Krughoff added a comment - OK. If Bo Xin is happy calling it saturation, I'll simply withdraw this RFC and we'll store the full well value in ADU in that attribute.
            Hide
            krughoff Simon Krughoff added a comment -

            OK. So as Merlin pointed out, there are two values of saturation that people want to store. So, I think I would still like two named attributes. We can keep saturation to mean the point source saturation so ISR doesn't have to change and we add saturation_flatfield to store the values we get from the camera team. Unless I'm misunderstanding something, these values are not trivially derivable from each other as the ADU vs. electron saturations are. If there's no major pushback to this idea, I'll change the description to reflect the new intent.

            Show
            krughoff Simon Krughoff added a comment - OK. So as Merlin pointed out, there are two values of saturation that people want to store. So, I think I would still like two named attributes. We can keep saturation to mean the point source saturation so ISR doesn't have to change and we add saturation_flatfield to store the values we get from the camera team. Unless I'm misunderstanding something, these values are not trivially derivable from each other as the ADU vs. electron saturations are. If there's no major pushback to this idea, I'll change the description to reflect the new intent.
            Hide
            rhl Robert Lupton added a comment - - edited

            Unless the camera team really really wants the saturation_flatfield I wouldn't add it. It is not useful for any data processing; I don't suppose it does much harm but it does clutter up the Detector for no purpose.

            Show
            rhl Robert Lupton added a comment - - edited Unless the camera team really really wants the saturation_flatfield I wouldn't add it. It is not useful for any data processing; I don't suppose it does much harm but it does clutter up the Detector for no purpose.
            Hide
            krughoff Simon Krughoff added a comment -

            After discussion with Bo Xin and Robert Lupton, I think I understand the situation better now. Bo is really using that value since we don't have a measurement of the point source saturation value at the moment. I think we can agree to use that value for now as a stand in until we have the data to compute the point source saturation, knowing that it is an approximation.

            This means we will simply put the value we currently have in the saturation attribute for the time being and the Amplifier object needs not change. I will withdraw this RFC if I hear no dissent by 16:00 project time today.

            Show
            krughoff Simon Krughoff added a comment - After discussion with Bo Xin and Robert Lupton , I think I understand the situation better now. Bo is really using that value since we don't have a measurement of the point source saturation value at the moment. I think we can agree to use that value for now as a stand in until we have the data to compute the point source saturation, knowing that it is an approximation. This means we will simply put the value we currently have in the saturation attribute for the time being and the Amplifier object needs not change. I will withdraw this RFC if I hear no dissent by 16:00 project time today.
            Hide
            krughoff Simon Krughoff added a comment -

            Withdrawn. See penultimate comment for explanation.

            Show
            krughoff Simon Krughoff added a comment - Withdrawn. See penultimate comment for explanation.

              People

              • Assignee:
                krughoff Simon Krughoff
                Reporter:
                krughoff Simon Krughoff
                Watchers:
                Bo Xin, Merlin Fisher-Levine, Robert Lupton, Simon Krughoff
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel