search

open-gamma-ray-astro / gamma-astro-data-formats

Data formats for gamma-ray astronomy
https://gamma-astro-data-formats.readthedocs.io
Creative Commons Attribution 4.0 International
29 stars 27 forks source link

Misleading Keyword EV_CLASS #119

Closed maxnoe closed 5 years ago

maxnoe commented 5 years ago

From the specs:

EV_CLASS type: str
        Event class (the ‘cut’ that has been used, e.g. ‘STD’, ‘HARD’, ‘SOFT’)’.

Several questions pop to my mind:

I think this header keyword is confusing and misleading and should probably either be removed or changed.

cdeil commented 5 years ago

@MaxNoe - Please review and comment on https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/pull/116 also, there I'm moving it to optional for now.

Note that Fermi-LAT has event classes: https://github.com/gammapy/PyGamma15/blob/gh-pages/talks/fermi2/fermi_advanced_v0.pdf So do all the current IACTs.

We could add a glossary entry what event class is and reference that entry from the keyword spec? http://gamma-astro-data-formats.readthedocs.io/en/latest/general/glossary.html

maxnoe commented 5 years ago

I think the term event class is misleading.

Event class for me is something like gamma-like proton-like muon-like.

This is more a question of the event selection and I think the keyword should reflect that.

cdeil commented 5 years ago

@MaxNoe - This event class and event type has been discussed in the past 3 years. Usually the conclusion is just that what Fermi-LAT used is as good as any other terminology and we should just adopt this: https://github.com/gammapy/PyGamma15/blob/gh-pages/talks/fermi2/fermi_advanced_v0.pdf

Some people prefer what Fermi has, some the opposite terminology, some something else.

I would suggest to add glossary entries to the spec that for now we use the terminoloty as in Fermi, but that this is an open point of discussion that will eventually be decided by CTA in the future.

cdeil commented 5 years ago

I tried to address this issue. See https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/pull/116#issuecomment-408611796

So I made it optional and tried to explain the origin of it and that we really don't have a full solution for this at the moment.

Personally I would also tend to remove it, but then e.g. Catherine thinks it's important provenance information, so I don't feel it's my place to completely remove the mention of this key that has been filled e.g. in HESS for the past years and used by people to see which config=class was used in the export to a given FITS file.

OK?

Closing this issue now. If you have a specific suggestion for a change, or to improve the explanation, please re-open or send a PR or open a new issue.