We decided at some point that we wanted to use the TI event timestamp as
the LCIO event timestamp. Yes, this is not what the LCIO javadoc tells you
to expect.
(Aside: In principle it should be possible to combine the TI event
timestamp with the Unix time from CODA to get a time that has nanosecond
resolution but is referenced to the epoch, and use that as the LCSim event
timestamp - but this is just an idea in the back of my head, and I think
we need the run crawler/run database first.)
There is a timestamp in the EVIO "head bank" but it is only available in
every 10th event (due to event block size). Also, it is not copied to
LCIO in pass 1. If you run EvioToLcio now, it is copied; and if you wait
for pass 2, it will be in the LCIO files.
Things Pelle brought up:
I agree that you should not need to cut out events during beam trips -
there should be basically no triggers if the beam is off (except for
pulser triggers, but you should be cutting on single1 or pair1 trigger
bits anyway). You do need to cut out events during the "bias off" and "SVT
open" periods, and that should automatically take care of beam trip
periods (bias is always off when the beam is tripped).
I think you are probably safe ignoring burst-mode noise. At your trigger
rates (11 and 7 kHz) the fraction of events affected is quite small (3% at
most), and in runs I've looked at, the events affected by burst-mode noise
are still basically OK (we expect SVT performance to suffer).
We think the SVT latency is OK starting with run 5722. If you're looking
at any older runs, we should talk about it.
On Wed, 29 Jul 2015, Hansson Adrian, Per Ola wrote:
> Hi Sebouh,
>
> I?m out but Sho is looking into this so you should coordinate with him.
>
> One note, I?m not sure you care about beam trips as there will be no events during that time.
>
> What you mostly care about is the SVT bias voltage being on and the opening angle of the detector was ok (not moving for example). The latter is a very small effect as long as you use the later runs when things were more stable. I and Sho have been putting together a way for users to reject those periods. The last thing is burst noise and latency issue but Sho can tell you about those if you want to know how we plan to attack those initially.
>
> /Pelle
>
> On Jul 29, 2015, at 10:56 AM, Sebouh Paul <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>
> Does anyone know where I can get absolute time from an event (ie, is it only in the EVIO and not copied ot the LCIO, or has it already been copied to somewhere in the LCIO?) Also i think it's misleading that the method "getTimestamp" has in its javadoc description that it's the ms since epoch (1970-01-01 00:00:00), and yet it has some smaller units (i'm guessing nanoseconds since that is consistent with the differences between the timestamps between events N events apart, and the tabulated event rate).
>
> What I want to do is mask out events that took place during the time when beam trips took place (the times of the beam trips I have found by looking at the scalers in Mya, which uses absolute time in ms), and then only use the events that are not during beam trips, and when the SVT is running etc.
>
> thanks
>
> ________________________________
>
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
|