Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PointingInterpolator #1902

Closed
kosack opened this issue Apr 27, 2022 · 4 comments · Fixed by #2409
Closed

PointingInterpolator #1902

kosack opened this issue Apr 27, 2022 · 4 comments · Fixed by #2409
Milestone

Comments

@kosack
Copy link
Contributor

kosack commented Apr 27, 2022

Please describe the use case that requires this feature.

Pointing information is monitoring data stored on timescales on the order of 1 Hz. Therefore it must be interpolated to an event time to get the pointing direction of an event. This is needed both in the ctapipe-process event-loop, as well as useful to have in TableLoader to be able to work with interpolated event positions.

There are two types of pointing information:

  • the pointing direction (azimuth, altitude)
  • the pointing corrections (dx, dy, camera rotation, maybe skew...) note above the DL1 level, probably the offsets dx,dy are already applied to the direction, but rotation and skew is still important.

Interpolation in spherical coordinates also has some caveats, as there are poles in the Alt/Az system and these are circular coordinates, so wrapping has to be considered (in case the instrument doesn't return azimuth values > 360 deg for example).

Describe the solution you'd like

a PointingInterpolator Component that can be used to interpolate a single or multiple event times and returns an event-wise pointing direction. Something like the following:

interpolate_pointing = PointingInterpolator(pointing_table, pointing_correction_table)

# given an event table "events"
events['ra_pnt'], events['dec_pnt'], events['rot_pnt'] = interpolate_pointing(events['time'])

Inside, would just be a scipy.interpolate.interp1d or similar, but taking into account cyclic boundary conditions.

Additional context

  • Pointing information (but not yet pointing corrections) are stored in the ctapipe HDF5 output files in /dl1/monitoring/telescope/pointing. For simulations, there is only one entry (since simulations do not track a source in the sky, so no interpolation is needed), for real data there are multiple entries here over time.
    image
  • For pointing corrections, simple interpolation may not be sufficient since there can be hysteresis effects (the history of telescope movement can influence the corrections), so perhaps it is better to split this into a PointingInterpolator and PointingCorrectionInterpolator. But remember: both are needed to do reconstruction, as the images or image parameters need to be corrected by any shift or rotation before reconstruction.
  • This could also be automatically constructed in TableLoader, see TableLoader: Option to load pointing information #1900
@kosack kosack added this to the v1.0.0 milestone Apr 27, 2022
@maxnoe
Copy link
Member

maxnoe commented Apr 27, 2022

@kosack
Copy link
Contributor Author

kosack commented Apr 27, 2022

Looks like the LST version does both bending corrections and pointing interpolation at the same time (which is good). I don't seem to see it doing any rotation corrections, though - is that not an issue with the LST? (bending that causes the camera to rotate slightly which needs to be applied to the hillas_phi (or pixel positions for ImPACT)?

@maxnoe
Copy link
Member

maxnoe commented Apr 27, 2022

@kosack That's what we have as information now, I don't know what else is planned exactly (I remember talk about star guider pointing corrections, but this not yet used in analysis)

@kosack
Copy link
Contributor Author

kosack commented Apr 27, 2022

In any case, having a single class the both interpolates the Pointing Monitoring table and applies the Pointing Correction (if it exists, for now we can use a null operation) would be nice. Then that allows us to swap in more complex corrections if needed. it's configurable inputs can just be the filename of the H5 file containing the table which could be the same filename as the input, or an external file.

For the event-loop version, it should fill the result into the event.pointing . So the interface could be something like:

get_pointing = PointingInterpolator(parent=self)

for event in source:
    calibrate(event)
    get_pointing(event)  # the __call__ method fills the results into the event like other Components
    ...

for using it in TableLoader could have a separate public functoin:

pointing_interp = PointingInterpolator(pointing_file=self._h5file, correction_file=None)

# the apply() method is lower-level and allows direct access to event times
output['pointing_alt'], output['pointing_az'], output['pointing_rot'] = pointing_interp.apply(tel_id, event_times )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants