Updated over 2 years ago by Knödlseder Jürgen
This page summarises a couple of thoughts on a possible COSI instrument interface
There are different event types that need to be handled by the interface, including Compton events, pair events, photo effect events, muon events and unidentified events.
For each of the event types a specific GCOSEventList
and GCOSEventAtom
class needs to be implemented to cope with the different data structures of the event types. If needed, GCOSEventList
and GCOSEventAtom
base classes may be implemented for common services. For example, GCOSEventList
could handle the generic reading of tra and fits
files. For convenience, reading of both file types should be supported.
Each event type would then be handled by a specific instance of GCOSObservation
. While the GCOSObservation
will probably be generic for any kind of COSI event type, it will hold the specific GCOSEventList
class that corresponds to a single event type.
Since the response for a given event type will be quite specific, separate response classes for specific event types will be implemented, possibly derived from a GCOSResponse
base class.
Therefore we expect that the following classes will be implemented ultimately:
GCOSObservation GCOSEventList +- GCOSComptonEvents +- GCOSPairEvents +- GCOSPhotoEvents +- GCOSMuonEvents +- GCOSUnidEvents GCOSEventAtom +- GCOSComptonEvent +- GCOSPairEvent +- GCOSPhotoEvent +- GCOSMuonEvent +- GCOSUnidEvent GCOSResponse +- GCOSComptonResponse +- GCOSPairResponse +- GCOSPhotoResponse +- GCOSMuonResponse +- GCOSUnidResponseIt remains to be seen whether actually all response classes need to be implemented, as not all event types will be used for science.
Some functionality should be implemented to define ranges for the number of hits for GCOSComptonEvents
and the associated GCOSComptonResponse
. This will allow to handle different hit numbers as different observations, combining all information in a joint maximum likelihood analysis.