Change request #1433
CTA EVENT_ID should be 64Bit long
Status: | New | Start date: | 03/03/2015 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assigned To: | - | % Done: | 0% | |
Category: | - | |||
Target version: | - | |||
Duration: |
Description
Discussing the FITS exporter for HESS with Christoph, we came to the conclusion that we want to use 64bit integers for the event id. This would allow for assigning unique event identifiers throughout the experiment time scale.
Accordingly, we propose to change the m_event_id
in GCTAEventAtom
to be changed from unsigned long
to long long
in order to assert 64Bit event identifiers. read
/write
methods would have to be adapted, too.
Is it ok to implement this in gammalib
?
Recurrence
No recurrence.
History
#1 Updated by Knödlseder Jürgen almost 10 years ago
It would be good to get Karl Kosack into the loop for this discussion, eventually also Jose Luis Contreras. We want to be compliant with the CTA data format.
We could always write a kluge that handles whatever data format is found, but store the event ID internally as 64 Bit.
But I’m wondering whether you could still fit all CTA events that will ever occur in a 64 Bit integer.
#2 Updated by Deil Christoph almost 10 years ago
The latest version of the CTA event list spec from Karl from 2011 doesn’t say what type of INT it should be, so we are free to define it now how we like.
There have been email discussions on this in the past two weeks, but this is not the right place to repeat them.
I’m waiting for a decision by Jose Luis if I or someone else can update and maintain the CTA event list spec.
Once this is clear we can discuss this and other changes on the cta-data mailing list.
Concerning the “assert 64 bit event identifiers”: what does this mean?
Given that there are event lists with 32-bit integer EVENT_ID values from the CTA-1DC, I think it should still work, and appropriate responses would be:
- Emit a warning if EVENT_ID is not INT64
- Don’t complain when reading data where EVENT_ID is INT32, but always write INT64 from now on.
I don’t have a preference, either is fine.
But I do think using INT64 here is important ... it simplifies computing the EVENT_ID for HESS and likely will for CTA, too.
The extra storage space for these bits is irrelevant, there’s no drawback.