You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past we've tended to set the timestamp required information in the Run tables to zero for all events in MC runs. This is not ideal if we want to be able to study tagging of muons or other time related vetos in the future.
We should probably generate time stamps based on some user configured trigger rate to allow for more data-like vetoing in these cases. This should be simple enough to implement and, as long as the user doesn't try for a rate >~1 kHz leaves ample space for any long duration events that could be split into multiple triggers.
Also could be a nice easy first PR for someone.
The text was updated successfully, but these errors were encountered:
After some thoughts I believe this is fairly easy, one should just relate time with nexus event_number, so the timestamp should simply be rate*nexus_evt_number + random(rate) ensuring that is only positive, or course.
In the past we've tended to set the timestamp required information in the Run tables to zero for all events in MC runs. This is not ideal if we want to be able to study tagging of muons or other time related vetos in the future.
We should probably generate time stamps based on some user configured trigger rate to allow for more data-like vetoing in these cases. This should be simple enough to implement and, as long as the user doesn't try for a rate >~1 kHz leaves ample space for any long duration events that could be split into multiple triggers.
Also could be a nice easy first PR for someone.
The text was updated successfully, but these errors were encountered: