Defining trigger time in NuRadioReco

[fschlueter]

Should it be defined absolut or relative (to station time). In what format do we want to store it (astropy, float tuple, ...). Do we need ns precision?

[shallmann]

To give a bit of more detail how the readout is done:

• The integer seconds part is taken from the readout time
• The subsecond part in the trigger is determined on a ~100 MHz clock (cf here: https://github.com/RNO-G/mattak/blob/d17d10315f8b7b944f834b86fe0579679d062e62/src/Header.cc#L28) i.e. it will anyway not be sub-nanosecond accuracy

The different options are:

• use a float tuple (second, nanosecond):
  • "+" mostly similar to what happens in the daq (but not quite, since wrap around is required)
  • "-" maybe cumbersome to puzzle together in analysis?
  • astropy:
  • "+" convenient to use
  • "-" inconsistency of how precision is stored across astropy/python versions (https://github.com/astropy/astropy/blob/e40c0eb94b7729ceb7e8d7fe93d8b57f003e2c8c/astropy/time/formats.py#L1591), caused errors in the past for .nur I/O
• use time with non-sub-ns accuracy: I think it is ok, since the trigger time is not known with sub-ns accuracy AFAIK

[sjoerd-bouma]

Some more comments:

• we currently store astropy.time.Time objects by calling .value (see https://github.com/nu-radio/NuRadioMC/blob/9b588ee8ba3cea753b30086652c6ec22f78dcffb/NuRadioReco/framework/base_station.py#L241-L247). I'm not sure if this ensures the precision we're interested in. E.g. trying to set an astropy.time.Time object with a np.float128:

  from astropy.time import Time
  import numpy as np
  time_128 = np.float128(int(Time.now().unix)) + np.float128(1e-9)
  print(time_128, type(time_128))
  aptime = Time(time_128, format='unix')
  print(aptime.value, type(aptime.value))

  results in the output

  1680768370.000000001 <class 'numpy.float128'>
  1680768370.0 <class 'numpy.float64'>

  If we do store our times as unix doubles, the precision is limited to 52 bits, which means ~ 400 ns. This will limit what we can do with multiple-station coincidences.

[fschlueter]

Just to put the information here and to restart the discussion. For the (just merged) mattak reader we set the trigger time absolute and the traces start time is relative to that.

[fschlueter]

Some more comments:

• we currently store astropy.time.Time objects by calling .value (see https://github.com/nu-radio/NuRadioMC/blob/9b588ee8ba3cea753b30086652c6ec22f78dcffb/NuRadioReco/framework/base_station.py#L241-L247 ). I'm not sure if this ensures the precision we're interested in. E.g. trying to set an astropy.time.Time object with a np.float128:

from astropy.time import Time
import numpy as np
time_128 = np.float128(int(Time.now().unix)) + np.float128(1e-9)
print(time_128, type(time_128))
aptime = Time(time_128, format='unix')
print(aptime.value, type(aptime.value))

results in the output

1680768370.000000001 <class 'numpy.float128'>
1680768370.0 <class 'numpy.float64'>

If we do store our times as unix doubles, the precision is limited to 52 bits, which means ~ 400 ns. This will limit what we can do with multiple-station coincidences.

Good that you bring that up Sjoerd. So we already store the time(stamp) as a float to file. I think that is the right way to go because storing astropy objects carries the danger of compatibility problems (e.g. see https://github.com/nu-radio/NuRadioMC/issues/481 where this happened for the event header where we used to store astropy objects). I would suggest the following: Within NuRadioMC we use astropy where ns precision is required and to file we store two floats/integers (the second and the nanosecond).

[fschlueter]

Just to document it here. We decided in the call on May-the-force that we will store the time with two numbers (second and nanosecond) + format to disc but will convert it to Astropy.Time in memory. @sjoerd-bouma or me will propose an implementation

[fschlueter]

What we have not decided is wether we want to store the trigger time as an absolute time or a relative time. As far as I can see we have the station_time, event_time and trigger_time. We should define what is their "relationship" and properly document it.