Timing and data exchange

1
Timing and data exchange
D.Autiero/IN2P3 Lyon, 15/1/07

• GPS Timing
• Calibrations
• Results from the CNGS run
• Perspectives
• EW and Database

2
CERN-LNGS UTC clocks intercalibration March 06
For the neutrino spill syncronization both CERN
and LNGS have a double unit (including a spare)
UTC clock system, but from different
manifacturers. The CERN system was calibrated by
the Swiss metrology institute METAS. CERN and
LNGS systems have comparable performance (lt100
ns) and their single units are in both cases
based on a GPS system Rb clock. One of the
CERN UTC units was installed and running for one
month in Gran Sasso in order to check for
relative offsets and time stability of the two
systems. Action was taken also to measure all
the delays in the LNGS time distribution chain
CERN Symmetricom XL-DC unit installed at LNGS
LNGS UTC cloks (ESAT)
3
Time difference measured during 12 days with a
time interval counter (300 ps accuracy)
22/3
10/3
plateau
Dt CERN-LGS unit 2 (ns)
Warm up
(ns)
Time (s) x 103
Correcting for the offsets the CERN and LNGS UTC
systems were able to track each other within 20 ns
Time (s) x 103
4
Discovered that the two LNGS UTC clocks which
should be identical (clock2 and clock1) have an
offset about of 140 ns. Different software
configuration ? How the antenna cable delays are
taken into account in the configuration of the
two systems
Measurement 8/3
Clock1-clock2 monitored over 13 hours
ns
Measurement 22/3
ns
5
Geodesy
The CERN system converged to the following
coordinates
N42 25 15.4 E13 30 52.9 Alt 1037 m asl
WGS84
The coordinates of the antenna used by clock2
are known from precise measurements N42 25
15.6 E13 30 52.8 Alt 985 m asl WGS84 .
The difference is due to the fact that the CERN
system refers to the WGS84 ellipsoid and the GS
system to the WGS84 geoid (the ellipsoid is about
50 m above the geoid at LNGS) Both systems are
correct Conversion factor geoid-ellipsoid at the
LNGS location Latitude 42.421 N 42 25'
15.6" NLongitude 13.5146666666667 E 13 30'
52.8" EGPS ellipsoidal height 1037
(meters)Geoid height 47.971 (meters)Orthometri
c height (height above mean sea level) 989.029
(meters) (note orthometric Height GPS
ellipsoidal height - geoid height)
6
LNGS time distribution system to underground
labs 2 independent master clock units are
installed in the external laboratory. The UTC
time scale is known at better than 100 ns. Every
ms (1000 better than the 1 PPS standard) a
synchronization pulse and the time/date string
are sent through the 8 Km long monomodal optical
fiber (1310 nm) to slave clocks in the caverns.
The ligth pulse is converted in electric serial
pulses.
Optical signal sent every ms
Edge (start of the ms)
80 bits code Date etc
GPS antenna
Master clock
GPS receiver
8 Km mono-modal 1310 nm optical fiber
Slave clock(s)
Rb clock
Underground LABs
External LAB
7
Complete calibration of the time distribution
chain
8
All the optoelectronic materials to set-up a
second path was found at CERN and the calibration
of the paths for OPERA,BOREXINO, LVD towers 1,2,3
was performed in July 06
9
TOF evaluation from the CNGS geodesy
1) Proton line down to the target Beam time tag
BFCT  41438. BFCT.41438 to CERN Target 992.4
m   2) The distances calculated from the CERN
Target to each LNGS reference point
POINT Distance
A 730465.4
B 730575.2
C 730575.6
D 730575.2
E 730574.9
3) Measurement of OPERA reference system wrt the
reference points Point A lost Points D and E
covered by the resin, E recovered, prediction
from B and C D To be recovered Build a new
network of points ?
10
Some investigation done thanks to the CERN
geodesy service, P.Martella and M.Crespi
Underground network of reference points
(C.Scalzini, 1989), connected to outside GPS
points (C.Scalzini, M.Crespi, 1998)
11
Points A-E expressed in the CERN reference
system CNGS beam centered midway in between A and
B Compute the direction AB, compare with the
CERN-LNGS direction CERN-LNGS 98.1 gon AB 98.3
gon Beam angle with respect to hall B axis 3.14
mrad Amazing precision in the construction of the
halls !
CNGS
Evaluation going on for the precise value of the
azimutal angle of the beam, must take into
account the plomb-line deviations with latitude
and geoid shape
12
The OPERA master clock card
PCI cards replacing the old slave clock and
providing the clock system in OPERA Totally
compatible with the LNGS clock system (ESAT
consultancy) Developed at IPN Lyon in
2003 Operative at LNGS since beginning of 2005
PPmS from optical fiber
10 MHz ovenized quartz local oscillator (reset
every ms) almost a Rb clock Allan variance
210-12 over 1s T stability 510-11 0-50 Aging
710-8 over 5 years Master clock signal edge
tracing within 20 ns
13
The OPERA clock distribution system
Time stamp distributed in units of 100 ns to the
detector nodes
The FE electronics works in units of 10 ns. The
DAQ works in cycles of 1 s (up to 256) with a
fine counter of 10 ns. Delays are measured and
subtracted at the nodes levels. The DAQ counters
are cross-referenced with the UTC date stored by
the master card
10 MHz high stability local oscillator
8 Km mono-modal 1310 nm optical fiber
Sync. signal sent every ms (PPmS)
14
Selection of on-time events The selection of
on-time events is performed by comparing the CERN
GPS time-tag of the extraction kicker pulses with
the events GPS date in the DAQ. In order to be
compared the two dates have to be corrected by
various factors 1) Kicker electronics cable
delays (automatically compensated in the CERN
dates written on the database, during the run we
had many problems with this correction) 2)
Particles TOF from the kicker down to OPERA 2
440 079 ns This time was re-estimated by the CERN
geodesy service 3) LNGS-CERN clocks
intercalibration 353 ns (measurement performed
in March-April) 4) Underground time distribution
fiber delay 40993.4 ns measured in July also for
LVD and Borexino 5) DAQ electronics time
distribution delays 4245.2 ns (Measured in
several steps both LNGS and in Lyon)
15
The two (CERN and OPERA) GPS dates are comparable
with a global correction of 2 394 488 ns. The
events selection could be done in a very strict
window of 10.5 microseconds starting with the
extraction time. Due to all the uncertainties
on the extraction kicker precision and phase
during the August run (see later) the search was
performed within a window of 2 ms (-1ms) or
even larger. Performing the search with a 2 ms
window we find events just in a about 10
microseconds sub-window (5-4) with practically no
background around !! In order to see the
background we performed also some test searches
within a window of 100 ms which shows the two
narrow peaks corresponding to the neutrino
extractions plus a flat cosmic background
16
Event selection by using GPS timing informations
Searching events in O(ms) windows just yields a
narrow peak of the order of the spill width (10.5
us) with practically no background O(10E-4)
CR background
17
August 2006 Run1
The run started on August 18th at 1340 and
lasted for 8.5 days (excluding MD), looking at
the CNGS logging database we had beam for 121
hours (5 days) The efficiency of the CERN
machines complex (CNGS) was around 60 (65
corrected for the data losses problem in the CNGS
database)
18
Number of on spill events 161 Before MD (23-24
August) 161 events After
MD (stable timing conditions at CERN) 158
events Total events on time 161158 319

• WARNING
• The 319 events is a lower limit
• There are beam events not correlated with the
  spills due to the data losses in the CERN LHC
  database (about 10)
• 2) The numbers given here are with a Threshold
  at 20 hits, there is an extra 10 of short events
• 3) Before the MD there are also events missed due
  to periods with the GPS off (blackout 1 morning
  DAQ development 12 hours) and a DAQ format
  problem (gt8 events)

19
Beam event
Muon from CC interaction in the material in front
of the detector (BOREXINO, rocks)
20
CC neutrino interaction in the scintillator planes
21

• CNGS Kicker time-tagging story
• Friday 18/8 off by about 100 us due to bad
  accounting of pulse leading edge. Adjusted by 87
  us on Friday afternoon
• Tuesday 22/8 attempt to adjust for other 10us,
  due to a bugged version of the libraries loaded
  by mistake when restarting the system
• Time tag off by about 2 ms
• Friday 25/8 at 1430, after having understood the
  reason of the bug, reset of the 2 ms offset and
  correction of the 10 us which were missing
• Since Friday 25/8 running in stable conditions,
  the time window is very close to zero (like it
  should be since we spent months to calibrate
  everything at better than 100 ns!) there is still
  a little offset to be adjusted 600 ns

22
Time difference of the in-time events with
respect to the closest spill vs time
102 ms
Time difference wrt closest spill ns
Fri, 18 Aug 2006 160927 GMT (Kicker delay
adjustment)
Sat, 19 Aug 2006 064640 GMT
16 ms
2.8 ms
Time (Unix date)
23
Time difference of the in-time events with
respect to the closest spill vs time
Sat, 19 Aug 2006 064640 GMT
Time difference wrt closest spill ns
Clock 1 and Clock 2 were intercalibrated and the
output was de-phased by 140 ns G.Di Carlo in the
replacement did not keep the same optoelectronic
coupler that we calibrated
Power cut switch to Clock 1, then switch back
to clock 2
16 ms
Time (Unix date)
24
Events before the MD (25/8)
Time difference with respect to the closest
extraction for the events on the plateau at 16 us
10 ms
This value should be 5.25 us (average between 0
and 10.5 us) It was measured at the same time
by the CERN people that the Kicker time-tagging
was still off by about 10 us. Expecting to go
exactly to zero delay after having adjusted it
after the MD (25/8)!
25
Time distribution of all the events after the MD
25/8/06
Larger than 10.5 us and off by about 600 ns
26

• Time tagging for the October run
• Other 100 ns recovered, due to a mistake in the
  calculation in the time correction for the
  kicker, time delay reduced to 500 ns
• The run was unfortunately very short due to the
  reflector leak and in about 24 hours we recorded
  just 30 events
• Perspectives for 2007
• CERN (J.Serrano et al.) bought a portable
  (powered with 12 V car batteries) Cs atomic clock
  which will be used to cross-check with an
  absolute time reference all the delays accounted
  in the timing chain at CERN. It outputs a 1PPS
  UTC signal which can be used as reference.
  Confident to understand there the origin of the
  still missing 500 ns. The clock can be brought to
  LNGS to check all the components of the timing
  chain for all the experiments (March 2007)
• Who is interested ?
• At CERN they are looking at how to move the time
  tagging system to the BCT which will be more
  precise and also to set-up a waveform
  digitization system which will record the pulses
  used for the time tagging (1 ns sampling,
  20GB/year) in order to make cross-checks and fine
  tuning on the start and duration of the
  extractions.

27
Neutrino velocity measurement Related to
exotics Lorents violation, extra-dimensions Bes
t limit from a FNAL experiment in 1977
abs(1-beta)10E-4 What could be do with
CNGS The timing system does not allow to
resolve the RF structure of the beam (200 MHz, 5
ns) We do not know when the neutrino was
produced during the 10.5 us of the extraction. So
we have an RMS on the single measurement of 10.5
us/sqrt(12) With 1000 events we have sigma10.5
us/(sqrt(12)sqrt(1000))96 ns Allowing for a
sigma(beta)4E-5 By adding the statistics of all
the experiments in 5 years gt 100K events, 9.5 ns
resolution, Sigma(beta)4E-6 provided we
understand systematics effects and we have a an
absolute calibration of all the
experiments. Possible common publication for the
LNGS experiments ?
28
One event in common with Borexino during the
October run
1 2909 11300 122 1161868864342099968.000
2407.000 Evt 736526 1161868864344498530 332
49997802 4074 Horizontal muon, 4074 ns after
start of second extraction Considering the TOP
of 2440079 ns The event should be at 2440
4.07 2447.07 us Found in Borexino at 2407 us
(before getting to LNGS), 40 us missing 
29
The CNGS-LNGS database

• Needs
• Correlate the events recorded by the experiments
  with the beam spills windows (10.5 microseconds).
  This is done through the UTC times recorded at
  CERN and LNGS T(LNGS)T(kicker)TOF, accuracy
  better than 100 ns. We need the list of spills
  UTC times from the CERN database
• Have online some rough, synthetic spills quality
  informations (intensity, status word)
• Full database of the beam conditions for physics
  analysis and comparison with the beam
  simulations, (e.g. NOMAD) important for
  numu-gtnue analysis
• Record in the beam database the feedback of the
  far (LNGS) beam monitoring muons from neutrino
  interactions in the rock, neutrino interactions
  in the detectors
• Be able to consult at LNGS the beam status, like
  it was done at WANF with a graphical application

30
The CNGS database (ORACLE based) produces 1
TB/day of information, mostly technical and it is
in the hidden accelerator controls network at
CERN (LHC logging database) After a few
meetings among OPERA/CNGS and the CERN Database
people it was decided to implement a new gateway
server (ORACLE) on the public network in order to
exchange the relevant informations among CERN and
LNGS for the data-taking, beam monitoring and
beam analysis The data will be available on the
public gateway about 15 minutes after recording
in the main database The database is structured
per CNGS cycles The server will be bidirectional
in order that also LNGS experiments will be able
to write the events observed in correlation to
the spills (some discussions started in OPERA and
LVD)
31
(No Transcript)
32
WEB page for the CNGS-LNGS documentation
33
First experience in August The gateway machine
had the update time very variable as a function
on the wanted variables (up to 8 hours) and it
was not persistent Two new procedures setup in
order 1) To access the data from the
measurement database almost real-time 2) To
access all the data in a persistent way for
physics analysis New procedure inserted in the
documentation 3) Problem of Data losses
(investigated in several steps in between August
and December Multiple access to vector
numeric variables for the muon pits still missing
34
LHC Database losses at CERN About 10 of clean
neutrino events without correspondence in the
spills database at CERN Either entire spill
missing or many variables missing among which the
GPS times and proton intensities Some
inconsistencies also due to loss of variables
e.g. no signal in the muon pits with protons
clearly hitting the target Problem under
investigation since 21/8. Due to the software
layers affecting all the clients. It general
problem of CERN affecting all the machines
logging now based on the LHC database and the
future LHC logging Beam data are definitely
lost, no independent logging This was indeed a
mixture of different problems which needed a lot
of debugging effort in several steps The
database/logging people attempted to fix the
problem by the October run. Some tests performed
during the two CNGS commissioning shifts
35
De Hermann Schmickler Dear all,   as promised
technical feedback for this problem. What is
important to notice is that the problem was
understood with the best possible delays. The
people working on it have a tight schedule
between several concurrent projects all asking
for the highest priority. During quite some time
we had to reduce the priority for CNGS in order
to assure successful LSS6 extraction and normal
SPS operation.   Cheers Hermann   Below the email
from Marine   I am well aware of the criticity
of this problem for the CNGS/Gran Sasso
Operation. Unfortunately, the identification of
the location of the data loss was not
straightforward and we were not able to fix the
problem before the end of the CNGS Run, also
because we had to deploy a significant effort at
the same time on the LSS6 controls
preparation. In collaboration with BDI experts,
we have started the investigation of this problem
after the LSS6 Beam Run, on Friday 25/8. Last
Tuesday 29/8, we have identified the location of
the loss of the data in the logging package and
elaborated a fix. We did not have time to deploy
this fix for CNGS as the Operation ended on Wed
morning 30/8. We are confident that this fix
will solve the problem and we are now performing
a complete validation. But once again this
activity is performed in parallel with logging
extensions/adaptations which are essential for
SPS and for the TI8 Dry Run held next Monday.
Thus, we can not do progress as fast as we
wish. In conclusion We will do our best to have
this problem solved as soon as possible, and with
no doubt before the next CNGS Run.
36
Dear  Dario , (Marine Pace 29/8/06     We have
identified this afternoon in which part of the
control chain the data got  lost from time to
time. We have one idea of the reason for this
loss but are not completely sure. So we will
prepare a fix and we will test it tomorrow.  If
the fix is successful, we will deploy a new
version of the logging but I doubt we will be
able to solve the problem before tomorrow
evening.   Anyway, as the problem is general and
potentially affects any logging client, we are
putting a significant effort on it. I' ll keep
you inforrmed as soon as I have more news.   Kind
regards, Marine.
37
Dear Dario, (Marine Pace 18/12/06)   I would
like to give you some good news related to the
logging. Here are the latest results of our
extensive tests performed to detect sources
of missing data.   Tests were performed with
CNGS-standard conditions in terms of amount of
data and supercycle 3 CNGS cycles (CNGS1, CNGS2,
CNGS3) . We have discovered a weakness  in the
software which receives data from logging and
actually writes them to the database. This
implies data loss when the device's publishing
rate isvery high (which is the case for CNGS
operation). The responsible person for this SW
as well as for METER and TIMBER databases,Chris
Roderick, has corrected the SW.  Since then,
further tests have been completed successfully
0 loss over more than 20 hours.   The above
improvement will of course not help if we face
data loss due to the lack of publication from the
device or due to an irrelevant data format. In
order to detect in real time these problems, we
are in the process of testing a new facility
which has been added in the device access library
"JAPC"  . This facility allows to detect such
conditions (no publication from device,
irrelevant data format) and to "inform" the
logging accordingly. The logging then writes a
specific value "NO_VALUE" in METER and TIMBER
databases for the corresponding cycleStamp. This
new implementation will guarantee that we will
always have a data logged, either a relevant data
or a NO_VALUE data for each cycleStamp. This will
allow us to do a very accurate post mortem
analysis Please feel free to contact me for
a further explanation. Kind regards, Marine.
38
Dear Dario, (Marine Pace, 13/10/06)   I am
happy to inform you that the preliminary analysis 
of data logged this afternoon during the CNGS Beam
 Run show no holes over more than 1000 values.
Please refer to the attached file for
details. The analysis covered BCT TT40, BCT CBGS a
nd GPS timing.   I hope that the weakness that
we found and corrected in our software has
definitely solved the problem.   Just to remind
you that there are other potential sources of
data loss  (device itself, frontend software,
middleware protocol,..) which could result -at
any moment- in holes of logged data.   I will
continue to closely follow-up this point as soon
as CNGS will restart.   With my best regards,
Marine.
39
CNGS status word (Giulia Brunetti) Flag
accessible from the database summarizing the
quality of the CNGS beam from the measurements
taken at CERN on the beam line Will be useful to
the machine operators and the experiments to have
a quick idea of the quality of the beam during
running From the studies on the beam August data
performed by G.B First technical implementation
for the October run in view of a test for a
precise tuning for 2006
40
STATUS WORD

• WHAT Basic information needed by the
  detector DAQ to understand the beam status at the
  single spill level when the events
  are correlated to the beam timing. Possible
  format
• 0 ? beam present and corresponding to
  specifications
• 1 minor problems present, not affecting
  significatively the beam quality
• 2 major problems, affecting the beam
  spectrum and/or yielding a ?
  flux not corresponding to the pot for
  the given extraction
• 3 No beam should be expected _at_ LNGS
• WHY At level of recorded data we need to
  cross check the beam statistics and quality, can
  be used also in the DAQ monitoring.
• HOW Principal VARIABLES to assess
  the beam quality
• Total Intensities
• Horn and Reflector Current
• Muons
• DETAILS THRESHOLDS
• Extracted pot gt 1012
• Pot measured before target ? check there were no
  major losses
• Currents Nominal value ? ? (5)
• ? normalized value (pot) ? 10 (complicated by
  saturation)
• Beam direction (obtained by the profile in the
  muon pits)

• Beam OK
• Error
• No ?s _at_ LNGS

minor
fatal
41
Charge (pot normalized) measured by the central
detectors of the muon pits
2 ADC bins, constant with time
Variations with beam intensity due to a
saturation effect
42
Hi Edda, (18/10/06) following our phone
conversation here you can find a precise layout
of what we discussed. Of course this is a test
implementation to start with, then we will see on
the October data how it works and how we can
improve it. Regards, Dario and
Giulia ------------------------------------------
---------------------------- The number refers to
the value taken by the beam status flag. 4) Beam
tests (set by the operator) ---------------------
-------------------------------------------------
3) No beam for this extraction (intensity 25
times lower than nominal) pot lt 10E12 OR (mu
central pit1 lt nominal/25 AND mu central pit2 lt
nominal/25) -------------------------------------
--------------------------------- 2) Major beam
problem, OR of the following conditions a) mu
central pit 1 off by more than 20 OR mu central
pit 2 off by more than 10 (the larger value on
pit1 is beacuse of the saturation) b) Horn OR
Reflector currents off by more than 5 c) muon
centroid on pit 1 off by more than 10 cm OR muon
centroid pit 2 off by more than 5 cm (Horizontal
OR Vertical centroids) ---------------------------
--------------------------------------------
43
1) Minor error conditions with respect to nominal
beam values, OR of the following conditions a)
mu central pit 1 off in the interval 10,20 or
mu central pit 2 off in the interval 5,10
(still check for the saturation on pit 1, 10 may
not be safe) b) Horn OR reflector currents off in
the interval 1,5 c) muon centroid on pit 1
off in the interval 1cm,5cm OR muon
centroid pit 2 off in the interval 4cm,10cm
(Horizontal OR Vertical centroids) --------------
--------------------------------------------------
----- 0) No error flag set, nominal beam
conditions ---------------------------------------
---------------------------- In case of data
losses one has to add 10 to the flag value set as
from the above algorith
44
October run Some bugs fixed in the logging
chain the problem was reduced but not completely
fixed. Still some neutrino events without
corresponding spills and missing
variables Extensive meeting in November on the
subject E.S., D.A, G.B, M.GP. To review all the
recorded cases of data losses in the October
run Logging group set up a lot of verification
tools, perfoemd simulated runs and finally traced
the origin of the data losses to a problem at the
level of database (December) The problem is now
considered completely solved.
45
Early warning signal
It is useful to know in advance the arrival time
of neutrinos in order to prepare the DAQ and
prevent operations which could interfere with the
neutrino events recording (e.g. OPERA from time
to time performs calibrations with flashing
LEDs) The next neutrino spill time can be
predicted in advance of several seconds. The
information can be transmitted through the
network
Two fast extractions/cycle 10.5 micro
seconds Separated by 50 ms
EW
Window for calibrations
46

• An experiment like OPERA is continously taking
  data, independently of the beam informations
  (data-base and early warning access through the
  network)
• The beam informations are needed to validate the
  bricks extraction once per day
• 2) The calibrations can be conservatively skipped
  for some time in case the early warning signal
  does not arrive. In case the EW is there the
  calibrations will be performed till a
  conservative window around the neutrino spills
• The transmission of the early warning from CERN
  to LNGS has been implemented and tested since the
  beginning of March by J.Lewis on the OPERA DAQ
  gateway computer
• 1) It is based on UDP packets. The transmission
  time is around 10 ms
• 2) The packets are sent every 1.2 s (all possible
  SPS cycles are multiple of 1.2s which is the
  PS-booster cycle). The packets contain the date
  of the future neutrino extraction. This date can
  be the same for many packets of the same cycle.
  The idea of the 1.2 s repetition is to keep a
  constant rate link among CERN and LNGS. OPERA DAQ
  cycle changed accordingly.

47
3) The DAQ looks at the arrival time of the
packet, compares to the extraction time written
in the packet and decides if there is time or not
to perform calibrations 4) We have to log the
interspill DAQ status in order to know which was
the livetime for cosmics
1.2 s
1.2 s
UTC Time of packet emission UTC time of next
extraction
O(10 ms)
UPD packet_at_LNGS
48

• EW packets emission set-up for a set of machines
  at LNGS and outside
• OPERA (LNGS)
• LVD (BOLOGNA LNGS)
• BOREXINO (LNGS)
• ICARUS (PADOVA LNGS)
• OPERA has fully integrated the EW in the DAQ
  system in order to organize the DAW cycles and
  have also a timing backup in case of GPS failure
• ICARUS wants to use the EW as a pre-trigger for
  the beam events. Ongoing studies for what
  concerns the reliability and delay of the signal
  transmission, will continue next year

49
Status word

• Presentation given by G. Brunetti at the CNGS
  working group 16/10/06

50
STATUS WORD

• WHAT Basic information needed by the
  detector DAQ to understand the beam status at the
  single spill level when the events
  are correlated to the beam timing. Possible
  format
• 0 ? beam present and corresponding to
  specifications
• 1 minor problems present, not affecting
  significatively the beam quality
• 2 major problems, affecting the beam
  spectrum and/or yielding a ?
  flux not corresponding to the pot for
  the given extraction
• 3 No beam should be expected _at_ LNGS
• WHY At level of recorded data we need to
  cross check the beam statistics and quality, can
  be used also in the DAQ monitoring.
• HOW Principal VARIABLES to assess
  the beam quality
• Total Intensities
• Horn and Reflector Current
• Muons
• DETAILS THRESHOLDS
• Extracted pot gt 1012
• Pot measured before target ? check there were no
  major losses
• Currents Nominal value ? ? (5)
• ? normalized value (pot) ? 10 (complicated by
  saturation)
• Beam direction (obtained by the profile in the
  muon pits)

• Beam OK
• Error
• No ?s _at_ LNGS

minor
fatal
51
Muon Detectors Saturation
The muon signal is pot normalized ? it should be
costant
Total Intensity
? It decreases with the proton intensity
Muon signal (charges/pot) PIT1
10 effect
Time
Muon Central Detector Pit1
ANTICORRELATION
Total Intensity
0.4 1013 pot
10
1.7 1013
UP TO 2.4 1013 ?

• Time

(PIT2 not saturated)
52

• Pit1 HORIZONTAL

Charges/pot
Left
Right
Esternal
Internal
Mean 0.2656
2-18
4-16
6-14
8-12
Total Intensity
Detectors Couples
53

• Pit1 VERTICAL

Charges/pot
Down
Esternal
Internal
Up
2-18
4-16
6-14
8-12
Total Intensity
Detectors Couples
54
PIT1 Extr1 MEANS
PIT1 saturated? But the mean
profile doesnt look too much flattened (The
only detectors not saturated are 1 and 19)
55
Magnets

• HORN and REFLECTOR are always ON

HORN
REFLECTOR
56
Horn Current
Reflector Current
A
0,3
0,6
Time
57
Muon Centroid
values
positions
cm
PIT1
PIT2
HORIZONTAL
HORIZONTAL
VERTICAL
VERTICAL
time
58
CORRELATIONS
cm
VERTICAL
?
PIT 1
Mean 0.51650
More sensitive to TARGET vs HORN alignment
PIT 2
More sensitive to BEAM vs TARGET alignment
Good correlation
Mean 1.253
mm
Position _at_ TARGET
Mean 0.02917
Time
59
cm

• HORIZONTAL

Mean 0.09137
No important displacement
PIT1
Mean 0.1091
PIT2
mm
Position _at_ TARGET
Mean 0.4266
Time
60
Vertical
mm
cm
PIT1
Position _at_ target
A
Horn
Anticorrelation?
PIT2
Reflector
time
time
61
mm
Horizontal
cm
PIT1
Position _at_ target
A
Horn
PIT2
Reflector
time
Displacement gt 0 in both cases
time
62
Database loss of muon chambers data? About 1
events with Pit1 and Pit2 zero at the same time
with extraction intensity and intensity _at_
target gt0 (for 90 of these events TBID was zero
as well)
63
TBID
Signal decrease with time as shown by Edda in the
AB seminar
Multiplicity
Time
64
Intensities
pot
After the kicker
A.U.
A.U.
Before the Target
t gt 1156.87 1015
Good correlation after proper threshold
adjustment
pot
Time
65
SPARES
66
SPS Supercycle 16.8 s CNGS cycle 6 s Two
extraction/cycle lasting 10.5 us and separated by
50 ms
67
Extraction intensities as a function of time
Friday 25, restart after MD
1.7E13 pot
Extraction 1
Increase bringing to 70 of the nominal intensity
(2.4 E13) after improvement of PS proton intensity
Friday 18
Extraction 2
Unix time (ns elapsed since January 1st 1970)
68
Integrated intensity (pot) as a function of time
Wed. 30 Aug. 2006 500
TOTAL 7.6 E17 pot EXT1 3.81 E17 pot EXT2 3.79
E17 pot
MD Monday CNGS smoke Detection system problem
2 days MD problems On Friday 25
Fri 18 Aug. 2006 1340
Unix time
Warning some people have the tendency to
remember 3E18 pot for this run. This is an
historical number. CERN refused to give an
official number for this run, unofficially it was
reasonably foreseeable around 1E18
69
October run
About 10 days of beam time (MD excluded)
allocated to OPERA at the last SPSC. Mainly
motivated by the requests of the machine
people. Start 26 October 800 End 7
November 800 SPS supercycle length 39.6s,
containing 3 CNGS cycles (18s), flat top of fixed
target cycle extended by 4.8 s to make a better
use of the protons for COMPASS FT 16.8 s 3
CNGS 18 s MD 4.8 s 39.6 s
70
Radial beam distribution at LNGS Full width at
half maximum 2.8 Km Flat region at - 500 m
CNGS Geodesy
effect on ?t cc events horn off axis by
6mm lt 3 reflector off axis by 30mm lt
3 proton beam on target lt 3 off axis by
1mm CNGS facility misaligned lt 3 by 0.5mrad
(beam 360m off)
Angular accuracy of CNGS direction 0.05 mrad -gt
37 m over 730 Km This uncertainty has practically
no effect on the observed rates Coming to
another problem It is known that the
experimental halls were built in the direction of
the future neutrino beam (apart from the zenith
angle of 3.2 degrres), but with which accuracy ?
(OPERA is aligned at - 5 mm over its length
with respect to hall C axis)
71
WGS84
Geoid more detailed description equipotential
surface corresponding to mean sea level
Note WGS84 can mean both WGS84 ellipsoid WGS84
geoid
72
World Geoid Separation
In Europe the geoid is about 50 m higher than the
ellipsoid
73
Fine details of the time difference evolution (1
measurement/s)
1h
X 102 s
X 102 s