cta-observatory / ctapipe

Low-level data processing pipeline software for CTAO or similar arrays of Imaging Atmospheric Cherenkov Telescopes
https://ctapipe.readthedocs.org
BSD 3-Clause "New" or "Revised" License
64 stars 269 forks source link

MON & SVC data in ctapipe #747

Open FrancaCassol opened 6 years ago

FrancaCassol commented 6 years ago

Hi, writing the reader for LSTCam data I run into a conceptual problem: LST data files include a CameraConfiguration header (one per file) that contains data that could be consider SVC or MON data, and can be read/set one time per file. Wondering on where to place them into the containers, I realized that in ctapipe the EVT, MON and SVC concepts are still missing. We have for example

r0.tel[m].waveform and not r0.tel[m].evt.waveform

so, in the case of LST specific data, I plan to introduce the evt and svc containers, like

lst.tel[0].evt.xxx --> for event specific data lst.tel[0].svc.yyy --> for camera specific data

what do you think, is there anything wrong with that?

Cheers

Franca

kosack commented 6 years ago

so far, the event structure is supposed ot be for only EVT data, though we have mixed in some SVC header info (e.g. mcheader, and inst.subarray) that will be removed in the next version, and handled separately from the event data.

The current way we do things is that all header info is part of the instrument config, and eventually only things that change per event should be in the event container. however, the containers do have a concept of meta-data headers, which you can access via e.g. event.meta, or event.r0.meta, and anything in those meta dicts will be written to the output file's header. So probably for now that is where you want to put this info. It is free-form, so no need for any structure to it, just key=value pairs.

Can you give examples of what data this is? That would help to structure things better.

FrancaCassol commented 6 years ago

Hi Karl, too late ;-) I implemented the SVC data in a LSTServiceContainer included in container.py that is filled in lsteventsource.py, you can see there the fields implemented till now (some are still not completely explicited, e.g. algorithms or pre_proc_algorithms, and others are still missing because I wait for the new EventBuilder version)... but no problem to change. Some of the data are indeed instrument data (e.g. num_pixels which can now be reached as event.lst.tel[telid].svc.num_pixels) and other are more software-like data (e.g. data_model_version which can be reached as event.lst.tel[telid].svc.data_model_version)... Let me know what do you suggest