Different event types / trigger types

[maxnoe]

As far as I can see, we have no information in the event container, what kind of event we have.

The next eventio version will also be able to read calibration events (e.g. pedestals).

Where should this information go and how?

First idea would by a field event_type for the DataContainer.

Should that be a number or a string?

[dneise]

I would prefer the most explicit, but I assume people wanna optimize for size here. So I'd say an int key, for a event_type_int_2_string_map dict, which must be available as "meta" information.

:-D And no code in the wild must ever use the ints ... every code must use the strings, to make sure the code is robust against mapping changes. (of course we must avoid changes in the mapping).

Can we story python enums in containers? that might solve the issue entirely...

[maxnoe]

event_type_int_2_string_map

that's an enum

[dneise]

Sorry Max .. I wrote "event_type_int_2_string_map dict" .. so that was .. for me a dict, since I wrote "dict".

By enum I mean this: https://docs.python.org/3/library/enum.html

[dneise]

I'll just try it out.

[maxnoe]

This came up today again.

For reference, simtel files can contain CalibrationEvents that can already be read by pyeventio and can be inserted into the event stream of the SimTelEventSource by setting skip_calibration_events=False.

Simtel has 4 or more types of calibration events:

• @param type Dark (0), pedestal (1), in-lid LED (2) or laser/LED (3+) data.

From sim_conv2hess.c line 2638.

How do we want to deal with event / trigger types here for now?

[FrancaCassol]

Hi,
I would suggest to copy them in the R0CameraContainer::trigger_type (as in data)

[maxnoe]

As this information is independent of data level (true for telescope event as a whole), r0 is not the right place I think. What happens when this information is needed at the DL1 level with r0 discarded?

[FrancaCassol]

I guess the trigger type (R0/R1) is kept somewhere in the DL1 format (e.g. in the event/telescope/parameters table)

[kosack]

A common set is also in the process of being defined for CTA R1 data. Once that's there, we can map the simtel numbers to CTA ones (in R1). Right now, it's not in the DL1 data, but I can add it. I guess to the trigger table, though that is at the event level, not camera, but I guess you cannot have an event with mixed trigger types. (I'll note it in #1066 ).

[kosack]

In real data, we could consider writing them to different files anyhow. Is it really useful to have non-stereo triggered events in the DL1 files? At that point, pedestals, etc, have already been computed and subtracted.

[kosack]

As this information is independent of data level (true for telescope event as a whole), r0 is not the right place I think. What happens when this information is needed at the DL1 level with r0 discarded?

It should be part of the IndexContainer, like event_id, particularly if these will have their own event_id that is not general (i.e. if they use the local camera event id, rather than the subarray trigger being involved)

For any further detail, let's wait for the official ACADA-Camera ICD, which is close to complete and will define this.

[maxnoe]

THis is fixed since some time now.