ctapipe_io_magic issueshttps://gitlab.mpcdf.mpg.de/ievo/ctapipe_io_magic/-/issues2021-12-06T07:55:07Zhttps://gitlab.mpcdf.mpg.de/ievo/ctapipe_io_magic/-/issues/14Missing CameraReadout in CameraDescription2021-12-06T07:55:07ZAlessio BertiMissing CameraReadout in CameraDescriptionIn the passage to ctapipe v0.12 (see #13), CameraDescription has an attribute which is a CameraReadout object. This class is filled from a file fits.gz, which is read whenever the CameraDescription is created with the method from_name (e...In the passage to ctapipe v0.12 (see #13), CameraDescription has an attribute which is a CameraReadout object. This class is filled from a file fits.gz, which is read whenever the CameraDescription is created with the method from_name (e.g. CameraDescription.from_name("MAGICCam") gives the MAGIC camera description). This file is not produced for MAGIC (the CameraReadout is a new class), so we should produce it and upload it to the CTA server where all this kind of data is stored.
An example for such fits.gz file is the one for LSTCam.
See also [https://github.com/cta-observatory/ctapipe/blob/v0.12.0/ctapipe/instrument/camera/readout.py](https://github.com/cta-observatory/ctapipe/blob/v0.12.0/ctapipe/instrument/camera/readout.py).
To create the needed file, in principle one could do also:
```python
from ctapipe.instrument import CameraReadout
import numpy as np
from astropy.table import Table
pulse_shape_lo_gain = np.array([...]) #fill with some pulse shape
pulse_shape_hi_gain = np.array([...]) #fill with some pulse shape
pulse_shape = np.vstack((pulse_shape_lo_gain, pulse_shape_lo_gain))
camera_readout = CameraReadout(
camera_name='MAGICCam',
sampling_rate=u.Quantity(1.64, u.GHz),
reference_pulse_shape=pulse_shape,
reference_pulse_sample_width=u.Quantity(0.5, u.ns)
)
camera_readout_table = camera_readout.to_table()
camera_readout_table.write("MAGICCam.camreadout.fits.gz")
```Alessio BertiAlessio Bertihttps://gitlab.mpcdf.mpg.de/ievo/ctapipe_io_magic/-/issues/13Switching to ctapipe 0.122021-12-14T21:13:41ZFederico Di PierroSwitching to ctapipe 0.12Using the latest containers will allow to use all recent functions and scripts implemented in ctapipe.Using the latest containers will allow to use all recent functions and scripts implemented in ctapipe.ctapipe 0.12https://gitlab.mpcdf.mpg.de/ievo/ctapipe_io_magic/-/issues/8Timestamps calculated in MAGICEventSource/MarsRun2020-07-23T12:55:53ZYoshiki OhtaniTimestamps calculated in MAGICEventSource/MarsRunCurrently, the timestamps in MAGICEventSource are calculated as follows:
```python
event_mjd = event_times[b'MTime.fMjd']
event_millisec = event_times[b'MTime.fTime.fMilliSec']
event_nanosec = event_times[b'MTime.fNanoSec']
event_mjd ...Currently, the timestamps in MAGICEventSource are calculated as follows:
```python
event_mjd = event_times[b'MTime.fMjd']
event_millisec = event_times[b'MTime.fTime.fMilliSec']
event_nanosec = event_times[b'MTime.fNanoSec']
event_mjd = event_mjd + (event_millisec / 1e3 + event_nanosec / 1e9) / seconds_per_day
event_data['MJD'] = scipy.concatenate((event_data['MJD'], event_mjd))
```
So the timestamps are calculated in units of "day" (Modified Julian Day, MJD).
When I try to find the coincident events between MAGIC and LST1, I prefer to use the timestamps in unit of "sec" counted since the start of each day.
So in order to get such kind of format, I need to do the following calculation:
**timestamp_reco = (event_mjd - int(event_mjd)) * day2sec [sec] (day2sec = 60x60x24)**
Then, I compared the value with the one that I simply reconstructed as follows:
**timestamp_true = event_millisec * millisec2sec + event_nanosec * nanosec2sec
(millisec2sec = 1e-3, nanosec2sec = 1e-9)**
Then, sometimes I saw the following values, for example:
**case1:
timestamp_reco = 82314.38639627304 [sec]
timestamp_true = 82314.3863962 [sec]**
**case2:
timestamps_reco = 82314.39802993555 [sec]
timestamps_true = 82314.3980302 [sec]**
In case of 1, it is ok if I discard the order below 100 ns.
However, in case of 2, even the order of 100 ns is different, and it may affect the coincidence algorithm because the coincidence window is ~ 1 µs order.
Actually, this is my concern and why I would like to change the timestamp calculation in MAGICEventSource.
This problem seems to be related with the accuracy of the float..? I don't know.
So my proposal of changes is,
**1. simply store the mjd, millisec and nanosec parameters separately in MarsRun object**
**2. change the get_stereo_event_data function to extract these parameters**
Actually, what I would like to do is to avoid using the mjd unit as the timestamps.
I would like to change the above things in dev-yoshiki branch and will do the merge-request. It would be appreciated if you gave me some comments or suggestions on this.
Best regards,
Yoshiki
Moritz HuettenMoritz Huettenhttps://gitlab.mpcdf.mpg.de/ievo/ctapipe_io_magic/-/issues/5To add the possibility to read the MAGIC Superstar files2020-06-17T13:31:57ZFederico Di PierroTo add the possibility to read the MAGIC Superstar filesTo add containers for higher level data and fill them with data from Superstar files.
This will allow to skip all steps from Calibrated to Superstar (relying on MARS for them).To add containers for higher level data and fill them with data from Superstar files.
This will allow to skip all steps from Calibrated to Superstar (relying on MARS for them).Alessio BertiAlessio Berti