Event lists for simulated events

[maxnoe]

The current definition of the event lists only caters to observed events.

I think it would be great, if we also could make a definition for simulated events, that

• would not require TIME / RA / DEC since these are mostly undefined for simulations
• defines column names for true and reconstructed properties (TRUE_ENERGY, TRUE_HMAX, ...)

Any opinions?

[TarekHC]

Hi @MaxNoe

This is essentially https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/30.

The thing is that it is hard to be consistent, given that ENERGY within the IRFs refers to the true energy, while within the event lists it refers to the estimated one...

Using TRUE_* might be more consistent with what the IACT community has been using until now, although I think using MC_* would be way more obvious, so no one makes a mistake. What do you (and others) think?

We would also need some metadata to store the usual MC-related parameters... Although that is probably something not so high level...

[jknodlseder]

What is the purpose of such a definition?

Le 14 sept. 2020 à 15:23, Maximilian Nöthe notifications@github.com a écrit :

The current definition of the event lists only caters to observed events.

I think it would be great, if we also could make a definition for simulated events, that

would not require TIME / RA / DEC since these are mostly undefined for simulations require ALT / AZ defines column names for true and reconstructed properties (TRUE_ENERGY, TRUE_HMAX, ...) Any opinions?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW2QV3ENUVT6CDTATKX4ILSFYKOLANCNFSM4RLTE4CQ.

[maxnoe]

The same as for the other definitions, to have a common data format for easy exchange and processing of such data.

Right now, one of the use cases would be to compare output of MARS, EventDisplay and ctapipe and to calculate the IRFs from such inputs.

[TarekHC]

@MaxNoe I think calculating IRFs needs DL2, not DL3. So @jknodlseder is right that it might be slightly out of scope regarding that specific science case.

But there are probably other tests and use cases that could benefit from such a definition. You could, for instance, compare a full simulation of any source with the high-level simulation of e.g. ctaobssim.

[maxnoe]

As the only difference between DL2 and DL3 is the added IRFs, this does not matter for the event list format, it would be the same for DL2 and DL3, right?

[TarekHC]

As the only difference between DL2 and DL3 is the added IRFs, this does not matter for the event list format, it would be the same for DL2 and DL3, right?

Mmmm... I kind of disagree. Even if technically they may be extremely similar, DL3 contain only gamma-like events and DL2 doesn't (so it would mean a change of paradigm, no?). In addition, DL2 would need to contain all the metadata/provenance from the simulations, which again might be slightly out of scope for this repo.

It is of course a matter of what we want to do, but DL2 is something probably more internal to ctapipe, so perhaps this is not the place for its definition (or perhaps it is?). Anyway, I still agree that it could eventually be useful to have a definition of true quantities, in case we ever need them.

[adonath]

In Gammapy we introduced "true" (energy / ra / dec) columns for simulated DL3 events lists, but this was only meant to be used internally for debugging / testing and is un-documented. During the implementation of the event sampling having access to the "true" information was useful, now that it's implemented not so much anymore. In general I agree it might be useful to have e.g. for technical studies.

I think the DL3 event list format is still rather simple and I wouldn't see any problem adding "true" columns as optional columns (https://gamma-astro-data-formats.readthedocs.io/en/latest/events/events.html#optional-columns). But I would rather see it as a preliminary solution, because I also agree with @TarekHC, that the technical requirements are different for DL2/DL3. Before cuts the DL2 event files can be orders of magnitude larger, different meta data is required and in terms of performance I'm not sure either whether FITS is the best suited format for DL2 event lists.