Add a few containers for monitoring data - #3063
Conversation
|
I'm not sure that having the containers with nan defaults in the event structure is the right choice in this case. Maybe better use Like this, it's clear that the monitoring was not filled at all, not that we tried to fill it and didn't succeed. |
…ns container to provide Alt/Az corrections
| default_factory=CameraMonitoringContainer, | ||
| description="Container for monitoring data for camera", | ||
| ) | ||
| structure_pointing = Field( |
There was a problem hiding this comment.
Following our discussion on slack on when / how lower-level monitoring is combined, I don't really see the need to add these containers to the event structure.
Is there a use case remaining?
I think we agreed that the more efficient approach is to compute the final correction on the monitoring time scales based on tabular data and interpolate that to the event.
In that scenario, we would not need event-wise data structures for these lower-level parts.
There was a problem hiding this comment.
I think we still want them for the star tracking. However, in this case I should leave them as standalone containers, but remove from being linked to the event, so it is only filled on request and not for every event processed with ctapipe-process tool, right?
In this case, I will leave TelescopePointing and CameraDisplacement containers here (I believe there's no easy way around for Camera Displacement, as I believe it would be only used to modify image, so we just take it as is and interpolate to the event time).
There was a problem hiding this comment.
You mean as output containers from the star tracking which would work on bunches of events? Or as intermediate input per event?
There was a problem hiding this comment.
as intermediate event-wise input to star tracker. The output of star tracker would be a grid of corrections (common grid with the structure monitoring).
There was a problem hiding this comment.
Why would the star-tracker not use the pointing filled from Structure + BendingModel into the telescope poiinting container?
There was a problem hiding this comment.
It will use the pointing from Structure + BendingModel as the seed, but it will also use CDM for a given event and weather values for the given event.
There was a problem hiding this comment.
Sure, weather is needed and should be added here.
But for the pointing, I would think that you configure the DL0MonitoringSource to read Structure, BendingModel and CDM files and use that to fill the already existing pointing container.
There was a problem hiding this comment.
Yes, it will be done like that. However, I still need to define the TelescopeStructurePointingContainer, TelescopeStructureDisplacementContainer, etc for conversion, to abstract telescope-specific implementations. They, however, would not be added to the event monitoring structure.
There was a problem hiding this comment.
I don't understand for what you need the containers then
Co-authored-by: Maximilian Linhoff <maximilian.linhoff@tu-dortmund.de>
|
3 participants
Containers implementation for #3055