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
Activity
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.
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.
After discussion with Bo Xin [X] 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.
Withdrawn. See penultimate comment for explanation.
OK. If Bo Xin [X] is happy calling it saturation, I'll simply withdraw this RFC and we'll store the full well value in ADU in that attribute.