Open FrancaCassol opened 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.
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
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