1. Timing and data exchange GPS Timing: Calibrations Results from the CNGS run Perspectives EW and Database D.Autiero/IN2P3 Lyon, 15/1/07

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 (<100 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 LNGS UTC cloks (ESAT) CERN Symmetricom XL-DC unit installed at LNGS

3. 10/3 22/3  t CERN-LGS unit 2 (ns) Time difference measured during 12 days with a time interval counter (300 ps accuracy) Time (s) x 10 3 Warm up plateau Plateau 355 Band of +-23 ns 1 day Time (s) x 10 3 Correcting for the offsets the CERN and LNGS UTC systems were able to track each other within 20 ns (ns)

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 22/3 Measurement 8/3 ns Clock1-clock2 monitored over 13 hours

5. 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 CERN system converged to the following coordinates: N42° 25’ 15.4’’ E13° 30’ 52.9’’ Alt 1037 m asl WGS84 Geodesy 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" N Longitude = 13.5146666666667° E = 13° 30' 52.8" E GPS ellipsoidal height = 1037 (meters) Geoid height = 47.971 (meters) Orthometric 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. GPS antenna GPS receiver Master clock Slave clock(s) External LAB Underground LABs Rb clock 8 Km mono-modal 1310 nm optical fiber Optical signal sent every ms Edge (start of the ms) 80 bits code Date etc …

7. Complete calibration of the time distribution chain: Telecom room Telecom room

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. POINTDistance A730465.4 B730575.2 C730575.6 D730575.2 E730574.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 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 2*10 -12 over 1s T stability 5*10 -11 0°-50° Aging 7*10 -8 over 5 years Master clock signal edge tracing within 20 ns

13. The OPERA clock distribution system Master clock O/E converter Master card 0 Node card i SM2 SM1 1:2 splitter PCI card Optical fiber MLVDS 8 Km mono-modal 1310 nm optical fiber Sync. signal sent every ms (PPmS) Time stamp distributed in units of 100 ns to the detector nodes 10 MHz high stability local oscillator 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

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(10 E -4) CR background

17. The run started on August 18th at 13:40 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) August 2006 Run1

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 161+158= 319 ** ** WARNING: The 319 events is a lower limit 1)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 (>8 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 14:30, 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 Time (Unix date) 102  s 16  s 2.8  s Time difference wrt closest spill ns Fri, 18 Aug 2006 16:09:27 GMT (Kicker delay adjustment) Sat, 19 Aug 2006 06:46:40 GMT

23. Time difference of the in-time events with respect to the closest spill vs time Time (Unix date) 16  s Time difference wrt closest spill ns Sat, 19 Aug 2006 06:46:40 GMT Power cut + switch to Clock 1, then switch back to clock 2 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

24. 10  s Time difference with respect to the closest extraction for the events on the plateau at 16 us 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)! Events before 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: 1)Other 100 ns recovered, due to a mistake in the calculation in the time correction for the kicker, time delay reduced to 500 ns 2) The run was unfortunately very short due to the reflector leak and in about 24 hours we recorded just 30 events Perspectives for 2007: 1) 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 ? 1)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 Best limit from a FNAL experiment in 1977 abs(1-beta)=10 E -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 sigma=10.5 us/(sqrt(12)*sqrt(1000))=96 ns Allowing for a sigma(beta)=4 E -5 By adding the statistics of all the experiments in 5 years > 100K events, 9.5 ns resolution, Sigma(beta)=4 E -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: 1)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 2)Have online some rough, synthetic spills quality informations (intensity, status word) 3)Full database of the beam conditions for physics analysis and comparison with the beam simulations, (e.g. NOMAD) important for numu->nue analysis 4)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 5)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)

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 and 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 WHATWHAT 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 @ LNGS WHYWHY At level of recorded data we need to cross check the beam statistics and quality, can be used also in the DAQ monitoring. HOWHOW Principal VARIABLES to assess the beam quality: :  Total Intensities  Horn and Reflector Current  Muons DETAILSDETAILS THRESHOLDS :  Extracted pot > 10 12  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) RESULTSRESULTS → Beam OK → Error → No ’s @ LNGS fatal minor

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 < 10E12 OR (mu central pit1 < nominal/25 AND mu central pit2 < 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): 1)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. 1.2 s 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 O(10 ms) UPD packet@LNGS UTC Time of packet emission UTC time of next extraction

48. EW packets emission set-up for a set of machines at LNGS and outside: 1)OPERA (LNGS) 2)LVD (BOLOGNA + LNGS) 3)BOREXINO (LNGS) 4)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 WHATWHAT 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 @ LNGS WHYWHY At level of recorded data we need to cross check the beam statistics and quality, can be used also in the DAQ monitoring. HOWHOW Principal VARIABLES to assess the beam quality: :  Total Intensities  Horn and Reflector Current  Muons DETAILSDETAILS THRESHOLDS :  Extracted pot > 10 12  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) RESULTSRESULTS → Beam OK → Error → No ’s @ LNGS fatal minor

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

52. Pit1 HORIZONTAL Charges/pot Total Intensity 2-184-166-148-12 Detector’s Couples Left Right Esternal Internal Mean 0.2656

53. Pit1 VERTICAL Total Intensity Charges/pot 2-184-166-148-12 Detector’s Couples EsternalInternal Down Up

54. PIT1 saturated? But the mean profile doesn’t look too much flattened (The only detectors not saturated are 1 and 19) PIT1 Extr1 MEANS

55. Magnets HORN and REFLECTOR are always ON HORNREFLECTOR

56. Time A Horn Current Reflector Current 0,3% 0,6 %

57. Muon Centroid valuespositions PIT1 PIT2 HORIZONTAL HORIZONTAL VERTICAL VERTICAL cm time

58. VERTICAL PIT 1 PIT 2 Position @ TARGET Time cm ? mm CORRELATIONS More sensitive to TARGET vs HORN alignment More sensitive to BEAM vs TARGET alignment Mean 0.51650 Mean 1.253 Mean 0.02917 Good correlation

59. HORIZONTAL PIT1 PIT2 Position @ TARGET Mean 0.4266 Mean 0.09137 Mean 0.1091 Timecmmm No important displacement

60. Vertical PIT1 PIT2 Reflector Horn Position @ target cm mm A time Anticorrelation? time

61. cm time time AmmHorizontalPIT1 PIT2 Horn Reflector Displacement > 0 in both cases

62. Database loss of muon chambers data? About 1% events with Pit1 and Pit2 zero at the same time with extraction intensity and intensity @ target >0 (for 90% of these events TBID was zero as well)

63. TBID Time Multiplicity Signal decrease with time as shown by Edda in the AB seminar

64. Intensities After the kicker Before the Target Time pot pot t > 1156.87 10 15 Good correlation after proper threshold adjustment A.U. A.U.

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 Extraction 1 Extraction 2 Friday 25, restart after MD 1.7 E 13 pot Increase bringing to 70% of the nominal intensity (2.4 E13) after improvement of PS proton intensity Unix time (ns elapsed since January 1st 1970) Friday 18

68. Integrated intensity (pot) as a function of time 2 days MD + problems On Friday 25 MD Monday + CNGS smoke Detection system problem TOTAL: 7.6 E17 pot EXT1: 3.81 E17 pot EXT2: 3.79 E17 pot Fri 18 Aug. 2006 13:40 Wed. 30 Aug. 2006 5:00 Unix time Warning: some people have the tendency to remember 3 E18 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 1 E 18

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 8:00 End: 7 November 8:00 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. CNGS Geodesy: Angular accuracy of CNGS direction: 0.05 mrad -> 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) Radial beam distribution at LNGS: Full width at half maximum: 2.8 Km Flat region at +- 500 m effect on ν τ cc events horn off axis by 6mm < 3% reflector off axis by 30mm < 3% proton beam on target < 3% off axis by 1mm CNGS facility misaligned< 3% by 0.5mrad (beam 360m off)

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 10 2 s