Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timing in ROOT files #47

Open
grand-oma opened this issue Sep 26, 2022 · 1 comment
Open

Timing in ROOT files #47

grand-oma opened this issue Sep 26, 2022 · 1 comment

Comments

@grand-oma
Copy link
Member

I understand that time is split into two fields (du_seconds and du_nanosecond), in all TTrees.
I fear this makes it a bit cumbersome to manipulate in the analysis.
Would it be possible to merge those in a same field?...
Or maybe have for a given coinc a single (UNIX?) timestamp with second granularity, and a nanosecond timestamp for each tigger in the coinc, eg measured with reference to the first trigger?
This could be discussed.

One additionnal problem is the integer type for these 2 fields: this does not work forZHaireS sims which have a 0.5ns time step. ALso in practice we might have a sampling frequency which translate in a nn-integer sampling step.

@lwpiotr
Copy link
Contributor

lwpiotr commented Sep 27, 2022

I hoped for a single timestamp from the beginning, but: in C++ there is no standard variable that could hold unix time with nanoseconds, thus no standard variable for the TTree. We can specify the number of bits, but then it is not straightforward to read directly, if someone does not use our interface. I can go this way, but do we want it for the Data Oriented Interface? In Analysis Oriented Interface I work around it, merging both together into t0: np.datetime64 = np.datetime64(0, 'ns')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants