You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current state of camera calibration:
At each calibration step there is a loop over telescopes. The same calibration is applied to each telescope.
As raised in #702, it will be almost always required that each telescope type uses its own extractor. This is currently not supported in the current way we do things, and it also raised a few questions in my mind that I need help addressing:
Are the DL0 files still planned to be stored per telescope?
Currently the event containers have tel sub-containers. Are these planned to be kept?
We need some way of defining the defaults for certain Components (e.g. the default ChargeExtractor to use) based on the telescope. Perhaps some sort of "set-up" Component that supplies the user with the correct classes based on the telescope.
Should the ctapipe.calib.camera Components be restructured to only apply to a single telescope at a time. This would make a lot more sense in the pipeline flow. As the name suggests, these components are camera specific, and their configuration will change depending on the telescope being investigated. A wrapper class (CameraCalibratorGroup) could be created which loops through each telescope, and applies the provided calibrators for that telescope.
What is the planned approach to combine the data together for each telescope when the telescopes aren't all in a single file like they are for the sim_telarray output.
Thinking about this has made me almost wonder if instead of the tel sub-container, it would be more intuitive to handle a telescope container at the highest level, and beneath it are the "event" containers for each telescope. But I don't know if this fits with the design planned for ctapipe, and if its too late to consider such a change.
But irregardless, it would be nice to discuss the questions I have. It might also be nice to have a call to discuss big topics like these instead of the github issues page.
The text was updated successfully, but these errors were encountered:
The ability to set the extractor traits per telescope was added in #1155
The ability to choose a different charge extraction method per telescope is still unavailable (briefly discussed at Bologna meeting, #1148, won't be implemented for now)
The loop over telescopes in CameraCalibrator is still be discussed in #1165, so for now this issue will remain open.
Current state of camera calibration:
At each calibration step there is a loop over telescopes. The same calibration is applied to each telescope.
As raised in #702, it will be almost always required that each telescope type uses its own extractor. This is currently not supported in the current way we do things, and it also raised a few questions in my mind that I need help addressing:
tel
sub-containers. Are these planned to be kept?ChargeExtractor
to use) based on the telescope. Perhaps some sort of "set-up" Component that supplies the user with the correct classes based on the telescope.ctapipe.calib.camera
Components be restructured to only apply to a single telescope at a time. This would make a lot more sense in the pipeline flow. As the name suggests, these components are camera specific, and their configuration will change depending on the telescope being investigated. A wrapper class (CameraCalibratorGroup
) could be created which loops through each telescope, and applies the provided calibrators for that telescope.Thinking about this has made me almost wonder if instead of the
tel
sub-container, it would be more intuitive to handle a telescope container at the highest level, and beneath it are the "event" containers for each telescope. But I don't know if this fits with the design planned for ctapipe, and if its too late to consider such a change.But irregardless, it would be nice to discuss the questions I have. It might also be nice to have a call to discuss big topics like these instead of the github issues page.
The text was updated successfully, but these errors were encountered: