*********************************************************************** * * * PART 2 PART 2 * * H1 LUMI LOGBOOK * * * * HERA ep-run, October 1991 * * * * * * Use command: F ====== to find all messages, and then select * * those you are interested in * * * To print this part on the logbook put * in the next line: * PRINT 'F11LEV.H1.LUMI.LOGBOOK.AUG91.DEC91' DEST LI1 OVFL ONA NOHEAD * * * S.Levonian Opened: 15/08/91 at 11:00 * * Closed : 31/12/91 at 23:59 * * * *********************************************************************** 15.08.1991 ==================== F11LEV === October logbook is opened This message opens our October logbook. Access to the July information is still possible (but only in browse mode). Use commands LLJ = list 'F11LEV.LUMI.J91.LOGBOOK' to inspect old July logbook LLO = ((edit)) 'F11LEV.PUB.LUMI.LOGBOOK' to update new October logbook It's proposed to work out convenient tabular form to keep all necessary run information for the future offline analysis. This table can then be copied and filled during the data taking, and thus for all runs some standard information will exist. Based on the experience of July run, a preliminary proposal is attached to this message. Please, send your comments, proposals, ideas and think about how to make it more compact and more informative. Proposal for the Run Summary Table to be filled by onliners during October'91 Run ---------------------------------------------------------------------- Header Run number : 6666 Number of events: 25000 Run start: 5.10.91 @ 0:55 Run end: 5.10.91 @ 1:20 ---------------------------------------------------------------------- HERA conditions e- beam: energy (GeV), # of bunches, intensity p beam: energy (GeV), # of bunches, intensity ---------------------------------------------------------------------- Trigger Description: ET & PD & aVC Elements setting: ET = 5...25 GeV PD = 5...30 GeV VC > 0.3 GeV ---------------------------------------------------------------------- Counters VC (kHz) : Veto counter (best estimation of total gamma rate) EC (kHz) : Electron counter ( - " - - " - e- rate) PD (kHz) : Photon fetector ( rate of PD accepted events ) ET (kHz) : Electron Tagger ( rate of ET accepted events ) TC (kHz) : Trigger counter ( total rate of actual trigger ) ---------------------------------------------------------------------- Other info ---------------------------------------------------------------------- 1 17.08.1991 ==================== H01USA === FIRST P-BEAM ............ This night and day there is first p-beam activity. PD - working position Trigger: PD (20); C1/C2(6)= 200/2000 Hz (f.e.) and fall down (0/0) during some minutes or some tens seconds. Very unstable beam. Sometimes 10 bunches (##14-23), sometimes there is almost no bunch structure. Last case there is peak (13 GeV) in WS+PD energy distributions; FWHM = 6 GeV. 19.08.1991 ==================== H1KSOL === HERANEWS message ........ Ferdinand Willeke August 19 1991 MPY Tel 3187 Update on Activities of the HERA Proton Ring ------------------------------------------- Commissioning The main magnet circuit of the HERA proton ring ~~~~~~~~~~~~~ been excited by 3000 A which corresponds to ~500GeV after a difficult start up. A lot of work was left over from the shut down period in May'91 and the quench test runs in June and July. The commissioning of the 8000 A power supply of the main circuit turned out to be more delicate as expected. A ground fault in the current feed throughs of the superconducting reference magnets caused some extra delay. During the technical commissioning period, the pro- ton accelerators DESYIII and PETRAII have been turned on. Operation was somewhat unstable which was partly caused by the unusual high outside temp- eratures in the beginning of August. 40GeV proton beams are beeing delivered to HERA-p. On the last weekend (August 16-18) a coasting beam has been reestablished with a life time of about 5min. This is a good base for further improvements and the preparations for the energy ramping opera- tion in September'91. Planned Access There is no planned access to the HERA ring and the ~~~~~~~~~~~~~~ experimental areas in August and September. 20.08.1991 ==================== F11LEV === Measurements on p-beam .. It would be desirable to perform some more or less systematic studies on proton beam in present stand alone p-mode, of course at relatively stable machine conditions. I even would propose to record 1-2 runs for further offline analysis (5-10-20 thousands of events) for the trigger "Any activity in gamma-arm" which means VC-trigger (may be also another run with VC OR PD trigger). Purpose: - measure VC trigger rates for p-beam (why it is so high even at 40GeV, what then will be at 820 ?) - study energy spectrum both at VC and PD and compare with "typical" e-response (again how it could be 13 GeV deposited from 40 GeV p-beam, where are our 2m of iron shielding? Does it mean that one should expect up to 250-300 GeV of E-dep at real p-beam? Don't believe...) - timing problem: in ep-collision mode we will perhaps detect overlap between e-signal from i-th bunch with p-signal from (i-7)-th bunch; can we really distinguish between them at h/w level, or should we afterwards estimate corresponding correction factor? In last case it would be very important to measure trigger rates for different LUMI triggers already now (in ep-mode it might be too late to do this - not obligatory however, but better to know truth in advance) 21.08.1991 ==================== H1KSOL === Possible access ......... Information from Korbel (BEAMSTAT): Probably access possible tomorrow at 11.00 for unknown time. More news about access not before 21.8. 10.35 in this file.(BEAMSTAT) 1 21.08.1991 ==================== H1KSOL === Work in the tunnel ...... 21.08.91 There was access to HERA tunnel 10.00 till 11.30 . The following work was done: 1. The water in Veto counter was added. 2. The new 6 dosimeters were installed in the following places: #1 - inside ET electronics box. #2 - on the post in front of ET in the plane of e-beam #3 - on the ET in the plane of e-beam near beam pipe. #4 - inside PD electronics box, #5 - on the right side of lead shielding in parking position for PD in the plane of e-beam, #6 - on the PD in the e-beam plane,on the edge near e-beam pipe. 26.08.1991 ==================== H01USA === P-BEAM .................. P-beam: there is some activity with stable bunch structure. Trigger: WV(8); C1/C2=~100/100 Hz (max(start) value). Period - 5-15 min. Life time - 10-120 sec. Number of bunches - 1 (#46). The energy responce from background halo - less then 0.5 GeV (in PD ARM: WS+PD). Trigger: PD(20); C1/C2=~10/100 Hz. The energy responce from background halo - up to 20 GeV (in PD arm - WS+PD),peak - ~7 GeV ( poor statistic). 28.08.1991 ==================== H01USA === P-BEAM .................. P-beam is better: life time is the same, but intensity is more stable (without big fluctuations). Pure bunch structure, precisly in one bunch. 14.09.1991 ==================== H01USA === luminosity monitors ..... Yesterday was meeting on luminisity monitors: Friday,September 13th in building 30 b, 5th floor at 1:00 pm The next persons were present: J.Rossbach MPY D.Kisielewska ZEUS Y.Soloview H1 A.Usik H1 F.Willeke MPY W.Bialowons MPY D.Hassel ZEUS F.Brasse H1 R.Brinkmann MPY Siazychi ZEUS The main topics - what and how HERA people can get information from luminosity subdetectors. The short presentation of posibilities of our detector was made with demonstration different pictures. It was decided that HERA will buy Mac for connection to H1_LAN. We should provide - sending of lumi data from our Mac - software for HERA Mac for displaying this data. On the first step we can send the following lumi data: - luminosity/beam - time dependencies - bunches structure (bunch statistic or/and bunch intensity) - beam profile. There was some discussion: 1.What time is needed for getting sufficient accuracy of luminosity? Accuracy is defined by statistic error - sigma=1/sqrt(N), where N is statistic. For design luminosity we will be have Rate=30 kHz => sigma=0.57% for 1 second time interval. If in October run we will have 5% of design luminosity then sigma=2.5%/sec. BUT 30 KHZ is the rate of lumi event for the trigger with noninteracted photons in veto (water) counter of photon arm. If we will use so called composite detector in this arm (spectrometric channel of veto counter + photon detector) we can reconstruct the energy of any photon in photon arm. The rate for this lumi trigger will be 300 kHz (design luminosity), then for 5% level of gesigned luminosity we will be have sigma=0.82%/sec for this trigger. So we haven't any appresiable delay for getting statistic which provides staistical accuracy of luminosity measurement less then 1%. 1 2. How are you going to subtract background from residial gas for getting pure e-p luminosity? We need to have empty proton bunches (f.e. in the simplest case - two electron bunches and one proton bunch). Then luminosity ~= ie1 * (ip +i(residual gas)) - ie2 * i(residual gas), where ixx - "intensity" of xx . So we need to have two scalers, one - for common luminosity, one - for luminosity on residual gas (we can send to HERA also the last data for monitoring gas condition), then we subtract one from another. The question is that the intensity of different electron bunches (ie1,ie2) schould be equal. If this difference will be not more 10% (Brinkmann) and contribution of luminosity on residial gas equals to 10% (Levonian - estimation for nominal conditions), then this difference will provide the error in luminosity measurements = 1%. In opposite case we need measure relative intensity of electron bunches (is it possible to get this information from HERA ?). For filling of histograms (f.e. beam profile) we should not use events from electron bunches which collide with empty proton bunches, (the numbers of this bunches we must know in advance); within the rest statistic we cannot of coarse separate events on protons and on residual gas. What we can do - it is only to get the same histograms for events on residual gas and then subtract one from another. 3. Signals from HERA. To protect our detectors from radiation damage we need keep them at working position only during normal run of HERA (not during beam dump or injection). It concerns also some another subdetectors. We don't mean casual increasing of background - it is not possible of coarse to predict it in advance, but about situations which depend on "wishes" of HERA operators we could be informed in advance. This delay must be not less one minute (moving time of our detectors from working to parking positions = 40 sec). For us it would be convinient to have one signal (high level - working position, low level - parking position) and to get it from our Central Trigger as another HERA signal, f.e. HERA_Clock signal. It was decided to discuss this point with experts. 15.09.1991 ==================== H01USA === Proposals ............... Extra requiments to trigger in October e-p run: ----------------------------------------------- Now during p-run (when energy is only 40 GeV) we observe some rate in water counter from proton beam halo background. Later during nominal work of HERA we'll estimate the rate and energy contribution from proton beam halo background in photon arm. But it is clear now that we need reject events with the energy contribution from proton background. From /1/ we know that PD detector is placed quite non-optimal: signals from photon and proton background coincide in time. But we can try to account for different directions of photons and proton background using something similar to time-flight technique for water counter and PD. In addition from experiance of July e-run it will be very useful to have in trigger card of Lumi monitor the separate branch for spectro- metric channel of Water counter. It's useful f.e. for selection events with big energy deposition in Water counter. When we work with ET trigger only and low threshold we have false triggers from therm or another noise. It will be more essential for original ET detector (49 channels). So it will be very useful to use majoritar scheme with n>= 2 or coincidece with additional scintilator counter(150x150 mm**2) placed before ET. Energy and beam monitoring: -------------------------- When our detectors are placed in parking positions, we have only water counter in photon arm and nothing in electron arm. In addition we haven't possibility to do any energy measurements. If we'll install behind original detectors simple detectors on max of shower (one is ready - Rusakov) we'll decide both problems. 1. LPI report No: 31-90. 15.09.1991 ==================== H1KSOL === Remark to above message . "If this difference will be not more 10% (Brinkmann) and contribution of luminosity on residial gas equals to 10% (Levonian - estimation for nominal conditions), then this difference will provide the error in luminosity measurements = 1%." - copy from previous message. The previous statement is correct only for nominal condititon,but for October run,for instance,when we will have only 5% of luminosity, the contribution of residual gas will be 50% or more depending on proton beam intensity and pressure and composition of residual gas. 1 17.09.1991 ==================== H1KSOL === Access in HERA tunnel ... Yesterday, 16.09.91 there was access in the tunnel all day. E-tagger was turned on 90 degree and now the layers of this detector are placed vertically.The center of sensitive area of detector is on distance 129 mm from electron beam pipe wall,or 160 mm from beam pipe axis,or 168 mm from electron beam axis.In other words approximately in the same position as in Juli Run. The height of the center of ET is now 41 mm higher then in Juli Run. The signals from ET were observed directly on cables connector in r.101 by oscilloscope,because there were no signals on front connector of FADC except of two (1-t and 5-th). Were are electronics HardWare experts?... The present geometry of ET: Layers # e-beam ------------------------------------ ! ! ! ! ! ! ! ! + ! ! ! ! ! ! ! ! +++++ ! 0 ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! + ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ------------------------------------ The view down e-beam 17.09.1991 ==================== H01USA === Calculation of e-p lumi . (In addition to 14.09.91) More precisly about error of luminosity measurements in e-p run. sigma(L) = ((Ne1 - Ne2)/Ne1) * Rrg/Rp, where Nex - number of electrons in bunch x, Rrg/Rp - relative out on residiul gas and proton bunch for one electron bunch (design value = 0.1). (Ne1 - Ne2)/Ne1 =< 0.1 (Brinkmann). So for design luminosity we have sigma(L) =< 1%. If out on residiul gas and proton bunch are equal, then sigma(L) =< 10% for supposed 5% intensity of proton bunches in October run we will have sigma(L) =< 20%. We cannot measure Rp (in Rrg/Rp) in direct way. We will measure R1 and R2- outs (rates) from first electron bunch on proton bunch and residual gas (R1) and second electron bunch on residiul gas (R2). Then we should use modification formula for error of luminoisity measurements: sigma(L) = ((Ne1 - Ne2)/Ne1) / ( (Ne2/Ne1)*(R1/R2) - 1) = 1 = sigma(Ne) * ----------------------- Ne2 R1 --- * -- - 1 Ne1 R2 17.09.1991 ==================== H01USA === P-beam .................. We observed high activity on beam monitor during announced 62 GeV proton beam: duration - some minutes; Rate,max- 10 000 Hz (!) instead of ~100 Hz in previous month; trigger - water counter. 23.09.1991 ==================== H01USA === P-beam .................. The high activity on proton side. The best result at 16.00: duration - 30 min (some continuous injections - one after another through some minutes), 2 bunches,the rate - from 10 to 300 Hz. Trigger - the same (water counter, threshold=8). 24.09.1991 ==================== H01USA === P-beam .................. Proton side: the best result at 7.31. Duration - 18 min, two injection (8 and 10 min ), two bunches, rate - from 1000 (after injection of two bunches) to 10 Hz (dump). 1 30.09.1991 ==================== H1KSOL === Movable platforms ....... It proves a wrong connection of power supply was done last year. Namely,the phases L1 and L3 were mixed. As a consequence of this we have a serious problem with tables when we have tried to switch them over other source of power to exclude the crosstalk on VME. After checking it was founded that phases L1 and L3 in r.101 are connected to the rack with steering boxes in a wrong way. Therefore,when we wanted to move table up it went down and stopped in abnormal way,namely by support construction.Now we only have to wait an access to the tunnel to estimate a scale of disaster and to repair the platforms. The project for movable platform has a protection from this case, program stop the movement when the platform is intented to move in a direction but it moves in other one. So it is not recommended to move platform by hand if some conditions were changed! Use only project program!!! 07.10.1991 ==================== H1KSOL === New pedestals algorithm.. After including a new algorithm - namely: negative values of FADC counts after subtraction of first bin are kept till getting the linearized responce of one channel of a detector - and testing it on data of July Run the following conclusion can be made. 1. Old algorithm gave us an additional shift in total reconstructed energy in both detectors. The value of this shift is of order 300 Mev. 2. Both calibration algorithms (S and U) shows a increasing of CC for ET of order 2-5% in each channel. The CC for PD are practically unchanged. 3. But a huge low part in energy spectra for PD (or ET)-trigger did not disappear,it was only shifted to zero by value about 200 Mev for ET. 4. The difference between S and U calibration is now smaller then earlier by value of 15-30% depending on the Run number(conditions). Moreover,reconstructed bremsstrahlung spectrum (in particular run 5413) is fitted much better to Bethe-Heitler than earlier and both S and U calibrations show practically the same results. Finally-now it is clear that this new algorithm should be included in online program.Only the negative values for FADC bins should be kept, if the energy responce of one channel is negative it should be equal to zero. This is,may be, the question of offline program,now it is not adapted for this case. It is very important for base detectors, course the number of channel will be much more than for alternative ones. The question of negative energy values for one channel should be investigated for base detector,now,for AD no changes were observed, when the negative value for one channel was kept. For those who would like to continue study with row data in F-banks: you can use for calibration package a load library 'H1KSOL.LUMI91.LOAD' an example of job is in 'H1KSOL.LUMI91.S(#LUCAS)'. It seems to be not necessary to include subroutine LUSER1 in CMZ file and LOAD library because it is important only for July Run Data. S/R LUSER1 makes the linearization, pedestal subtraction and a new E-banks by using the information from F-banks. For analysis package you can use both H1KSOL and F11LEV LOAD libraries. An example of job for analysis with F-banks you can find in 'H1KSOL.LUMI91.S(#LUANS)'. 09.10.1991 ==================== H1KFOM === New OnLine Program ...... As You know during July 91 e-run it was appeared the problem with working of the OnLineProgram together with H1CDAQ if You are using the starting option parameter "DEEPNESTING" with values more then 1. Using of 2 - 8 values of DEEPNESTING parameter creates the posibility decrementing of the lost events (so called Overflow situations at the L2Keep subroutine). At our community this problem is familiar as problem of "appearing of red buffers at H1CDAQ". The reason of appearing of the red buffers was at the phylosophy of the stack processing of the events - namely the time period between MEBREQ call and MEBREADY call must be not very large. It was proposed the realization of FIFO-ideology for OnLine processing of the events for struggle with this large time period. The new version of the OnLineProgram is appeared now with posibility of working with DEEPNESTING = 8 only and only with MODE 1. First tests without H1CDAQ shows good and stable result. There is problem of working with other MODE value (2-10) and low values of DEEPNESTING (1 - 7). Problem is under studying. 1 09.10.1991 ==================== H1KFOM === Soloviev's Algorithm .... Today it were changed the ProcessingET and ProcessingPD subroutines at the H1LUMIOnLineProgram. It were made two correction at each subroutines: 1) it was deleted the finding of negative result after substraction of the first bit value (the pedestal) from values of rest 9 bins and replacing negative result with zero; 2) it was included the finding of negative result of sum of 9 previous substraction results and replacing negative result with zero. The new version of OnLineProgram is working faster (up to 20%). 11.10.1991 ==================== H01USA === p-beam background ....... This night up to 3 o'clock HERA worked on the request of Veto Wall people in the next mode: injection, ramping to 70 GeV, keeping this energy some time, ramping to the next energy, keeping ... and so on up to 480 GeV (see F21TST.H01.OFFLINE.S (OK10/11) ). It was good posibility for investigation of proton halo background. Trigger - Water counter (threshold on veto channel - 8). During first attempts the crashes of FIC programm are observed correlated with beam dumps. Then HERA worked stable. Results: injection - 100 Hz, then decreasing up to 2-8 Hz, some ramping (?) - 1000-100 Hz during one minute, then 1-2 Hz and increasing up 2-12 Hz for 480 GeV. The ramping to the next step of energy was slightly observed. Intensity - 164 uA/bunch = 25% of nominal. # of bunches - 1. Intensity(time) graphics are available in H1 control room. FIC PROGRAMM HAS STOPPED AGAIN DURING INJECTION - JUMPS OF POWER? Serge - how to install MIX option on default? As result the reading of revolution counter in output register stops - no L1-keep for transfer new value ==> beam data are recorded in DPM without revolution time. It is not very good. Comments: estimating the rate from proton halo background for nominal intensity and 220 bunches as 10 kHz we will have the rate of random coincidence with the lumi event 0.2 % ( 2 * 10**4 * 10**(-7) ). 14.10.1991 ==================== H1KSOL === Movable platforms ....... The movable platforms are operated now. During today access to HERA tunnel they were repaired,adjusted and tested. The working position for ET platform is 384.00 (for been turned ET ), for PD platform - 378.00. But during measurments of profile of bremstrahlung by PD keep in mind that the accuracy of our installation of PD is of order 1 mm. For instance it can turn out that PD was installed 1 mm higher than e-beam plane. Keep in mind also that the max.value of position of both ET and PD platform is only 5 mm higher than the working positions for both. So dont try to move them much higher than this values because this movements will stops by end-switch-off. 20.10.1991 ==================== H01USA === First ep-collision ...... At Wednesday 16 October was the meeting on luminosity monitoring. It was decided for measuring luminosity to have two bunches (#1 and #21), first of them must collide with p-bunch. Because of delay with delivery of Mac LC for HERA control room it was decided to use temporary the Mac from H1. Next day with the help of Erwin Deffur one of his Mac's (H1Home2) was installed at HERA control room and connected to H1 LAN communication. After this we started testing of our software for spying H1Lumi data from HERA control room. Now we have in HERA control room the following lumi data from H1Lumi subdetector: - lumi/beam intensity monitor: 3 graphics of time dependency of lumu/beam data for the last 10 minutes ( usually it's rate from veto channel of water counter and rate of luminosity trigger). - X,Y projections of photon beam profile on the face of photon detector. Next day and night we waited first ep-collision, but ... At last at Saturday, 18 October our Lumi monitor in HERA control room was used for tunning e-beam (on the base profile information) and at 18:54 for luminosity measuring when the first collision of one e-bunch and one p-bunch was done. It was fixed by observing increasing of luminosity trigger rate ( ET&PD ) from ~ 2.5 Hz to ~ 5 Hz. This data were recorded in 'data base' of H1Lumi subdetector. 1 Calculation of observed luminosity from logged data (at DPM of H1Lumi subdetector): The rate on residual gas - (2.49 +-2% (sigma)) Hz The rate on residual gas + proton bunch - (4.80 +-6% (sigma)) Hz (first minute of ep-collision) ==> Luminosity trigger rate (PD&ET) - (2.31 +-13% (sigma)) Hz Luminosity trigger rate for design luminosity - 300 kHz Proton bunch intensity - 7.8 % from design value Electron bunch intensity - 5.5 % from design value Electron energy - 12 GeV Proton energy - 480 Gev Cross section + acceptance for 12x480 beams - 0.88 (relatively 30x820 beams) (from Levonian's calculation) Correction for one bunch - 1/210 Ratio of emittances - 25/47 ( from HERA logbuch ) Gamma correction - 512/874 Design luminosity - 1.5 10**31 sm-2 s-1 ===> correction to design luminosity - 0.593 10**-5 So expected luminosity = ( 0.89*10**26 +-30% ) sm-2 s-1, measured luminosity = ( 1.02*10**26 +-13% ) sm-2 s-1. 21.10.1991 ==================== F11LEV === Luminosity calculation .. Basic formula for luminosity m e a s u r e m e n t is trivial: R(Hz) = L(cm-2s-1) * sigma(cm**2) where R is lumi trigger rate and sigma is corresponding cross section. For Lumi trigger used in Oct-19 measurements (ET & PD) accepted brems- strahlung cross section at 12 Gev e- scattered on 480 GeV protons were calculated (using for ET and PD acceptances our best guess - H1SIM): sigma = 23.0 +- 0.9 mb giving L = 2.36/23.0 * 10**27 = 1.03 * 10**26 cm-2s-1 Of course, for different beam energy and different trigger conditions estimation of accepted cross section will be different; accurate calculation needs rather long simulation jobs (of the order of 30 min per each condition at IBM 3090). However, it seems that beam energy dependence is not too strong: sigma accepted at nominal conditions = 31 mb, and this is easely calculatable. Much more important compared to energy, is real beam tilt leading to the limited geom. acceptance of PD and changing also ET acceptance. E.g. horizontal tilt of 0.2 mrad could decrease overall LUMI acceptance on 25% at the same beam energies. Therefore, one MUST provide beam profile information for each run to be used later on for correction factor calculations... 21.10.1991 ==================== H1KFOM === Again about lumi......... Using memory dump from our DPM we got life time of first ep-collision: Measured Rate of ET&PD trigger N,events Time,sec First minute - 4.8 Hz +- 6.0 % 270 56.2 Second minute - 3.7 Hz +- 6.7 % 220 59.3 Third minute - 2.6 Hz +- 8.0 % 155 60.1 Rate on residual gas - 2.49 Hz +- 2.0 % 2780 1116.0 22.10.1991 ==================== H1KSOL === RUN # 9017,9019-9022 .... Run # 9017 21.57 - 22.17 Test of online programm FIFO. Trigger SumET * SumPD Thresholds -13/5 ,Rates - 50/5 Nevnts = 733 Run # 9019 01.19 - 01.51 Trigger = SumET * SumPD, Thresholds - 13/5 Rates - 100/15,after 10 min. - 40/5,after 8000 ev - 300/40 Electron energy = 12 GeV, Nevents = 35308. Run # 9020 Trigger - Veto Thresholds - 13/5, Rates - 350/280/80, Nevents = 18402 Run # 9022 07.15 - 07.35 Trigger - Veto, Thresholds - as in run 9020 Rates - 80/80/50, E = 12 Gev. # of bunches -22, but with very different intensity (two order). 1 21.10.1991 ==================== F11LEV === Bad news ................ As I realized few days ago, an old LUMI geometry was used for ET acceptance calculation for L calculation at Oct'19. A new LUMI text file with correct geometry is lost and I have to recreate it. Therefore, don't take value of 23+-1 mb for Oct'19 data seriously. It should be approx. 15-20% more and thus L estimation should be less. Another observation: reconstruction algorithm for ET is bad or incon- sistent with detector properties. This may have very serious consequen- ces for future: can we believe for our simulation results for KRS with this respect? Fortunately, it does not influence too much present PD reconstruction results which are used for beam monitoring. However, the problem needs detailed study! 25.10.1991 ==================== H1KSOL === RUN # 9022 .............. Run # 9022 has been copied to H1KSOL.LUMI91.CRT09022. 29.10.1991 ==================== H1KSHE === New Trigger possibilities 1. New trigger module is inserted in LUMI system. Main function of this module is monitoring the varios triggers for each bunch and selected run conditions. The max. number of the simul- taneously monitored triggers is 32. a) Short logic description There are 5 boolean logic signal inputs for selecting relevant group of 220 scalers. Total number of signal combinations for these 5 inputs is 2**5 = 32, so we have 32*220 = 7040 scalers (real number of scalers is 32*256 = 8192, but because of 220 bunches, not all of them are used). Each scaler within one group is selected by relevant bunch number. In short we can have 32 histograms with 220 channels for each of them that will simultaneously be filled during HERA run. b) Technical features -VME access to each counter: read and write(preset initial value) -Trigger access rate is ~10 Mhz(HERA-Clock),so no dead time. -Possibility to mask through VME each of 5 trigger inputs. -VME control for start and stop counting all scalers simultaneously. -Capacity of each scaler is 2**25 i.e. ~33 Mcounts. (For luminosity trigger the overflow time is 33*10**6 / (3*10**4 / 210) ~ ~ 2*10**5 sec. ~ 60 h. c) Remark: No dead time feature of this module can be very useful to measure not shifted relative luminosity for each bunch especialy for high rate monitoring events. To explain this one simplified example can be shown: Say, there are two filled bunches only along HERA ring: a first bunch (b1) and a followed through N*96 ns. second bunch(b2) For events generated by these two bunches during one HERA revolution period (96ns.* 220) there are four combinations: 1. No event 2. An event generated by first bunch (b1) (suppose event rate Fb1) 3. An event generated by second bunch (b2) (suppose event rate Fb2) 4. Two events generated by b1 and b2 (double event rate Fd) The last event rate component will be the same for both bunches, so, total event rate is: Ftot = Fb1 + Fb2 + 2*Fd, and the rates separately for each bunch are: Fb1tot = Fb1 + Fd Fb2tot = Fb2 + Fd there Fd = Fb1tot*Fb2tot*(220*96ns.)/10**7 Now, if we suppose that the trigger dead time greater then time betweeng these two bunches (N*96ns.), the following estimations for relevant trigger rates can be writen: Ftr.b1 = C(Fb1 + Fd*(220-N)/220) Ftr.b2 = C(Fb2 + Fd*N/220) there C = (Tdead*Ftot + 1)**-1, C- dead time factor, Tdead- dead t. (expression for C is valid in case Tdead > (Ftot)**-1) 1 As seen from above the double event component will give equal contri- bution for both bunches in case of N = 110 only, so, for not uniform distribution of filled bunches along HERA ring trigger dead time can be cause of shifted relative luminosity value for selected bunch. For low rate events (I mean the main H1 triggers), of course the not shifted each bunch luminosity value is needed. The idea may be not new I don't know exactly, but I'd like to say, the dead time problem for fast luminosity measurements may be not so trivial. d) First using, future using It seems to me for this moment should be interesting to look at the correlation between PD,ET,VETO counters for filled and empty bunches. In this case we will have 8 histograms for varios combinatitions from PD,PD#,ET,ET#,VETO,VETO# entries. Next steps can be fast estimations efficiency for varios triggers and so on... Which triggers will be selected as the entries in future should be discussed. It is clear for me now,that one entry should be kept for L1Aktive signal (Time of activity L1 trigger level). 2. Suggestions for trigger BOS banks structure. First of all it is suggested to have trigger BOS bank with the sta- tus of current trigger for each event. In this case there is a possi- bility to change trigger logic (not threshoulds!) during run. This can be useful for collection varios low rate event components when the run conditions are constant. Not so bad if this bank will contain the main trigger elements that formed the final trigger like an analog summing rezults, cluster finder solution, current map of hit rates on detector faces, and of course current total luminosity value and luminosity associated with given bunch number. Suggestion 1 for data structure in trigger bank (name-?): ------------------------------------------------------------------ Header ------------------------------------------------------------------ D a t a B l o k Content |Format| Word Comments ! !Number -----------------------------!------!------------------------------ Total luminosity scaler | | |These 8 words must be Hihg order 16 bits | B16 | 1 |readed before the Front- Low order 16 bits | B16 | 2 |-end Ready have beeng | | | sended Sel.bunch luminosity scaler | | | Hihg order 16 bits | B16 | 3 | Low order 16 bits | B16 | 4 | | | | Local Time scaler | | | Hihg order 16 bits | B16 | 5 | Low order 16 bits | B16 | 6 | | | | Luminosity and Photoproduc. | | | branches triggers, masks. | B16 | 7 | | | ! Cluster finder solutions | | ! for PD and ET | B16 | 8 _! | | Topological trigger, LUTs | | filling ID, masks | B16 | 9 | | _ PD analog summ value | B16 | 10 |These information comes ET analog summ value | B16 | 11 |directly from FADCs,so PD+ET analog summ value | B16 | 12 |can be omited in case of VETO1, VETO2 | B16 | 13 _|time problems. | | Current hit rate map for PD | | 13 words |B16*13|14-26 ! | | ! Current hit rate map for ET | | ! 25 words |B16*25|27-51 ! | | ----------------------------------------------------------------------- Contents of total number of scalers should be included in End of Run record, but current value selected scaler group can be useful during run also. 1 Suggestion 2 for data structure in Hard_Hist bank1 (name-?): ----------------------------------------------------------------------- Header (Nrow = any from 1,2...32 ; Ncol = 441) ------------------------------------------------------------------- D a t a B l o k Content |Format| Word Value ! !Number -------------------------------------------------------------------- | | No.of scaler group,masks | B16 | 1 bits 12-8 No.of group | | bits 7-0 masks First bunch scaler | | Hihg order 16 bits | B16 | 2 Low order 16 bits | B16 | 3 . . . . . . . . | | . . . . . . . . . | | | | | | 220 bunch scaler . | | | Hihg order 16 bits | B16 | 440 | Low order 16 bits | B16 | 441 | ------------------------------------------------------------------- ------------------------------------------------------------------- . . . . . . . . . . | | | | ------------------------------------------------------------------- . . . . . . . . . .. | | ------------------------------------------------------------------- | | No.of scaler group,mask | B16 | 1 | | First bunch scaler | | Hihg order 16 bits | B16 | 2 Low order 16 bits | B16 | 3 . . . . . . . . | | . . . . . . . . . | | | | 220 bunch scaler . | | Hihg order 16 bits | B16 | 440 Low order 16 bits | B16 | 441 ------------------------------------------------------------------- Format B16 was selected becouse most of data are readed through standart VME access. 01.11.1991 ==================== F11LEV === Luminosity calculation .. 1) New geometry description for the final LUMI setup in H1SIM program has been recreated. Using this data I calculated our present ET acceptance for different beam energies. For example, at 30*820 GeV 6 < E(e- accepted) < 21 GeV for lumi e- 6 < E(e- accepted) < 22 GeV for photo e- Shift of high limit from previous 24 to 21 GeV is mainly due to the fact that exit window is situated at -27.3 m instead of -29.5 m as it was assumed before. 2) I am going to perform a lot of calculations in order to a) estimate systematic errors for different LUMI triggers (ET, ET & PD, ET & PD & aVC) b) estimate background (rate, E-spectrum, x-distibution) at ET from the bremsstrahlung on residual gas from a full beamline (0 - 30m) Some of the preliminary results are already available. 3) In the table below several numbers of common interest are given. Notations used: sig(ET&PD) - accepted cross sections for the trigger ET & PD sig(VC) - cross section corresponding total Veto Counter rate In order to estimate luminosity one has to use the following relation (remember that 1mb = 10**-27 cm**2): L(cm-2s-1) = R(Hz)/sigma(cm**2) where R is pure ep-collision rate (Rtot - Rbgr). ------------------------------------------------------------------- Beam energies sig(ET&PD), mb sig(VC), mb R(VC)/R(ET&PD) ------------------------------------------------------------------- 12 x 480 21.5 +- 0.8 186 +- 5 8.7 +- 0.4 26 x 480 22.7 +- 1.0 238 +- 6 10.5 +- 0.5 30 x 820 24.9 +- 1.1 260 +- 6 10.4 +- 0.5 ------------------------------------------------------------------- 1 In the last column a ratio between single VC rate and a rate of (ET & PD) coincidences is given, as predicted by Monte Carlo simul. You can compare this with the ratio of 2 curves on your online Mac monitor (but only for VC/ET&PD, not VC/ET&PR&aVC). 4) Important remark. ----------------- As MC study of ET-arm shows, there should be quite a big background at low energies. Therefore, one has to apply Ecut at least 4 GeV in order to get more or less correct ET-spectrum. Such a cut was used for the determination of the sig(ET&PD) in the table above. If no cut is applied, then total energy spectrum will have two maxima (lowest would correspond to the coincidence between photon and e-, which lost some energy in the material before hitting ET). In our final trigger using total energy requirement this will be taken into account automatically, but in the current run...? Recommendation: during the ep-collisions always keep an eye on the --------------- total energy spectrum. If there will be 2 peaks - then it would mean a presence of low energy back- ground at ET. In such a case numbers from the sig(ET&PD) column are not applicable for the L de- termination! 5) In multi-bunch regime it would be important to measure relative e-bunch filling independently on HERA machine. This is necessary for the correct subtraction of the residual gas background. In order to do this, one should record somehow (online, offline, by hand...) so colled "bunch structure" in a stand alone mode (only e-beam) before ep-collisions. Thus, we are interesting to have the following scenario: a) first e- beam is injected and accelerated to the final energy b) at this moment we perform our usual measurement on the res.gas. (VC counts for each bunch) which gives us relative number of Ne in each bunch (at nominal conditions 10 sec measurements will provide estimation within 1% error) c) after that p-beam is injected, accelerated and finally d) we measure our trigger rates in colliding mode. For more details concerning present note, please consult me. S.L. To I (or E?) Shaviakov: ----------------------- Please consider the possibility to participate in restricted meeting in Wedn. morning (Nov 6-th) concerning our present trigger possibili- ties (Eisele, Straumann, DeRoeck, Korbel, me, you). Be prepared to the questions in the spirit which we discussed alredy briefly. 03.11.1991 ==================== F11LEV === Data for offline analysis I propose the following program of the data taking for offline analysis This should be done only for the E(e-) >= 26 GeV, for the 12 GeV you may continue study online. Also for recorded data please, use minimal mode (without ET/PD F-banks) You can scale down number of required events in case of very low rates. Note however, runs with less then 3-4K events at the same conditions are in general useless... Stand alone e-beam mode (e-gas bremmstrahlung) ---------------------------------------------- 1) Pure LUMI trigger (ET&PD&aVC) = 20.000 events 2) The same without VC (ET&PD) = 20.000 events 3) OR-trigger (ET.or.PD.or.VC) = 120.000 events 4) The following chain (in one go): ET only (20K) -> ET&(PD.or.VC) (20K) -> ET&no(PD.or.VC) (10K) -> ET only (20K) 5) ET only with different lower thresholds (calibration of threshold) ep-collision mode ----------------- 1) VC only = 50.000 events 2) ET & PD = 10.000 events 3) ET & PD & aVC = ??? depending on the trigger rate It is important to keep as stable conditions as possible, at least within each of above modes (don't change HV, timing etc. unless it is really unavoidable!). If you need to align counter's response - do it before data taking. Fomenko, are you able to transfer c.c. in Run Start Records? Should i expect new trigger banks from online? 1 04.11.1991 ==================== H01USA === Once more ep ............ Yesterday (03.11.91) second and third ( with half ) ep-collisions were happened. Time Ie,**10e Ip,uA Rl.t,Hz Rwc,Hz Rlum,Hz l.t.,min * #2 19.27 0.5 30 3.5/6 25/42 2.5 7.0 #3 22.59 0.7 100 6.7/22 15.3 1.1 ** #3.5 23.03 0.7 60 6.7/13 6.3 >6.0 Ie,Ip - intencities of electron and proton beam Rl.t. - lumi trigger rate Rwc - rate from water counter Rlum - luminosity rate l.t. - life time of ep-collision */ before collision / just after collision **/ with the same proton beam, 2 minutes later Ee = 12 GeV Ep = 480 GeV Using last Levonian's data (see previous message) for brems cross- section ( taking into account geometrical aceptance of H1Lumi subdetector ) we have for luminosity: #2: ( 1.2 * 10**26 +/- 4% ) cm-2 sec-1 #3: ( 7.0 * 10**26 +/- 2% ) cm-2 sec-1 #3.5: ( 3.0 * 10**26 +/- 4% ) cm-2 sec-1 (statistical errors are showed ) 04.11.1991 ==================== H1KFOM === Run 10050 ............... Run 10050: --------- Trigger: SumPD & SumET Thresholds: 199/13 (PD), 199/12 (ET), 8 (WaterVeto) Counts - 2-3/14-50 Trigger/WaterVeto. Number of events - 2769. Start of Run - 04.11.91 at 22:11. End of Run - 04.11.91 at 23:02. At this Run must be found the new BOS-bank: LRTF (Raw data from Trigger Sums - SumPD, SumET, and SumPD+SumET. Format B16 ( as at banks LREF and LRPF, but number of bins at each window - 22). The last 200 events were with 26.6 Gev energy, befor this events - energy of e-beam was 12.0 GeV. At 22:31 p-beam current was 181 mkA, number of particles at e-bunch was 0.308* 10**10. It seems that this Run is not needed. 05.11.1991 ==================== F11LEV === Lumi measurement data ... Did you check, whether single VC rate is consistent with ET&PD coinci- dence rate (see last column in my previous table)? What was e-beam energy, Usik missed this important point... 05.11.1991 ==================== H01USA === Once more ep ............ This night (05.11.91) first ep-collisionswith the Ee = 26.5 GeV and Ep = 480 GeV was observed. Firstly the collision for ZEUS was done, then - for H1 with the same beams. For electron beam energy Ee = 26.5 the life time of proton beam is more then some hours, so it was possible. Zeus started with record proton beam intensity 176 uA, we continued only from 109 uA (tonight was very long tunning procedure - the size of proton beam: 0.3 x 0.3 mm**2, the scanning region: 10x10 mm**2). Time Ie,**10e Ip,uA Rl.t,Hz Rwc,Hz Rlum,Hz l.t.,hours * #4 3.00 0.72 109 12/32 150/300 20 ~6 1 Ie,Ip - intencities of electron and proton beam Rl.t. - lumi trigger rate Rwc - rate from water counter Rlum - luminosity rate l.t. - life time of ep-collision */ before collision / just after collision Using last Levonian's data (see previous messages) for brems cross- section ( taking into account geometrical aceptance of H1Lumi subdetector ) we have for luminosity: #4: ( 8.8 * 10**26 +/- 2% ) cm-2 sec-1 (statistical error is showed ) N.B. Serge - the value for the last column - 9.4, but keep in the mind that electron beam energy was 26.5 GeV instead of 26 GeV , wich you used for simulation. 05.11.1991 ==================== H1KSHE === Run 10071 ............... Run 10071: --------- Trigger: SumPD & SumET Thresholds: 199/13 (PD), 199/12 (ET), 8 (WaterVeto) Number of events - 146083 Start of Run - 05.11.91 at 01:34. End of Run - 05.11.91 at 03:55. For this of the first time real luminosity data record the events can separated in two main groups. The first ~57000 events was recor- ded without e-p collisions, so residial gas background can be estima- ted. The last 57000 - 146083 events, probably, contain luminosity fraction. The border of this separation is not exact(+/_ 1000 events) The exact value can be found from offline calculations trigger(event) rates, becouse of max. value for data taking rate was not reached. The mean trigger(event) rate for 0 - 57000 events was 12 Hz The trigger(event) rate for 57000 - 146083 events had slow change from 30 Hz to 22 Hz. The VC rate for the same events have changed from ~270 Hz to 200 Hz. For events with numbers around 95000 some manipulations with beams have take place. This also can be finded from event rate calculation. Rifferece timing for these calculations are revolution scaler values. The beam conditions see from the previos message. 05.11.1991 ==================== F11LEV === Lumi measurements ....... What worries me a bit, boys, is the fact, that background VC rate is so different for 12 and 26 GeV e-beam (factor of 22=150Hz/6.7Hz) while i would expect factor of 1.3 (238mb/186mb), since e-beam intensity was very similar (0.7 compared to 0.72 times 10**10). One possible explanation might be, that due to the much higher synch- rotron radiation in case of 26 GeV, the residual gas pressure was also higher (synchrotron photons hit beam pipe walls and produce additional gas). But in 15 times??? Looks doubtful. Could you check this with the machine experts, what they claim? The question is: are we insensitive presently to the p-halo background at VC due to the different timing, or not? Usik: difference between 26 and 26.5 GeV is really negligible (compare e.g. 26 and 30 GeV results: ratio is always at the same level of approx. 10.). Question to Sheviakov: ---------------------- 1) do you have an explanation for poor a(VC&PD) trigger efficiency during July run? Remember, requiring no gammas in Photon Arm (e.g. runs 5496, 5497) we nevertheless observed up to 20 GeV energy response from PD+VC. Efficiency were estimated at the level of 90% wich is incredibly bad! 2) it seems that cluster finder at h/w level is an important trigger element, at least for ET. MC study shows that systematic error in ET acceptance determination may be reduced from 5-6% to say, 2% (this last number i still has to prove by another MC simulation). Of cource, this is applied only for final detectors, but you are asked to take care about this trigger element would be available to the Feb'92. P.S. Sorry, i mixed up VC rate with a coincidence rate for the 12 GeV. So, VC rate factor between 12 and 26 GeV is 150/25=6, while expected value is (0.72/0.5)*(238/186)=1.8. Relative rise is thus 6/1.8=3.3 which still need to be understood. 1 05.11.1991 ==================== F11LEV === Run conditions .......... Why don't you fill all necessary run conditions for the recorded data? Please look into the very first message in this logbook and try to fill something similar to the proposed table unless you can make more clever proposal. What was e- energy and beam intensity? This information is scattered around different notes from many people, so i have to look through them to find out actual run conditions. Please, improve in future... I copied data to disk file: F11LEV.LUMI91.RUN10071 first 45689 events cartridge: F11LEV.LUMI91.CRT10071 all 125011 events which is less then online number of 146083 events, but this is all what i found on the H1 testdata cartriges from the run 10071. 08.11.1991 ==================== H1KFOM === New H1Lumi banks ........ From this day it is possible to find at H1Lumi data stream which is written into IBM3090's cartridges through H1 Central DAQ the new H1LUMI BOS-banks: LRTF and LRTC. Shortly about its format: 1) LRTF - contents: three pulses of different H1Lumi Trigger Sums: SumPD, SumET and SumPD+SumET. This pulses similar to pulses which You could see at LREF and LRPF banks but "window" consists of 22 bin (this pulses are wider); - format B16 (similar as for LREF and LRPF); - length are fixed and never changed; - Exmaple of HexaDecimal Dump of this bank: 4C525446 00000000 00000000 00000013 000C0003 00001717 17213748 4B3F3226 1E1B1309 01051923 272C2A2D 00010503 01040405 04050404 02020404 06050906 06040503 00020000 00000000 01050A16 1A17140C 0A060301 00000308 - each byte at three lines keeps unlinearized value of single 10nsec bin at 22 bins window; - 0000 at the first line is sign of SumPD pulse, 0001 at the second line - SumET pulse, 0002 at the third line - SumPD+SumET pulse. 2) LRTC - contents: different H1Lumi Trigger System counters. For today at this bank we have 310 counters - 10 counters from 31 different group counters (10 from 220 couters at each group). - format B32; - length are fixed and never changed; - Structure of this bank: LRTC - name 0 0 343 length at longword without 4 longwords of header 11 Nrow 31 Ncol 1st group of counters (11 longwords) 2nd group of counters (11 longwords) ..... 31th group of counters (11 longwords) -Structure of ith group of counters (11 longwords): 1st longword: first byte - bunch counter number (0-219) - N; second byte - group number (1-31) - M; third and fourth bytes - masks for counters; 2nd - current value of N-counter from M group (24 low bits); 3nd - current value of N+1-counter from M group; .............................................. 11th - current value of N+9-counter from M-group. - Structure of mask word at first longword: significant bits are - 0,1,2,3,4 and 7. "1" at significant bit means that no mask for some trigger. 0 bit corresponds to WaterVeto trigger bit; 1 bit SumPD; 2 bit SumET; 3 bit InnerVetoWall; 4 bit OuterVetoWall. 7 bit servis bit (=1). -correspondence between trigger bits and groups of counters; (if all trigger bits unmasked) Group WaterVeto SumPD SumET InVeto OutVeto 1 1 0 0 0 0 2 0 1 0 0 0 3 1 1 0 0 0 4 0 0 1 0 0 ...................... 31 1 1 1 1 1 1 For example, counters from group 2 count events with trigger: anti(waterVeto)&SumPD&anti(SumET)&anti(InVeto)&anti(OutVeto) counters from group 31 count events with trigger: waterVeto&SumPD&SumET&InVeto&OutVeto 220 counters at each group needed for counting of events from all 220 bunches. At present bank we have only 10 counters from 220 (only around single bunch). Remark: if some bit at mask is 0 - it means that this trigger bit is not member of trigger coincidence. For example: if bit 0 at mask word is 0 - counters of group 31 counts events with trigger: SumPD&SumET&InVeto&OutVeto (without WaterVeto). Including of this banks at each event is temporary - for reading of all needed for creating of this bank information H1LumiOnLine program got near 4msec per event (when we shall work with H1 Central Trigger - we must have this time not more then 800 mcsec). It is possible at new version of OnLine Program to switch On/Off the creating of this bank through SuperCard monitor. Maximum rate of putting H1Lumi-event into H1CDAQ with new banks is 60-70 Hz. Without LRTC - near 100 Hz. Without LRTF - near 128 Hz. Maximum length of event now is 2836 bytes, without LRTC - 1448 bytes 09.11.1991 ==================== H1KFOM === Two Bunches IN e-Ring ... There was very interesting situation today at H1 Interaction Point. HERA machine people put into e-ring 2 bunches - one (number 0) for collisions with p-beam bunch and second (number 19) - for collisions only with residual gas. H1LumiOnLineFIFO-program has special counters for monitoring of rates of appearing of candidates to Bremsstrahlung events at H1Lumi trigger at two different bunches. We had attempt of monitoring this counters at DA "BeamInten- sity". All was resonable - during 21 minutes we had rates from bunch 0 near 25-27 Hz and from bunch 19 near 1-2 Hz. It was filled histos of profiles for events from bunch 0 and from bunch 19. Pictures it is possible see at LUMI-Logbook. It was 21 minutes of ep-collisions at H1 Interaction Point today from 14:30 up to 14:51. 09.11.1991 ==================== F11LEV === Multibunch mode usage ... This would be ok (i mean previous message) provided you are confident that these two bunches have the same, or at least very similar inten- sity. However, our experience shows, that bunches usually are filled differently (see e.g. Run 9022). Therefore, please, try always before collisions measure relative bunch filling by taking e-gas data during few minutes and then use this information for trigger rate normaliza- tion, otherwise your conclusions about ep-luminosity might be wrong! Other info. ---------- I tried last long run analysis using cal.coeff. from 12 GeV run. Good news: mean beam energy was found to be 26.7 GeV (no large shift) Bad news: sigma = 2.1 GeV giving energy resolution = 7.9% (compared to best July result of 3.5% and typical July res. = 4.8%) Calibr. coeff. during one last run (2.5 hours) were changed on 20-30%! Using requirement on abs(E_tot-E_beam) < 2.5 sigma i found, that our luminosity estimation changes on 17,9%. Remember, that we are aiming to reach the level of systematic error below 5%. My hope that cluster analysis would help to reduce systematic error in ET acceptance calculations did not realized. The improvements is only from 5% to 4%, at least at Monte Carlo level. Problems which still not solved, or even sometimes not understood: ------------------------------------------------------------------ 1) Anti (VC.or.PD) trigger inefficiency during July run. 2) Instability of calibration coefficients. If they are really so dependent on loading rate, one has to provide dynamical correction function, allowing to correct CC at least at the offline level using knowladge on the actual rate. However, this will have bad concequences on h/w trigger efficiency (e.g. any energy cuts will also be washed away). 3) Coordinate reconstruction at ET - out of any reasonable shape. Any ideas flying around? 4) Huge background to the lumi events in the run 10071. What is really bad, this background cannot be easily removed by energy threshoulds at ET and/or PD, as it was in July. Low energy background is understandable and we know how to reject it. But in latest run the background was above 5 GeV at ET (having "second" maximum at 6 GeV) and around 11+-1 GeV at PD. I personally don't understand the nature of this damned background. 1 09.11.1991 ==================== H1KFOM === LREC &LRPC banks were OK? I am sorry but I think that I put into LREC and LRPC banks the right values. Today I checked hexadecimal dumps of LUMI91.RUN09022 and LUMI91.RUN10050 data sets at my catalog and found that all is OK. May be something not right at routine for checking of contents of this banks at IBM3090. May be something wrong at format. Example of hexadecimal dump of this banks: 4C524543 LREC - name of bank 0 0 33 length of bank at longwords (without header longwords) 1 Nrow 31 Ncol 0000BE57 Calibration Coefficient for e0 00009C8C e1 00009AD6 e2 ....... 0000AB17 e45 0000720F e46 0000AB17 e47 0000720F e48 Request to Sergey Levonian - check please the contents of this banks else one. 10.11.1991 ==================== F11LEV === Online cal.banks are ok.. Fomenko was right, formally content of LREC and LRPC banks were correct however, general problem of c.c. stability is still vital. Those who want to see how c.c. are changing in time may execute the following LOOK session (since pictures are not in a computer readable form; > means command prompt): > LOOK ! enter an interactive LOOK session > 1 ! choose terminal type (1 is valid both for ! Mac and IBM graphics terminals) > exec '.f11lev.lumicc' ! execute my macro file creating figures ! (note a fullstop sign in front of userid!) > fig1 ! display 4 figures for PD counters > fig2 ! display 1 figure for VC cal.coeff. > fig3 ! display 7 figures for ET counters > qq ! terminate LOOK session. Each figure contains 3 curves: S(Soloviev's c.c), U(Usik's c.c.), OL(c.c. which i got from online (LREC LRPC banks). 10.11.1991 ==================== H1KFOM === Runs 10848 - 10857 ...... At 18:38 today after injection of electrons and ramping we could look 26 GeV electrons at HERA. Malinovskii said that machine people don't know - is collisions or not. But p-beam existed too. At 18:55 Ip = 106 mkA (but after two hours Malinovskii said that this digits were up to 2 more then really was). Ne = 3.16*10**10. ** The current of P-beam was really about 106 mkA(18:50) but at one bunch there was only 50% and the rest has been distributed between a few others. Time table. At 18:40 Ip = 108 mkA,Ne = 3.22*10**10 At 19:10 Ip = 98 mkA, Ne = 3.08*10**10 At 19:23 Ip = 90 mkA, Ne = 3.00*10**10. At 19:42 Ip = 75 mkA, Ne = 2.95*10**10. At 19:58 Ip = 66 mkA, Ne = 2.93*10**10. At 20:10 Ip = 55 mkA, Ne = 2.90*10**10. At 20:20 Ip = 51 mkA, Ne = 2.85*10**10. At 21:00 Ip = 46 mkA, Ne = 2.68*10**10. At 21:58 Ip = 34 mkA, Ne = 2.52*10**10. It was decided (may be it was e-beam without collisions) to try writting of some Runs into IBM. Runs were written as was recommended at 3.11.91 by S.Levonian (data for off-line analysis) at LogBook. Run 10848. Trigger WaterVeto. Thresholds: WaterVeto 8. Start of Run - 10.11.1991 at 18:56:26. End of Run - 10.11.1991 at 19:12:04. Number of events: 101795 (mode 1) from 913987. Run 10849. Trigger: SumPD&SumET&anti(WaterVeto). Thresholds: SumPD 199/13; SumET 199/12; WaterVeto 8. Start of Run - 10.11.1991 at 19:19:21. End of Run - 10.11.1991 at 19:51:50. Number of events: 20004 (mode 1) from 20046. Run 10850. Trigger: SumPD&SumET. Thresholds: SumPD 199/13; SumET 199/12 Start of Run - 10.11.1991 at 19:58:14. End of Run - 10.11.1991 at 20:09:53. Number of events: 54580 (mode 1) from 54689. 1 The next Runs - attempt to make data for threshold of SumET calibra- tions: Run 10851. Trigger: SumET. Thresholds: SumET 199/12 Start of Run - 10.11.1991 at 20:15:10. End of Run - 10.11.1991 at 20:16:55. Number of events: 12608 (mode 1) from 26024. Run 10852. Trigger: SumET. Thresholds: SumET 199/22 Start of Run - 10.11.1991 at 20:20:52. End of Run - 10.11.1991 at 20:22:23. Number of events: 10878 (mode 1) from 20437. Trigger rate - 221 Hz. Run 10853. Trigger: SumET. Thresholds: SumET 199/32 Start of Run - 10.11.1991 at 20:27:58. End of Run - 10.11.1991 at 20:29:23. Number of events: 10284 (mode 1) from 17066. Trigger Rate - 199 Hz. Run 10855. Trigger: SumET. Thresholds: SumET 199/42 Start of Run - 10.11.1991 at 20:35:01. End of Run - 10.11.1991 at 20:37:30. Number of events: 10063 (mode 1) from ?????.Trigger rate 154 Hz. Run 10857. Trigger: SumET. Thresholds: SumET 199/52 Start of Run - 10.11.1991 at 21:15:16. End of Run - 10.11.1991 at 21:17:02. Number of events: 11174 (mode 1) from 11626. Trigger rate 107 Hz. 11.11.1991 ==================== H1KSHE === Run 10864 ............... During this run for evets with numbers ~0 - 27610 the PD*ET trigger was selected, and for last 27610 - 35069 numbers was PD*ET*ant.VC. The trigger rate from ~25 to ~2 Hz after this switching was down. It was observed that the intensive plaeing with beams take place. Currents: At 06:38 Ip = 46 mkA, Ne = 1.25*10**10. At 08:30 Ip = 27 mkA, Ne = 1.02*10**10. Triggers PD*ET and PD*ET*antiVC. Thresholds: WaterVeto 8. Photon D 13. Electr.T 12 Start of Run - 11.11.1991 at 06:38:12. End of Run - 11.11.1991 at 08:08:21. Number of events: ~30000. First news: the fast trigger monitoring,by using LUMI trigger monitor card (220*32 scalers), shows that timing for catching ET trigger was not correct, as seems me today. The max. ET trigger statistic lies betweeng 0 and 1 bunches. This means that somthing was changed in HERA timing after summer tuning, may be just slightly. It can be couse of simultenios tuning e,p beams. New timing was installed today. For this reason Run 10864 has the aim to check that last modification doesn't make worse the situation. Second, the same monitoring shows some not undersandeble cross cor- related trigger statistics (betweeng different bunches) that have considerable values. This can be addition sourse of background. Third, the triggers Calo, VetoIn, VetoOut from VetoWall are accepted in LUMI with correct time (triggers must arrived in the same bunch as ET,PD,VC trig.) and relevant logic levels. Time and logic levels ajustment was made in LUMI system. During several last e-p runs some attempts for estimation the rates for common with VetoWall triggers was made. The values relevant triggers are: Mean luminosity rate was ~48-35=13 Hz. (35 is background) Calo*ET*ant.PD*ant.VC ~ 0.3 Hz VetoIn*ET*ant.(PD*VC) ~ 3 Hz Calo*VetoIn*ET*ant.(PD*VC) ~ 0.1 Hz Calo ~ 200 Hz VetoIn ~ 2000 Hz ET*ant.(PD*VC) ~ 200 Hz 1 Of course the data is very preliminary, but was measured directly. Details can be taken from me if somebody interested. To make exact estimation the relevant Run record is needed, but for this moment very hard to catch good beam conditions. 11.11.1991 ==================== H1KFOM === LRTC-bank (new release).. It was made some changing (with request of Igor Sheviakov) with contents of LRTC banks. The format and data structure is the same but it is possible have at different Runs the different length of this bank and get information not from all group of counters. But it is possible now to have two "windows" from each group of counters. This is example of some hexadecimal dump of LRTC now: 4C525443 name LRTC 00000000 00000000 000000C8 length (at longwords without header longword) 0000000B Nrow (always 11) 00000012 Ncol (from 1 to 62 may be at different Runs) 0001009F XXX1stXX XXX2ndXX XXX3rdXX .... XX10thXX 1st "window" of gr1 D201009F X210thXX X211thXX X212thXX .... X219thXX 2nd "window" of gr1 0002009F XXX1stXX XXX2ndXX XXX3rdXX .... XX10thXX 1st "window" of gr2 D202009F X210thXX X211thXX X212thXX .... X219thXX 2nd "window" of gr2 .................................................. 0018009F XXX1stXX XXX2ndXX XXX3rdXX .... XX10thXX 1st "window" of g24 001C009F XXX1stXX XXX2ndXX XXX3rdXX .... XX10thXX 1st "window" of g28 Group number is incremented from begin to end of data piece of bank. Group numbers and existing of 1st or 2nd window or both windows at bank are options before Start Run of our subsystem. First longword at each 11 must be decoded with detail (high byte - number of bunch for first counters from window, next byte (16-23bits) - group number,for example, group number 1 counts events with the next trigger : Anti(OuterVeto)&Anti(InnerVeto)&anti(SumET)&anti(SumPD)&WaterVeto group number 31 counts events with the next trigger : OuterVeto&InnerVeto&SumET&SumPD&WaterVeto; the two low byte is mask. See previous message at logbook. 12.11.1991 ==================== H1KMAL === Conditions for run 10879. Short description of all actions which were done on HERA from 10:30 to 14:40 . 10:40 There are two beams at HERA - ring, E(electron)=12 GeV 11:25 The electron beam intensity was increased 11:33 The Ramping of the electron beam up to 26.5 GeV 11:45 The start of a lateral scan of the proton beam 12:47 The horisontal shift of the electron beam 12:50 The vertical shift of the electron beam 12:56 Collisions 13:02 The proton beam shift for a control of collisions 13:37 The electron beam shift for the same control 13:58 The regime was restored Time table for the intensity of beams. 10:40 I(p) = 86 mkA, N(electron) = 0.20 * 10 ** 10 11:25 I(p) = 85 mkA, N(electron) = 1.75 * 10 ** 10 11:40 I(p) = 84 mkA, N(electron) = 1.73 * 10 ** 10 11:50 I(p) = 79 mkA, N(electron) = 1.71 * 10 ** 10 12:10 I(p) = 65 mkA, N(electron) = 1.70 * 10 ** 10 12:30 I(p) = 59 mkA, N(electron) = 1.64 * 10 ** 10 12:55 I(p) = 52 mkA, N(electron) = 1.58 * 10 ** 10 13:15 I(p) = 45 mkA, N(electron) = 1.55 * 10 ** 10 13:35 I(p) = 33 mkA, N(electron) = 1.49 * 10 ** 10 13:55 I(p) = 30 mkA, N(electron) = 1.46 * 10 ** 10 14:15 I(p) = 29 mkA, N(electron) = 1.44 * 10 ** 10 14:34 I(p) = 24 mkA, N(electron) = 1.42 * 10 ** 10 14:35 the electron beam is kaputt. 12.11.1991 ==================== H1KFOM === Run 10879(ep-collisions). Today it was looked beams activity at HERA. We decided to write long Run with all history of situations at HERA. We was right. At this time very interesting situation are "documented". We looked injecti- on of e-beam with 12 GeV after this - ramping up to 26.?? GeV and after this living of two beams at rings without collisions and finaly ep-collisions. During ep-collisions it was looked atempts of HERA- -peoples to stop ep-collisions (by same way) and after this to re- start ep-collisions. All this events was happened from 11:03 up to 14:37. At this time H1CDAQ was under our using and we wrote Run 10879. At this Run You can firstly look the new banks LRTF and LRTC. Mean value of event size is near 1.75Kbyte. At Run 10879 we collected 354381 events with trigger SumET&SumPD with "standard" trhesholds: 199/13 for SumPD and 199/12 for SumET. 1 Run 10879. Trigger: SumPD&SumET Thresholds: SumPD 199/13, SumET 199/12. Start of Run - 12.11.1991 at 11:03:11. End of Run - 12.11.1991 at 14:37:05. Number of events: 354381 (mode 1). New banks - LRTF and LRTC. The last bank very important for monitoring of rates of different coincidence of available trigger bits. 12.11.1991 ==================== H1KFOM === LRTN - new H1Lumi bank... From today it is available the next release of H1 Lumi OnLine Program with the name H1LUMIOnLineFIFOnew1. This release can create new trigger bank LRTN with very important information. This bank is very short - length 6 longwords (without header longwords). Its format is B32. Short discription is the next: LRTN - name 0 0 6 - length 1 - Nrow 4 - Ncol XXXXXXXX - Total Luminosity Scaler XXXXXXXX - Sel.Bunch Luminosity Scaler XXXXXXXX - Local Time Scaler (frequency now is 2950 Hz) XXXXXXXX - H1Lumi Trigger The appearence of this bank is the next milestone to realization of multitrigger mode of data taking. 12.11.1991 ==================== H1KFOM === Run 10885 ............... Today evening it is appeared new activity of HERA beams. E-beam was began near 20:30-20:40. We decided to write new Run with trigger SumET&sumPD&anti(WaterVeto). Run 10885 started at 21:38. The ramping was seen at this time. We collected 1736 events with new release of OnLineProgramm (with LRTN-bank). But at 21:44 both beams were lost. This Run can be useful as first Run with LRTN-bank. It is possible to try decoding of this bank. 12.11.1991 ==================== H1KMAL === Conditions for run 10885. 21:00 I(p) = 118 mkA, N(electron) = 0.22 * 10 ** 10 21:05 I(p) = 118 mkA, N(electron) = 2.21 * 10 ** 10 21:10 I(p) = 118 mkA, N(electron) = 1.03 * 10 ** 10 21:20 I(p) = 118 mkA, N(electron) = 1.01 * 10 ** 10 21:40 I(p) = 117 mkA, N(electron) = 0.98 * 10 ** 10 21:42 THE ELECTRON BEEM IS OVER 13.11.1991 ==================== H01USA === Next progress in HERA.... This night shift we have first stable lumi run: luminosity was stable during long time in comparison with previous shifts when luminosity fast decreased becouse of fast degradation of proton beam during collisions. This problem was decided (for my opinion ) this night when new optic for e-beam was installed (which is doubled beta- function in our IP - from explanation of HERA night shift). The short history of this hight: time Ip Ne Rwc R& Comments _____________________________________________________________________ 3:40 90 1.757 423 43 0.64 0.12 before collision 26x480 GeV 3:46 80! 1.740 759 89 0.68 0.06 beginner of collisions 3:48 77 1.740 701 76 0.76 0.11 L=1.8*10**27 cm-2 sec-1 3:51 73 1.732 662 73 0.75 0.06 4:05 54 1.708 438 44 separation of beams 4:08 54 1.698 834! 38 new optic is installed: very bad ratio Rwc/R& 4:27 52 1.685 442 46 0.16 0.29 some tunning with new optic - return to residual gas only 4:30 53 1.655 425 48 0.28 0.28 4:33 Egor set new trigger for green curve => now no profile histos 4:38 53 1.634 536 57 start collision again but with new optic 4:46 53 1.621 539 69 L=0.66*10**27 cm-2 sec-1 4:47 53 1.621 564 65 4:53 53 432 47 test: beams are separated 5:20 52 1.557 523 60 collisions again 5:45 50 1.514 470 54 7:09 47 1.380 424 47 ______________________________________________________________________ 1 Ip - proton beam current, uA Ne - number of electrons *10 **-10 Rwc - rate from water counter,Hz R& - rate of lumi trigger,Hz , - horizontal and vertical position of photon beam,cm. During this night Run 10887 was recorded -> see next message. 13/11/91 ===H1KSHE===RUN 10887 ==32671 + (192 * 0.0?) Photopr.Events Run 10887. Trigger: 1. SumPD&SumET&antiVC for first 30805 events 2. ET&antiPD&antiVC&INveto(VetoWall) for 30805 - 32671 event numbers 3. ET&antiPD&antiVC&Calo(VetoWall) for 32672 - 32863 event numbers Thresholds: SumPD 199/13, SumET 199/12. Start of Run - 13.11.1991 at 03:01:13. End of Run - 12.11.1991 at 07:51:43. Number of events: 32863 (mode 1). Banks LRTC and LRTN were included The last 192 events (third trigger) during 1 h. 40 min were collected. Rates for corresponding triggers were ~8 Hz, ~0.5 Hz, ~0.0? Hz The luminosity for events with last two triggers can be estimated from LRTN bank contents, and also from online diagrams. Some comments. 1. Special shift in bunch numbers was made to better see an around bunch zero trigger statistic i.e. several before and several after The shift equal 3*Hclock i.e. statistic for zero bunch lies in data corresponding to bunch number 3. (the same valid for Run 10879) 2. To calculate statistic for unconditioned triggers the whole number of statistics with trigger combinations for others trgg. elements must be added. example: Calculation for VetoCounter total statistic Svc = Stat.(VC*PD*ET*CALO*INveto) + (VC*ant.PD*ET*CALO*INveto)+ .. ....+(VC*ant.PD*ant.ET*ant.CALO*ant.INveto) (16 items totaly) 3. Don't forget the factor 1/2 for these statistics, so final value must be multiplied by 2. 4. In most of cases it is not need to calculate total value becouse of small values for random coincedece probability factors, and for rough estimation the selection from TRIGGER*(others is anti) can be sufficient. 5. Instead the OutVeto(VetoWall) trigger element the Calo(VetoWall) trigger element was inserted.(this valid for all runs since run 10879) 6. Luminosity rate from 13/11/91 H01USA message is given for trigger ET&PD , the same trigger in LRTN bank is counted. 13.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 10898. Short description of all actions which were done on HERA during this run::from 18:20to 20:05 18:10 There is only p-beam at HERA 18:25 The injection of electrons into HERA 18:48 The Ramping of the electron beam up to 26.5 GeV 18:55 The end of ramping 19:00 The start of the actions with magn.optic 19:15 The end of all actions 19:36 The proton beam was killed 20:05 The electron beam - kaputt Time table for the intensity of beams. 18:30 I(p) = 64 mkA, N(electron) = 2.91 * 10 ** 10 18:45 I(p) = 62 mkA, N(electron) = 2.86 * 10 ** 10 18:58 I(p) = 60 mkA, N(electron) = 2.79 * 10 ** 10 19:15 I(p) = 52 mkA, N(electron) = 2.72 * 10 ** 10 19:30 I(p) = 40 mkA, N(electron) = 2.68 * 10 ** 10 19:36 N(electron) = 2.67 * 10 ** 10 19:55 N(electron) = 2.61 * 10 ** 10 13.11.1991 ==================== H1KFOM === Multitrigger Mode ....... From this day it is appeared new release of the OnLine Program for creating of "kvazi"-OR trigger mode - i.e.multitrigger mode of writting information into IBM3090 cartridge. Now this version (H1LumiOnLineFIFOnew2) works with default mode as multitrigger mode with 1sec. period of trigger changing. Triggers which are included into this infinity chain are SumPD only, SumET only, Water Veto only. 1 In principle it is possible to include any triggers into this chain (up to 8 different triggers). It is possible to change the period of changing of the next trigger. It is possible to change the number of working triggers simultaneously (from 1 to 8). This release was tested with H1 CDAQ (Runs 10895,10896). With this release was collected very waitable data (Stand-alone e-beam (e-gas bremstrahlung). See message of S.Levonian from 03.11.91 " ...3) OR-trigger (ET.or.PD.or.VC) 120 000 events ...." It was Run 10898. 13.11.1991 ==================== H1KFOM === Run 10898 ............... Run 10898. Triggers: SumET.or.SumPD.or.WaterVeto label of each trigger it is possible find at LRTN-bank. Start of Run: 18:28:09. 13.11.1991 End of Run: 20:06:15. 13.11.1991 Number of events 358266. Last 1/3 of events were written with standalone e-beam of 26 Gev. 14.11.1991 ==================== H01USA === No progress in HERA...... This nigt shift was unsuccessful: we had collision only during 1 min, all following attempts were unsuccessful. 14.11.1991 ==================== H1KSHE === Trigger timing again..... Alone ET trigger seems to be not suitable for thresholds calibration for this time of permanent tuning and monitoring for HERA necessity. As was generaly known from last summer tests that was not possible to find the optimal time shift within one Hclock to detect relevant responses from ours detectors with time accuracy ~10 ns. This was happen becouse of there were no collisions purpose for HERA peoples. In fact in each new run we had new time shift with respect to Hclock. It was decided to exclud the fine time analysis from the trigger. From end of summer run any pulses arrival from ours detectors are considered by trigger logic withing one Hclock gate to decide to which bunch it correspods only, no time analysis more. As the measurements shows, we have relatively uniform time distribution of pulses around filled bunch coming from ET and VC. The shape of this distribution is not yet measured (probably it depends on beam conditions), but usualy it overlaps up to three bunches. (For pulses coming from PD situation is mach more better.) This can couse very large amplitude dispersion becouse of nobody knows how a pulse lies in the FADC window, and in case of the looking for coincidene with Photon Detector pulse the timing must be checked. All above is evident, but to switch on the time analysis in the trigg. again we must be sure that relevant parametres for beams are not changed. The best way is to make our time gate width step by step the less value,but due to permanent monitoring it is very dangerous to change namely this trigger condition. This night I have try to investigate the bunch distribution for VC ET, PD, Inveto, Calo triggers during different beam revolution phases. For this night time Runs we had following per cent of trigg.statistic: Veto Counter Electron Det. Photon Detec. VetoWall Bunch ------------- ------------- ------------- ---------- No 12Gv. 26Gv. Col. 12Gv. 26Gv. Col. 12Gv. 26Gv. Col. InV. Call ------------- ------------- ------------- 217 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 1% 218 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 219 64% 56% 58% 33% 38% 42% 0% 0% 0% 6% 5% 0 33% 40% 37% 65% 43% 44% 99% 91% 88% 87% 88% 1 3% 4% 5% 2% 18% 14% 0% 9% 12% 5% 5% 2 0% 0% 0% 0% 0% 0% 0% 0% 0% 2% 1% Where Col. means collisions. 14.11.1991 ==================== H1KFOM === Trigger Labels at LRTN... Little remark about trigger labels which You can find at last (4th) longword of LRTN-bank. It is important for separating of events with different triggers (at multitrigger mode - "kvazi"-OR). SumPD only - 0000FFDF SumET only - 0000FFF7 WaterVeto only - 0000FF7F At nearest Runs it must be appeared the next trigger labels: SumPD & SumET - 0000FFD7 SumET & WaterVeto - 0000FF77 SumET & anti(SumPD) - 0000FFC7 SumET & anti(WaterVeto) - 0000FF37. 1 14.11.1991 ==================== H1KFOM === Run 10900 ............... It was written very long Run again - we waited ep-collisions but near 17:40 the e-beam was lost. But it means that we had almost "pure e-beam" and this Run is (may be) answer for S.Levonian request from 03.11.1991 (see LogBook earlier): "...4) The following chain (in one go): ET only (20K) -> ET & (PD.or.VC) (20k) -> ET & no (PD.or.VC) (10k) -> ET only (20k) ........." Run 10900 started from 14:41:43. At 15:47 the counters of different triggers at our data flow had the next values: ET only - 45972 (23.9% of all events) ET & PD - 31472 (16.3% ) ET & VC - 30471 (15.8% ) ET & no(PD) - 42450 (22.0% ) ET & no(VC) - 42309 (22.0% ) During this Run triggers was changed after next 2 sec. Now - existing release of H1LumiOnLineFIFOnew2 with default mode is working with this 5 trigger multitrigger mode with changing of triiger after each 2 sec. Run 10900. Trigger: SumET .OR. SumPD&SumET .OR. SumET&WaterVeto .OR. SumET&anti(SumPD) .OR. SumET&anti(WaterVeto) Thresholds: SumPD 199/13, SumET 199/12, WaterVeto 8. Start of Run - 14.11.1991 at 14:41:43. End of Run - 14.11.1991 at 16:57:15. Number of events: 413351 (mode 1). All possible banks was presented at this Run - LREC,LRPC,LREE,LRPE, LREF,LRPF,LRTE,LRTN,LRTC,LRTF,TSTC. LRTN-bank has 4th word with trigger code (label) - see previous message. 14.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 10900. Short description of all actions which were done on HERA during this run::from 14:40 to 17:00 14:30 There is only p-beam at HERA 14:35 The injection of electrons into HERA: there are e few bunches-main one has I=0.395mA, as total I=0.41mA. ( in fiture I will give data about only main bunch) 14:51 The electron beam - kaputt 15:00 The injection of the new electron bunch into HERA 15:18 The start of ramping of the electron beam up to 26.5 GeV 15:21 The end of ramping 15:25 -----> The actions at SUD 17;30 The electron beam was killed Time table for the intensity of beams. 14:30 I(p) = 162 mkA, no 14:40 I(p) = 142 mkA, N(electron) = 5.25 * 10 ** 10 14:50 I(p) = 138 mkA, N(electron) = 5.20 * 10 ** 10 14:52 I(p) = 138 mkA, no 15:05 I(p) = 125 mkA, Total N(electron) = 4.610 * 10 ** 10 One bunchN(elect)= 4.526 * 10 ** 10 15:15 I(p) = 113 mkA N(electron) = 4.24 10 * 10 ** 10 15:25 I(p) = 87 mkA, N(electron) = 4.17 * 10 ** 10 total N(electron) = 4.21 * 10 ** 10 15:35 I(p) = 77 mkA, N(electron) = 4.2 * 10 ** 10 15:40 I(p) = 75 mkA N(electron) = 4.07 * 10 ** 10 15:50 I(p) = 66 mkA, N(electron) = 3.99 * 10 ** 10 16:00 I(p) = 64 mkA N(electron) = 3.94 * 10 ** 10 16:20 I(p) = 61 mkA, N(electron) = 3.48 * 10 ** 10 16:35 I(p) = 60 mkA N(electron) = 3.38 * 10 ** 10 16:50 I(p) = 59 mkA, N(electron) = 3.29 * 10 ** 10 17:10 I(p) = 58 mkA N(electron) = 3.18 * 10 ** 10 14.11.1991 ==================== H1KFOM === Runs 10941,10945 ........ After phone talking with S.Levonian we decided to try writting of the next Run with the same trigger as at Run 10900 but without LRTC and LRTF banks. We had attempt to write Run 10941 with mode 6 (without LREF and LRPF banks). All was OK. But at this mode it is impossible to do profiles for HERA ControlRoom (I must make some changing at On-Line Program for producing of profiles at 6 mode). But Run 10941 exists and it has 32712 events (very short - only near 420 bytes per event). It is really to work with this "suppressed" Run. After this we changed mode from 6 to 1 again and now are producing Run 10945 with the same .OR. trigger (5 type) as at Run 10900 and Run 10941 but with LREF and LRPF banks. 1 Run 10941. Trigger: SumET .OR. SumPD&SumET .OR. SumET&WaterVeto .OR. SumET&SumPD .OR. SumET&anti(SumPD) .OR. SumET&anti(WaterVeto) Thresholds: SumPD 199/13, SumET 199/12, WaterVeto 8. Start of Run - 14.11.1991 at 22:01:34. End of Run - 14.11.1991 at 22:07:45. Number of events: 32712 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC. This Run was written with e-beam energy 26.5 GeV and without collisions. Proton beam existed. Run 10945. Trigger: SumET .OR. SumPD&SumET .OR. SumET&WaterVeto .OR. SumET&anti(SumPD) .OR. SumET&anti(WaterVeto) Thresholds: SumPD 199/13, SumET 199/12, WaterVeto 8. Start of Run - 14.11.1991 at 22:22:20. End of Run - 15.11.1991 at 00:13:01. Number of events: 533633(mode 1). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LREF,LRPF. This Run was began with e-beam energy 26.5 GeV and without collisions. Proton beam existed. 14.11.1991 ==================== H1KMAL === CONDITIONS FOR last runs. Short description of all actions which were done on HERA during this runs:from 21:40 to 23:20 21:40 There are two beams at HERA 21:51 The start of ramping of the electron beam up to 26.5 GeV 21:56 The end of ramping 23:00 -----> May be collisions ? Time table for the intensity of beams. 21:40 I(p) = 45 mkA, N(electron) = 4.71 * 10 ** 10 21:57 I(p) = 45 mkA, N(electron) = 4.58 * 10 ** 10 22:10 I(p) = 44 mkA, N(electron) = 4.53 * 10 ** 10 22:25 I(p) = 43 mkA N(electron) = 4.44 * 10 ** 10 22:35 I(p) = 42 mkA, N(electron) = 4.37 * 10 ** 10 22:50 I(p) = 42 mkA N(electron) = 4.29 * 10 ** 10 23:10 I(p) = 40 mkA, N(electron) = 4.18 * 10 ** 10 23:20 I(p) = 35 mkA N(electron) = 4.09 * 10 ** 10 15.11.1991 ==================== H01USA === News from night shift.... This night shift we had nice posibiflity to work with record for this time lumi - 5.3*10**27 cm-2sec-1 but ... we had this lumi only during one minute and after this separation was made for playing in Zeus IP. The last was unsuccessful. So NE IM I NE NAM. time Ip Ne Rwc R& R&V Comments _____________________________________________________________________ 3:30 161 3.222 during ramping to 26.5 GeV 3:37 160 3.188 Ee=26.5 GeV 3:56 159 2.64 864 99 9.5 residual gas 3:58 159 2.63 1734 212 18 collision L = 5.3*10**27 cm-2 sec-1 4:05 160 2.605 892 94 -0.52 0.78 5.14 beam separation, attempts to get lumi in Zeus 4:14 160 2.605 882 101 9 895 103 10.75 873 103 10.55 4:36 159 2.512 932 97 -0.9 0.78 6.45 966 100 10 960 91 9.4 4:50 159 2.470 932 92 936 98 941 102 4:54 159 2.465 1071 90 influence of playing with Zeus 5:05 62 2.426 1078 95 suddenly lost some part of p-beam........ ______________________________________________________________________ Ip - proton beam current, uA Ne - number of electrons *10**-10 Rwc - rate from water counter,Hz R& - rate of lumi trigger,Hz R&V - R& on coincidence with antiveto,Hz , - horizontal and vertical position of photon beam,cm. During this night Run 10950 was recorded -> see next message. 1 15.11.1991 ==================== H1KSHE === Run 10950: trigger bgr... Run 10950 This Run was writen with the aim to estimate the first order of background for the common with VetoWall trigger. Unfortunetly there were not collisions during this long time run and good relative esti- mations for common trigger is not possible to do. Thresholds: SumPD 199/13, SumET 199/12, WaterVeto 8. Start of Run - 15.11.1991 at 03:59:29. End of Run - 15.11.1991 at 06:59:10. Number of events: 46414 Trigger: ET&PD - First ~5 min of run, mean rate ~85 Hz. ET&PD&noVC - Next ~25 min of run, mean rate ~9 Hz. ET&Calo&noVC&noPD - Next ~2 h. 25 min rate ~0.? Hz. ET&PD&noVC - Last 5 min(for reff. value at the end) All possible banks was presented at this Run - LREC,LRPC,LREE,LRPE, LREF,LRPF,LRTE,LRTN,LRTC,LRTF,TSTC. LRTN-bank has 4th word: 0000F7C3 for trigg. ET&Calo&noPD&noVC 0000FFD7 for ET&PD 0000FF17 for ET&PD&noVC After ~1 h. 15 min from start of run a 2/3 of proton beam current was losted (during ~1.5 min) and some peak of trigger rate can be observed. 15.11.1991 ==================== H1KFOM === "Zero" Pedestals ........ It is appeared some version about "zero"-values of pedestals. It is possible of course to explain its appearing at pedestal histos with high frequency of input signals but (as Egor predicted - this explanation is good for 500 kHz and more). Now we have not this frequencies. May be there is a little bug with filling of pedestal histos (or misundestanding how to do it). At most Run we worked with mode 1 for data taking. At this mode we have LREF and LRPF banks from which information for pedestal histos is got. But... We have this banks only for hitted cells. If before decoding all Your arrays with dimensions (7,10) forET,(4,10) for PD and (1,10) for WaterVeto are erased with zero and after decoding not zero infor- mation is appeared only for hitted cells - may be this is the reason of appearing of "zero" pedestals. It is needed to fill pedestal histos only for hitted cells. But it is only idea - may be all is OK with filling. 15.11.1991 ==================== H1KFOM === Two bunches possible .... From yesterday Malinovskii talking with HERA people there is very probably situation for today evening or night from Friday to Saturday for working with two bunches. We have posibility to write first Runs with two bunches. Egor proposed to take data at this time with single trigger - ET & PD & anti(VC) and with all possible banks for trigger (LRTC especially) and to change the begin of the second window from 210 (as it was earlier) to 19 (as we suppose that the second bunch must be with number 19). And to switch on all 31 group with both window. Length of event is waiting near 2.4 Kbyte. Somebody who have any other idea to use this rear situation at HERA activity welcome to propose another trigger or alternative proposal. 15.11.1991 ==================== H1KFOM === Trigger Labels (Codes)... This is the table of existed or planned triggers at our raw data. 4th longword at LRTN-bank must have one from this values: Trigger Hex Decimal SumET only 0000FFF7 65527 SumPD only 0000FFDF 65503 WaterVeto only 0000FF7F 65407 SumPD & SumET 0000FFD7 65495 SumPD & SumET & anti(WaterVeto) 0000FF17 65303 SumET & anti(SumPD) 0000FFC7 65479 SumET & anti(WaterVeto) 0000FF37 65335 SumET & WaterVeto 0000FF77 65399 SumET & Calo & anti(SumPD) & anti(WaterVeto) 0000F7C3 63427 SumET & anti(SumPD) & anti(WaterVeto) 0000FF07 65287 15.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 10966. Short description of all actions which were done on HERA during this run::from 22:50 to 23:30 22:45 There are two beams at HERA 22:51 The start of ramping of the electron beam up to 26.5 GeV 22:55 The end of ramping 1 22:57 ---> Collisions 23:05 ---> Increasing of Luminosity but the backgrownd at VETO increases to 2 times and very high proton beam lost 23:20 The electron orbit was changed 23:37 The electron beam was kaputt. Time table for the intensity of beams. 22:50 I(p) = 138 mkA, N(electron) = 3.71 * 10 ** 10 22:55 I(p) = 131 mkA, N(electron) = 3.68 * 10 ** 10 23:00 I(p) = 80 mkA, N(electron) = 3.62 * 10 ** 10 23:15 I(p) = 59 mkA N(electron) = 3.57 * 10 ** 10 23:30 I(p) = 46 mkA, N(electron) = 3.51 * 10 ** 10 22:35 I(p) = 42 mkA N(electron) = 3.46 * 10 ** 10 23:40 I(p) = 40 mkA --------------------- 16.11.1991 ==================== H1KSHE === New threshold for ET..... The IBM record time cavers the last 18 min. of the beam run only. During this period there were e-p collisions with stable rates for triggers: ET&PD - ~160 Hz (bacground ~40 %(online data)) ET&PD&noVC ~16 Hz (--"-- ~40% ---"---) Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 15.11.1991 at 23:20:21. End of Run - 15.11.1991 at 23:38:01. Number of events: 21080 Trigger: ET&PD&noVC - First 10 min of run, ~10.000 events Unknown trirrer(mistake) - next 3 min ~10.000 events ET&Calo&noVC&noPD - Next ~5 min rate ~ 0.8 Hz.!!! I very ask for S.Levonian to test the first 10.000 events becouse of threshould for ET was changed from 12 to 16 and according my obser- vation the component with zero energy events must considerable be less. 16.11.1991 ==================== H01USA === Collisions with 2 bunches THIS NIGHT SHIFT WE OBSERVED FIRST GOOD COLLISIONS WITH TWO ELECTRON BUNCHES ( #0 & #61 ). We used our H1LUMI monitor in HERA control room for displaying rates for this two bunches separatly. Third curve was the same - rate from water counter. time Ip Ne1 NeS Rwc R#0 R#61 Comments _____________________________________________________________________ 6:06 188 2.345 4.5 1941 11.6 11.0 Trigger for R#0,R#61:ET&PD&Awc Ee=26.5 GeV, Ep=480 GeV centering of beam profile Result: =0.08 cm sigmax**2=2.63 =0.06 cm sigmay**2=0.43 6:13 188 2.340 4.5 2109 10.1 9.2 Wait when something will be 2083 10.2 10.5 done in Zeus 2078 10.2 9.5 6:19 189 2.320 4.5 2084 12.6 9.3 first attempts to make collis. 2166 12.9 13.4 2159 9.6 11.4 6:26 188 2900 28.0 12.0 COLLISIONS !!!!! 6.40 174 2.246 4.4 2752 27.9 13.9 6:51 150 2.220 4.4 2556 19.75 12.7changing of profile: =0.51 cm sigmax**2=2.40 =-0.06 cm sigmay**2=0.39 L = 7.1*10**27 cm-2 sec-1 7:03 120 2.180 4.2 ................................. ______________________________________________________________________ Ip - proton beam current, uA Ne1 - number of electrons*10**-10 in bunch #0 NeS - number of electrons*10**-10 at all Rwc - rate from water counter,Hz R - rate for bunch #0 R - rate for bunch #61 1 16/11/91 === H1KSHE == Run 10968 = First two e-bun.and one p-bun.Coll. This hight at last our blue dream about two-e and one-p collisions is happend. The current discrepancy betweeng two e-bunches was not more then several per cent. The numbers of filled e-bunches are:0, 61 Trigger ET&PD&noVC Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 16.11.1991 at 05:48:21. End of Run - 16.11.1991 at 06:42:01. Number of events: 101447 This run was accidently aborted becouse of some online manipulations. 16/11/91 === H1KSHE == Run 10969 = Continue of the previos RUN = This Run is simply continue previos accidently interupted Run 10968. Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 16.11.1991 at 06:48:58. End of Run - 16.11.1991 at 09:45:00. Number of events: 856755 Triggers: . ET&PD&noVC - from 06:48:58 to 07:00:00 at ~06:56 the LRTC bank was added. MultiTrigger (5 triggers, 2 sec. period) 07:00 - 07:06(30.000events) at 07:08 LRTC is on at 07:32 is off PD*ET from 07:34 to end of run. Unfortunetly it was not possible to switch MultiTrigger for more long time becouse of permanent monitoring for HERA and also was not possible to stop IBM record (856755 events is too mach) for the same reason. 16.11.1991 ==================== H1KFOM === New Release of OnLine ... From this day it is available the next release of OnLine Program for H1Lumi. Its name is H1LumiOnLineFIFOnew2. This release can work as a previous release but: 1) It can get grom Egor's bunch counters (31 x 220) information for monitoring of rates of appeared candidates to Brems.events at two different bunches (for trigger SumET&SumPD). This two counters are put into the next addresses of DPM of FIC (it is imporatant for mointoring facility): B002B2A8 - counter for Bunch 1 (bunch 0 at the last time) B002B2AC - counter for Bunch 2 (bunch 19 at the last Run) Bunch 1 and Bunch 2 are changed (if it is needed) at "ETBooking" card of "CTrigger"-menu 2) It can work at Mode 6 and produce the profiles for monitoring at HERA Control Room (earlier it was impossible for this mode). 3) Default - mode 6, multitrigger mode (after 2 sec. it must be switched 5 different triggers - SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVeto) .OR. SumET&anti(PD)&anti(WaterVe- to), LRTC and LRTF banks switchoffed, DEEP = 1 (for garanty of trigger switching which are made at BG-area), bunches for monitoring and creation window at LRTC 0 and 19, all 62 windows for LRTC bank (if somebody will wish to switch on this bank). I hope that this release will be useful today for data taking with very short events with .OR. trigger (from Levonian phone request) and without any problems for monitoring of situation at HERA Control Room. 16.11.1991 ==================== F11LEV === Data quality,future tasks Some critical remarks concerning current LUMI run. ------------------------------------------------- Content: brief preliminary conclusions based on the offline analysis of the LUMI data taken before 15/11 (up to the run 10898 incl.) Aim: correct run strategy in order to do all our best in the time left to the end of the HERA run (December 2?) Introduction ------------ Gentlemen, let me first remind you our original task list which has been worked out after several discussions on the basis of the July run experience. 1) Improve and hopefully finalize calibration procedure using recon- structed energy in Electron Tagger (which was not possible in July setup) 2) Realise and test multitrigger mode (online h/w and s/w) 3) Prepare and include in the system 220 counters for an independent monitoring of all bunches. 4) Estimate efficiencies of all trigger elements (and understand reasons for possible inefficiencies) mainly for two our basic triggers: LUMINOSITY: ET * PD * noVC PHOTO CANDIDATES: ET * no(PD + VC) 1 5) Finally, measure real ep-luminosity and try to understand all sources of background in order to estimate systematic error and extrapolate it to the final HERA beams (30x820 GeV, L=10**31) 6) We also wanted to clearify our possibilities for the photoproduc- tion study: a) background to the "photo candidates" trigger and b) systematic errors due to the ET-acceptance and energy resolu- tion. Where are we now? ----------------- First of all, there was one default assumption, namely that ALL THE PROBLEMS WHICH WERE SOLVED OR UNDERSTOOD DURING/AFTER JULY RUN HAVE BEEN SOLVED FOREVER. At least it was my understanding. Now I must admit that it was by far too optimistic point of view. I will illustrate this later. A) Our positive achievments. --------------------------- 1) It has been proven, that H1 LUMI system is able to detect ep- collisions and measure luminosity (with sofar big systematic errors however) (Everybody). 2) Connection line between H1 and HERA control room has been established and all necessary information for the efficient e-beam tuning and ep-collisions detection is regularly transfer- ring (A.Usik). 3) 220 h/w counters have been prepared by I.Sheviakov and together with A.Fomenko implemented in the system. Correspondent informa- tion is too long and complicated to be included in each event, but suitable for the Run-end record, as it was originally planned 4) Although a real multitrigger mode is not yet possible, some s/w ersatz providing at least 50% of the wanted possibilities is now available (Fomenko, Sheviakov). 5) Some additional trigger signals from foreign (Korbel's) system are included in the LUMI trigger, allowing to test first combined trigger (LUMI + something in H1) for the eventual total photopr. cross section estimation, or at least to perform some useful backgroung study (I.Sheviakov). B) Problems, open questions. --------------------------- 1) Connection and data transfer from H1 Mac to the HERA Mac is done in a very preliminary and non-optimal way, which prevents our own studies during beam monitoring. According to the expert's remarks (E.Deffur) it can and must be done such, that will not block completely host computer and thus allow simultaneous work of H1 LUMI system (including data taking and recording them on IBM) and beam monitiring from HERA control room. 2) No single action have been taken with respect to calibration procedure. Presently c.c. are not stable, typical variations are of the order of 25-30% during one long (2-3hours) run. Since our detector experts have no definite program, proposals and may be even strong opinion on that, I must assume that this is our best possibility and will estimate all systematics taking into account 25% absolute calibration accuracy for single counters. 3) Reconstruction of the real data in ET has shown another problem which is somewhat new for us: coordinate reconstruction algorithm is badly working, or inconsistent with the detector properties. This may have catastrophic consiquences for the final setup, if the same will happen at Photon Detector. By the way, if one would have more detailed look into July and November data, it becomes clear immediatelly, that similar problem exists also for the present PD, but due to the small number and big size of cells in most cases it is simply hidden. 4) Comparing latest and July data, I found several important diffe- rencies: a) there is a stable background at ET (around E(e)=5-6 GeV for 26 GeV primary energy) which corresponds approx. 10-12 GeV at Ph. Detector, giving total energy of the order of 18 GeV. This background veries from run to run between 10% and 20% depending also on trigger used. b) Practically all single triggers (ET, PD, VC) give a lot of "empty" events, i.e. have large peaks at zero energy (false triggers). Even 2-combinations also give this "empty" events (e.g. our LUMI trigger at this run: ET * PD has from 5% to 25% of such background). It still has to be studied more carefully. What I can say now is that sometimes additional trigger element noVC helps, sometimes rejection of events by the requirement: abs(x_ET)<6.6 cm also reduces this sort of the background. It never happend in July run, moreover, at that time any detector, being included in the trigger immediately applied a sort of threshold,so such we never observed energies below 3-4 GeV at this detector. And for Lumi triggers (ET*PD, or ET*PD*noVC) we automatically rejected low energy parts in both branches: ET and PD. Anyway, now we have to apply a correction factor to our Lumi value measurement of the order of 20-30%: L(true) = L(meas) * (0.80+-0.10) where L(meas) = R(lumi)/sigma, as discussed in one of the above messages in our Logbook. If this background will not be understood I have to attri- bute it to the systematic error in our Lumi determination. 1 5) Threshold study at ET (runs 10851-10857) showed extremely strange behaviour, and generally even at th=52 (in online units) "zero" peak was present. One explanation for all these things(Sheviakov) is that trigger timing in not optimized in this run, which toge- ther with worse e-beam quality leads to this kind of "background" It is not completely clear for me (since e-bunch "length" is any- way very small: 0.03-0.1 ns, so how timing could help? Only if one assumes that there is "e-halo" having time length comparable with the trigger window of the order of 10 ns?). However, I agree that time tuning is an important task in order to if not improve, but at least understand what is going on. Conclusions and proposals. -------------------------- Please, keep in mind the following important events (milestones, as Fomenko likes to say): 20-22/11/1991 H1 physics and technical plenary where H1 community expect from us (and I have to report on that): a) where we are with the Luminosity measurements, b) where we are with the total photopr. x-section 1-2/12/1991 End of the ep-run March/1992 Start of the ep-physics at HERA So, we have a unique chance at the last time before serious physics try to clearify all uncertain points with our system. For this I propose: 1) Since we anyway have to share ep-collision time with the ZEUS, it gives us very good possibility to perform our own study without destructive interference with the beam monitoring. I think, our best work and measurements do not require collisions, we just need e-beam. So, first proposal: during collisions in ZEUS area switch off Mac II in HERA control room and do not allow even touch any button on it! Use this time for stand alone e-beam measurements and online tuning. 2) At these periods (no collisions at H1) do the following work: a) trigger timing (responsible E.Sheviakov, who defines all neces- sary actions and has highest priority during this particular shift(s)); b) perform once more online calibration and change content of LREC and LRPC banks according to the new result; align before HV on all counters if necessary (responsible A.Usik); c) record e-gas data for the offline analysis in the priority: - pure luminosity (immediately after online calibration) with the trigger ET * PD * noVC (15K events) - big run in a multittriger mode with the following triggers included: ET PD VC ET * PD rough lumi trigger ET * PD * noVC pure lumi trigger ET * noPD * noVC photo candidates 120-150 K events. It would be nice to have LRTC bank at the beginning and at the end of this run; for each event - too much information - difficult to process. One possibility: include LRTC bank in the Run_Start record, and then to write immediately after this long run another short run (e.g. VC only) and i will compare LRTC bank from these two runs in order to get relevant information); d) try to calibrate thresholds at least at ET in region 0-10 GeV This should be also written to the IBM (minimal bank set, 10K event per threshold, 4-5 points); d) at the end of the HERA run, if high intensity stand alone e-beam will be available take one long run (120-150 K events) with two trigger included: ET * PD and ET * PD * noVC. This could give us an additional information about a behaviour under high loading rates (e.g. how c.c. are changing with a time). 3) During collisions in H1 area write runs with a minimal set of banks (which still allow beam monitoring for HERA people) for triggers: ET * PD and ET * PD * noVC (2-trigger mode) Start IBM runs only after e-beam ramping!!! This is general require- -------------------------------------------------------------------- ment for all data which you put to IBM cartridges! -------------------------------------------------- In case of L reaching 10**28 or more, coordinate efforts with Korbel team and write combined runs with a trigger: ET * noPD * noVC * VetoWall and ET * noPD * noVC * Calo In these runs include LRTC bank to the output also! Note, that for further offline analysis we need data from Korbel's detectors also, therefore make sure, that they are writing their data via own Mac II (just call them and remind). 1 4) I also propose for Malinovsky and Usik to start think about: a) how to improve space reconstruction for hodoscope detectors, please recall your previous experience, look into literature, etc b) dynamical corrections for cal.coeff. (if c.c. themself are not stable, may be some functional dependence on rates may be used with another set of coefficients which ARE stable) c) what should be done in order to replace Alternative detectors by KRS and start in March with a main detectors. Final remark. ------------ So far (this is my own opinion) current run was successful more from political point of view rather than for understanding of our system. A.Usik was very good in front of dozens of photocameras, also LPI group has got a great publicity. Let now make an effort to finish this run with a good technical (if not physical) results. May be from time to time A.Usik and E.I.Malinovskij could come to the NH to help our poor guys Fomenko and Sheviakov, when no collisions in H1 happens, and they are not needed in HERA control room. 16.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 10971. Short description of all actions which were done on HERA during this run::from 17:50 to 20:00 18:30 There is only the proton beam at HERA 18:33 The injection of first bunch (number 19) 18:44 The injection of second bunch (number 0) 18:55 The start of ramping of the electron beam up to 26.5 GeV 19:01 The end of ramping 19 05 The start of the proton beam scan 19:32 ===> Collisions 19:50 The action at ZEUS's holl 20:00 The electron beam was kaputt. Time table for the intensity of beams. 18:30 I(p) = 158 mkA, 18:45 I(p) = 159 mkA, N(e,O bunc) = 3.56 * 10 ** 10 N(e,19 bunc) = 3.48 * 10 ** 10 N(total at ring) = 8 * 10 ** 10 19:10 I(p) = 159 mkA, N(e,0 bunc) = 3.28 * 10 ** 10 N(e,19 bun) = 3.20 * 10 ** 10 N(e.total) = 7.40 * 10 ** 10 19:40 I(p) = 156 mkA N(e,0 bunc) = 3.12 * 10 ** 10 N(e,19 bunc) = 3.02 * 10 ** 10 N(e,totalnc) = 7.00 * 10 ** 10 19:55 I(p) = 155 mkA N(e,0 bunc) = 3.08 * 10 ** 10 N(e,19 bunc) = 2.98 * 10 ** 10 N(e,19 bunc) = 6.90 * 10 ** 10 20:00 I(p) = 153 mkA --------------------- 16.11.1991 ==================== H1KFOM === Runs 10971,10973 ........ Run 10971. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 16.11.1991 at 19:12:05. End of Run - 16.11.1991 at 20:03:23. Number of events: 247973(mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC This Run was began with e-beam energy 26.5 GeV and with collisions after some time. Run 10973. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) .OR. SumPD&SumET Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 16.11.1991 at 20:33:32. End of Run - 16.11.1991 at 22:08:53. Number of events: 505016(mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC This Run was began with e-beam energy 26.5 GeV and withpure collisions after some time and without collisions up to end. At 22:06 it was switched on LRTC and LRTF-banks. At the some last events it is possible to find LRTC banks for all 31 groups with two windows (for 1st bunch and for 19th bunch). The size of this last events is 3.5-4 Kbytes. 16.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 10973. Short description of all actions which were done on HERA during this run::from 20:00 to 22:10 20:00 There is only the proton beam at HERA 20:03 The injection of first bunch (number 19) 20:11 The injection of second bunch (number 0) 20:21 The start of ramping of the electron beam up to 26.5 GeV 20:25 The end of ramping 1 20 27 The start of the proton beam scan 20:30 ===> Start of the trubles with LAN Because of this reason the Luminosity could be not achhieved, the HERA people had decided to study their own problems. 21:43 LAN is in order 22:03 The proton beam was kaputt 22:08 The electron beam was kaputt. Time table for the intensity of beams. 20:00 I(p) = 118 mkA, 20:15 I(p) = 117 mkA, N(e,O bunc) = 4.51 * 10 ** 10 N(e,19 bunc) = 4.25 * 10 ** 10 N(total at ring) = 9.2 * 10 ** 10 20:45 I(p) = 110 mkA, N(e,0 bunc) = 4.27 * 10 ** 10 N(e,19 bun) = 3.90 * 10 ** 10 N(e.total) = 8.60 * 10 ** 10 21:20 I(p) = 86 mkA N(e,0 bunc) = 4.02 * 10 ** 10 N(e,19 bunc) = 3.90 * 10 ** 10 N(e,total) = 8.10 * 10 ** 10 21:40 I(p) = 70 mkA N(e,0 bunc) = 3.89 * 10 ** 10 N(e,19 bunc) = 3.62 * 10 ** 10 N(e,total) = 7.80 * 10 ** 10 22:00 I(p) = 51 mkA N(e,0 bunc) = 3.71 * 10 ** 10 N(e,19 bunc) = 3.40 * 10 ** 10 N(e,total) = 7.60 * 10 ** 10 22:03 I(p) = 0 22:08 N(electron) = 0 17.11.1991 ==================== F11LEV === HV problem .............. After common discussion in the NH (Levonian, Fomenko, Sheviakov) we came to the following conclusions: 1) In many cases second peak for E_tot around 18 GeV (or populations in 2-dim plot "E_gam vs E_el" around E_el=5-6 GeV and E_gam=12 GeV) can be explained by the events with overflowing amplitudes at least in one of the ET and/or PD channels. We assumed that 2 counters most likely are "responsible" for this effect: ET(3) and PD(3) which have very different cal.coefficients compared to the rest (1.5-1.9 while "normal" channels have 3.3-4.0 MeV/ADC). This hypothesis has been confirmed today by the offline analysis of runs 10071, 10966, 10969). Indeed, all "bad" events having A=20000. (which means overflow) hit either ET(3) or PD(3) or both of them. The reason for such big difference in C.C. not yet completely under- stood (in case of ET interesting fact is that ET(3) was a central layer in previous July run and thus for a long time was under much higher rates comtared to other ET counters). Anyway, it is clear that first task is to reduce HV at these 2 coun- ters to the level excluding (or minimazing) number of "overflowed" events. 2) The phenomenon of "empty triggers" needs more detailed study inclu- ding low threshold calibration at ET and PD. It is not excluded, that corrections of HV will also improve trigger situation, since in general trigger is based on the total analog signals from ET and PD and thus also affected by bad high voltage. Difference between online and offline energy spectra is preliminary attributed to the specific online histogramming and has to be checked again in a first occasion. 18.11.1991 ==================== H1KFOM === Run 10975 ............... I am sorry but I forgot to write information about may be very important Run which was started at my shift and ended during Egor's shift. This Run have LRTC and LRTF banks at all events. And LRTC banks have all 31 groups with windows for each group. Size of events is very large - 3.5 - 4.0 Kbytes per event. Run 10975. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) .OR. SumPD&SumET Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 16.11.1991 at 23:38:24. End of Run - 17.11.1991 at 00:38:11. Number of events: 113008(mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC. This Run was began during existed ep-collisions and has information only about collisions. But I don't see any information about situation at HKR during this Run --> request to Malinovskii and Usik - find anything about this one hour of Run 10975. I know only that Ie(19th bunch) = 0.8*Ie(1st bunch) (from our BortZur- nal). 1 18.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 10975. Short description of all actions which were done during this shift :from 23:30 16.11.1991 to 00:40 17.11.1991 23:20 There is only the proton beam at HERA 23:22 The injection of first bunch (number 19) 20:25 The injection of second bunch (number 0) 23:30 The start of ramping of the electron beam up to 26.5 GeV 23:34 The end of ramping 23:40 Collisions ----> up to 00:47 when the beams were separated. Time table for the intensity of beams. 23:20 I(p) = 186 mkA, 23:25 I(p) = 186 mkA, N(e,O bunc) = 4.74 * 10 ** 10 N(e,19 bunc) = 4.25 * 10 ** 10 N(total at ring) = 9.1 * 10 ** 10 23:47 I(p) = 131 mkA, N(e,0 bunc) = 4.60 * 10 ** 10 N(e,19 bun) = 4.10 * 10 ** 10 23:55 I(p) = 116 mkA N(e,0 bunc) = 4.52 * 10 ** 10 N(e,19 bunc) = 4.00 * 10 ** 10 00:20 I(p) = 91 mkA N(e,0 bunc) = 4.32 * 10 ** 10 N(e,19 bunc) = 3.72 * 10 ** 10 N(e,total) = 7.80 * 10 ** 10 00:45 I(p) = 89 mkA N(e,0 bunc) = 4.18 * 10 ** 10 N(e,19 bunc) = 3.50 * 10 ** 10 N(e,total) = 8.80 * 10 ** 10 18.11.1991 ==================== H1KFOM === Run 10996 ............... Run 10996. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) Thresholds: SumPD 199/13, SumET 199/17, WaterVeto 8. Start of Run - 18.11.1991 at 18:33:00. End of Run - 18.11.1991 at 18:58:42. Number of events: 32881(mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC. This Run was began during existed activity of p-beam. I saw at our BeamIntensity DA frequency of WaterVeto near 10-30 Hz. BunchIntensity DA showed intensity (for some from 5 triggers) between 200 and 210 bunches. At 18:48 I changed the begin of window2 at LRTC-bank (from 19 to 200). I think that Runs this type could be useful for background investiga- tion (through Egor's LRTC-banks) at our detectors during different activities of p-beam. May be it is rare situation which we must use. Only needed to look at HKR - which conditions of p-beam were.. Request to Usik or Malinovskii - know please and write into logbook the conditions of Run 10996. May be it will be needed. 19.11.1991 ==================== F11LEV === Latest data analysis..... Results of the offline analysis of runs 10971 and 10973 (multitriggers) ----------------------------------------------------------------------- General remark: Data quality is much better compared to the period bet- ween 8 and 15 November. Run 10973 better than 10971 - LUMI is improving? 1) "Zero" peak at Electon Tagger disappeared, it still there at Photon Detector. 2) (e-gamma) energy correlation plots for LUMI trigger are nice, total energy resolution is 4.2% for run 10971 and 3.7% for run 10973, with the same calibration coefficients determined in the run 10968. 3) Trigger inefficiency (in %) for gamma-vetoing (noPD * noVC): Run E_gamma > 12 GeV > 10 GeV > 5 GeV > 1 GeV ----- ------ ------ ----- ----- 10971 0.2 2.0 7.0 8.0 10973 0.1 0.9 2.0 3.0 which means that e.g. in run 10971 in 2% of events taken with trigger ET*noPD*noVC there was 10 GeV or more deposited in (VC+PD). I would be definitely satisfied with 1-2% above 1 GeV... 4) In run 10971 record luminosity has been achieved in H1 Interaction Region: L = (100+-10) Hz/(22.7+-1.)mb = (4.4+-0.5)*10**27 cm-2s-1 5) R(VC)/R(ET*PD) is also close to the expected value of 10: run 10971 (=8.0) and run 10973 (=9.2). This value by the way already before was ok (see data tables from Usik at 13/11 and 15/11). 1 Reminder: Urgent tasks: a) High voltage on ET(3) and PD(3) plus re- calibration; b) Trigger timing study; c) Threshold calib- ration; d) Understanding of gamma-vetoing inefficiency at the level of 2-7%. Is it normal? e) Providing our trigger signal for Korbel's team for eventual common runs at high luminosity (> 10**28). 20.11.1991 ==================== H1KFOM === LRTC-bank counters ...... I want to remind that Egor's counters which we used for creating of LRTC-banks must be multiplied on 2 for getting real rates. The second - at each LRTC window Egor used special shift for convinent of his activity (this shift is for today is 3) - at this case if You want to get counters from 0-banch at first window You must get the value of 4-th counter (0-bunch`s counter is disposed at the place of 3th bunch`s counter). And the last - from yesterday we see 1st bunch at our data (not 0th as earlier). This is the same bunch for accelerator people. Egor made some corrections at his H1LumiTrigger. Shift is 3 as early. Counters of 1st bunch (at our counts) of 0th bunch (at HERA people counts) must be found at 5th counters of the first window. 20.11.1991 ==================== F11LEV === Damned LRTC.............. I succeeded to retrieve reasonable rates from LRTC banks after Igor reminded me about 3-bunch crossing shift. However, I still have some problems with the first event in a run containing this bank: I always get unreasonably high rate for the time interval between run start and first appearence of LRTC. Perhaps something simple in the analysis program. I have no time to look into it more carefully because of the talks tomorrow and in Friday. But in general LRTC is unpacked now correctly and i will use it later in the analysis (very important for triggers cross checks!). Therefore, could you concider the possibility to make this bank a bit shorter (then it can be included to the recorded runs more often). In principle I do not see a strong reason to have all 31 combinations for 20 bunches now. a) for LUMI stand alone runs one may mask bits 3,4 and keep only VC,PD and ET trigger elements -> 7 combinations instead of 31 (for common trigger with Korbel hardware we need of coarse all 31) b) one could also think about optimization of number of bunches which are read out and included in LRTC, but if it is too much work, it is not worth while to do for such a small usage time (anyway, finally we will include full LRTC in the Run end record). 22.11.1991 ==================== H1KFOM === LRTB-bank (EndRunRecord). From this day it is available the new release of the On-Line Program for H1Lumi-subsystem. Its name is H1LumiOnLineFIFOnew4. This release can write new LRTB-bank into EndRunRecord. Contents of this bank are written at Egor's message from 29.10.1991 (H1KSHE - New Trigg. posib) ( Hard_Hist bank). Contents of this bank - 220 x 7 counters. Format of this bank is B16. 23.11.1991 ==================== H01USA === New HV setup ............ In the evening shift after all internal tunnings of electronics made by Egor attempts to allign channels responces ( or calibration coeffici- ents ) were done. Attempts - because we were limited by time ( electron beam was dumped at 23.00 - only p-beam in the following shifts ). Firstly we calibrated PD&ET detectors without S-channel of water counter ( trigger: PD&ET&(PD+ET)&AVwc ). In the first aproximation ( +-10% calibration coefficients were aligned: 0.94 / 0.92 / 0.93 / 1.17 ( PD 0-3 ) 1.19 / 1.12 / 1.1 / 1.03 / 1.05 / 0.94 / 1.06 ( ET 0-6 ) We changed only following HV: PD0 641V --> 620 V ( 0.739 -->0.94 ) PD3 737V --> 710 V ( 0.675 -->1.17 ) ET3 647V --> 590 V ( 0.454 -->1.03 ) From energy hist ( on DA Energy_Hist ) we have: = 26.4 GeV, sigma = 1.65 GeV ( for all statistic ), but FWHM/2.36 = 1.0 GeV. After this we fixed this CC and started to calibrate Swc but e-beam was dumped. Next time we must allign CC with accuracy some percents by tunning HV and then make energy calibration of descriminator's threholds. After this we'll install final lumi trigger with cutting sum energy on level +-3 sigma ( our dream ) and will be ready for measuring final big luminosity in this ep-frun. 1 24.11.1991 ==================== H1KFOM === Runs 11148,11149,11150... It was written three Runs due to some activity of p-beam. Run 11148 - clean test Run ( due to LRTB-bank appering as EndRunRecord Run 11149 - the same conditions but with large statistics. Run 11150 - the same conditions but with DeepNesting = 8. Run 11148. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) .OR. SumET&SumPD Thresholds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 24.11.1991 at 11:44:19. End of Run - 24.11.1991 at 11:58:05. Number of events: 2737 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11149. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) .OR. SumET&SumPD Thresholds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 24.11.1991 at 11:58:14. End of Run - 24.11.1991 at 13:41:01. Number of events: 31763 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11150. Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) .OR. SumET&SumPD Thresholds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 24.11.1991 at 13:42:28. End of Run - 24.11.1991 at 16:12:07. Number of events: 18476 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). DeepNesting = 8 (at two previous Runs DeepNesting = 1). 24.11.1991 ==================== H1KFOM === New Release of OnLine.... From today it is available the new release of the OnLine Program for H1Lumi subdetector. Its name H1LumiOnLineFIFOnew7. This release can make all that previous releases could make; 1) it prepares 5 different energy histos for Usik's DA "Energy_Hist_B" 2) it created BeamArchive at new memory Region: B0B00000 - B0C00000; 3) it created EndRunRecords with all 31 X 220 counters (very large LRTB-bank - 27424 bytes). 4) it can work under DeepNesting=1 (don`t try 2,3,..8). 25.11.1991 ==================== F11LEV === p-background in gamma arm From the run 11149 i defined some numbers for background at ET, PD and VC in presence of proton beam only. They have any sence in case if one would know what beam conditions were during this run (24-Nov, 12-14 h) Is there any possibility to restore p-beam intensity etc? All 220 bunches were present in LUMI events, almost equally populated (150+-10 events/bunch no). Energy spectra were characterized by the following numbers (i used new sets of c.c. from LREC and LRPC banks): Counter: VC PD PD_peak ET Total (ET+PD+VC) E_max(GeV): 1.0 21.0 5.2 11.8 22.0 Entry point distribution at PD is asymmetric either due to the p-halo is shifted towards higher vertical coordinates, or due to the over- estimated cal.coeff. for PD(2). Deposited energy per channel is almost identical for all 7 ET counters and quite different for PD channels: PD(0) = PD(1) < PD(3) < PD(2). Reason for that could be again either too big c.c. for PD(2),PD(3) or real energy distribution in p-halo. Trigger rates (summed over all 220 bunches): Name Trigger Rate (Hz) Comments ----- ------- --------- -------- VC 0.01-0.02 last 50 min show PD 0.01-0.02 2 times higher ET 0.00-0.004 rates compared to first 50 min. rough lumi ET*PD 0.0 pure lumi ET*PD*noVC 0.0 photo candidates ET*noPD*noVC 0.00-0.004 the same as ET (evident, since no coincidences) 1 Conclusions. ------------ 1) Rates at VC and PD are completely identical, showing that they are really originating from p-halo rather then from cosmics (this can be proved by comparing single VC and PD rates with VC&PD coiciden- ce rate, which i did not make). 2) From bunch structure it is impossible to say which bunch(es) in p- beam were really filled (if any). This means, that at this level of p-beam intensity proton halo is more or less uniformly distri- buted over the time. Some very small "peak" (not significant even at one sigma level) can be recognized around bunch no = 160-162). 3) Trigger rates can be extrapolated to the design beam intensity (and energy?) provided real conditions at this run will be available. 30.11.1991 ==================== H01USA === COLLISION WITH 10 BUNCHES The previous evening (29.11 after 22:00 ) we observe collision of 10 electron bunches with 10 proton bunches. Also we have 11-th so called 'empty' electron bunch. But intensities of electron bunches were not equal. From archive data we defined integral luminosity for 10 bunches ( comparing integral rate of rough lumi trigger with the rate during separation beam ): ~1.1 * 10**28 cm**-2sec**-1. Ip = 818 uA Ne = 14.4 10**10 Rwc ~= 17 kHz R& = 1800 Hz ( collison ) R& = 1540 Hz ( after separation ) In addition we observed in on-line the luminosity trigger rate for every bunch, f.ex. 153 Hz 72 Hz 99 Hz 198 Hz 112 Hz 119 Hz 130 Hz 145 Hz 160 Hz 150 Hz After this the Ethernet connection was broken ( ~ from 0:30 ) We have the same situation as in previous troubles : - no access to IBM and VAX - H1DAQstatus and our DA's didn't work - after rebooting of Mac it's possible to read information from H1 only ones or do one step in logging procedure. It was decided to use telephone connection but we haven't yet electron beam ... 30.11.1991 ==================== H1KFOM === New Release of OnLine.... From this day it is available the new release of the OnLine Program for H1Lumi-subdetector. Its name is H1LumiOnLineFIFOnew12. At this release it is possible to change the time of data taking of events with different trigger at multitrigger mode. With default this release put multitrigger mode with 8 Triggers: Trigger Data Taking Trigger Code (sec.) hex decimal 1) SumET only 1 FFF7 65527 2) SumPD only 1 FFDF 65503 3) SumET+SumPD only 1 FFFD 65533 4) SumET & SumPD 5 FFD7 65495 5) SumET & SumPD & anti(WaterVeto) 10 FF17 65303 6) SumET & anti(sumPD) & anti(WaterVeto) 10 FF07 65287 7) SumET & SumPD & anti(waterVeto) & SumET+SumET 10 FF15 65301 8) SumET & anti(SumPD) & anti(WaterVeto) & Calo 10 F707 63239 This release with default switches on LRTN,LRTC and LRTF banks. At each event this release create 22 windows for 11 group of trigger bits: Calo InVW SumET SumPD WaterVeto Group First window Second Window 0 0 0 0 1 1 56 67 0 0 0 1 0 2 56 67 0 0 0 1 1 3 56 67 0 0 1 0 0 4 56 67 0 0 1 0 1 5 56 67 0 0 1 1 0 6 56 67 0 0 1 1 1 7 56 67 0 1 0 0 0 8 56 67 0 1 1 0 0 12 56 67 1 0 0 0 0 16 56 67 1 0 1 0 0 20 56 67 Note: 0 - anti; 1 - notanti. 1 Bunch numbers (56 and 67) it is possible to change mannually at the cart "ETBooking" of NewFastLUMIMonitor. It depends from HERA people - which bunches will be get as "empty"(56th was yesterday) and "not empty" (67th-76th were yesterday). This release can create EndRunRecord with TSTC and LRTB banks after pushing "Stop Run" button at the H1 Central DAQ monitoring facility. 30.11.1991 ==================== H1KFOM === Runs for Thresholds Calib Today it was written 5 Runs for threshold calibration of our 3 Trigger Bit - SumPD,SumET and SumPD+SumEt. Data for this Runs was tooked with multitrigger mode (3 different triggers with 5 sec. period of trigger changing). At each Run You have information about behaviour of thresholds at 3 different trigger. We have short time for this and not finished this procedure. Beam was lost during data taking of Run 11435 when we started calibration of High Thresholds. Run 11427. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 199/90, SumET 199/70, SumET+SumPD 199/50. Start of Run - 30.11.1991 at 10:31:02. End of Run - 30.11.1991 at 10:46:00. Number of events: 7909 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11429. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 199/20, SumET 199/20, SumET+SumPD 199/20. Start of Run - 30.11.1991 at 10:47:34. End of Run - 30.11.1991 at 10:52:07. Number of events: 17494 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, and LRTB(at the last event). Run 11431. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 199/30, SumET 199/30, SumET+SumPD 199/30. Start of Run - 30.11.1991 at 10:53:39. End of Run - 30.11.1991 at 11:00:59. Number of events: 31584 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, and LRTB(at the last event). Run 11433. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 199/40, SumET 199/40, SumET+SumPD 199/40. Start of Run - 30.11.1991 at 11:02:11. End of Run - 30.11.1991 at 11:10:20. Number of events: 33437 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, and LRTB(at the last event). Run 11435. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 30/20, SumET 30/20, SumET+SumPD 30/20. Start of Run - 30.11.1991 at 11:12:04. End of Run - 30.11.1991 at 11:15:37. Number of events: 3386 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC. 30.11.1991 ==================== H1KFOM === Runs with 10 bunches..... Today from early morning to 09:58 it were written 9 Runs with first events with 10 bunches beams. Its numbers: 11412,11413,11414, 11415,11416,11417,11418,11422,11424. This Runs was written with different conditions, triggers, thresholds. Egor promised to write about Runs late. 30.11.1991 ==================== H1KSHE === Runs 11412-11424......... Run 11412. 10 p-bunches, 2 - 11 e-bunches.(e - 12 Gev) Trigger: SumET .OR. SumPD .OR. WaterVeto .OR. SumET&SumPD&anti(WaterVe to .OR. SumET&anti(SumPD)&anti(WaterVeto) .OR. SumET&SumPD Thresholds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 30.11.1991 at 06:20:00. End of Run - 30.11.1991 at 06:50:01. Number of events: 54639 (mode 6). 1 Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Comments: This data was recorded for estimation p-beam background, but beam conditions was very unstable. Number of filled e-bunches has being changed from 2 to 11 (first were fil- led the bunches 57, 67 and at the end of filling the 57, 67 - 76 bunches were runing) To check the valide No of filled e-bunches at 06:38 the multitrigger was switched OFF and PD&ET - ON (for online check). Probably, it is not so easy to extract relevant data from this Run. 30.11.1991 ==================== H1KMAL === COND. FOR RUN 11413-11414 6:20 There is only the proton beam at HERA 6:30 The injection of the ten electron bunchs 6:48 The start of ramping of the electron beam up to 26.5 GeV 6:52 The end of ramping 7:20 Collisions ----> ?????? No connection with H1 control room I(p) = 802 mkA - 6:40 I(p) = 800 mkA - 7:05 I(p) = 795 mkA - 7:25 I(p) = 750 mkA - 7:45 I(p) = 705 mkA - 8:00 N(e)total = 26.5 * 10 ** 10 - 6:40 N(e)total = 20.1 * 10 ** 10 - 7:05 N(e)total = 16.2 * 10 ** 10 - 7:25 N(e)total = 14.9 * 10 ** 10 - 8:00 N(e)total = 13.6 * 10 ** 10 - 8:00 N(e)1= 2.07 * 10 ** 10 - 7:15 N(e)1= 1.74 * 10 ** 10 - 8:00 The intensenties of all electron bunches were approximately identical at the begining of Run11412 - 06:50. ........................................................... Run 11413. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 57, 67 - 76 filled p-bunches: 67 - 76 Trigger: SumET & SumPD & noWaterVeto Threshoulds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 30.11.1991 at 07:05:36. End of Run - 30.11.1991 at 07:38:00. Number of events: 80110 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11414. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 57, 67 - 76 filled p-bunches: 67 - 76 Trigger: Multitrigger like in Run 11412 Threshoulds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 30.11.1991 at 07:39:57. End of Run - 30.11.1991 at 07:55:00. Number of events: 23986 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11415. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 57, 67 - 76 filled p-bunches: 67 - 76 Trigger: For first ~1300 events noVC&PD&ET, and then noVC&noPD&ET&Calo Threshoulds: SumPD 199/16, SumET 199/16, WaterVeto 8. Start of Run - 30.11.1991 at 08:01:50. End of Run - 30.11.1991 at 08:21:00. Number of events: 23986 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Comments: in this run it was attempt to collect Photo candidates. Very high level of so called zero component(~70%) was observed. This zero component has visible correlation with proton hallow timing ??? And low photon arm efficiecy was also observed. It was solved to change threshoulds for next Run. 1 30.11.1991 ==================== H1KMAL === COND. FOR RUN 11415-11417 I(p) = 707 mkA - 8:00 I(p) = 611 mkA - 8:20 I(p) = 575 mkA - 8:40 I(p) = 554 mkA - 9:00 N(e)total = 13.6 * 10 ** 10 - 8:00 N(e)total = 12.1 * 10 ** 10 - 8:20 N(e)total = 11.3 * 10 ** 10 - 8:00 N(e)total = 10.5 * 10 ** 10 - 9:00 N(e)1= 1.75 * 10 ** 10 - 8:00 N(e)1= 1.63 * 10 ** 10 - 8:20 N(e)1= 1.54 * 10 ** 10 - 8:40 N(e)1= 1.47 * 10 ** 10 - 9:00 Run 11417. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 57, 67 - 76 filled p-bunches: 67 - 76 Trigger: noVC&noPD&ET&Calo Threshoulds: SumPD 199/11, SumET 199/17, WaterVeto 6. Start of Run - 30.11.1991 at 08:42:42. End of Run - 30.11.1991 at 09:05:00. Number of events: 26011 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). 30.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 11422 I(p) = 490 mkA N(e)total = 9.2 * 10 ** 10 N(e)1 = 1.32 * 10 ** 10 P.S. Distribution of the electrons betweenbunches is next: N(e)0=1 N(e)1=0.81 N(e)2=0.8 N(e)3=1 N(e)4=0.86 N(e)5=0.73 N(e)6=0.7 N(e)7=0.52 N(e)8=0.33 N(e)9=0.25 N(e)10=0.2 ................................................................... Run 11422. 10 p-bunches, 11 e-bunches.(e - 26 Gev) Trigger: noVC&PD&ET&Summ(PD+ET) Threshoulds: SumPD 199/10, SumET 199/10, VC 6, Summ(PD+ET) 50/27 Start of Run - 30.11.1991 at 09:32:35. End of Run - 30.11.1991 at 09:43:00. Number of events: 21506 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Comments: In this run the Summ(ET+PD) trigger element was first time involved. 30.11.1991 ==================== H1KMAL === CONDITIONS FOR RUN 11424 I(p)= 470 mkA N(e)pilot = 1.45 * 10 ** 10 N(e)total = 8.8 * 10 ** 10 N(e)1 = 1.27 * 10 ** 10 N(e)2 = 1.2 * 10 ** 10 N(e)3 = 1.4 * 10 ** 10 N(e)4 = 1.15 * 10 ** 10 N(e)5 = 0.8 * 10 ** 10 N(e)6 = 0.65 * 10 ** 10 N(e)7 = 0.54 * 10 ** 10 Run 11424. (like previous, but with another threshoulds) 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 57, 67 - 76 filled p-bunches: 67 - 76 Trigger: noVC&PD&ET&Summ(PD+ET) Threshoulds: SumPD 199/17, SumET 199/17, VC 8, Summ(PD+ET) 50/27 Start of Run - 30.11.1991 at 09:47:25. End of Run - 30.11.1991 at 09:58:21. Number of events: 22051 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11456. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 56, 67 - 76 filled p-bunches: 67 - 76 1 Trigger: Multitrigger from 8 following triggers: Data Taking Trigger Code (sec.) hex decimal 1) SumET only 1 FFF7 65527 2) SumPD only 1 FFDF 65503 3) SumET+SumPD only 1 FFFD 65533 4) SumET & SumPD 1 FFD7 65495 5) SumET & SumPD & anti(WaterVeto) 1 FF17 65303 6) SumET & anti(sumPD) & anti(WaterVeto) 1 FF07 65287 7) SumET & SumPD & anti(waterVeto) & SumET+SumET 1 FF15 65301 8) SumET & anti(SumPD) & anti(WaterVeto) & Calo 10 F707 63239 Thresholds: SumPD 199/17, SumET 199/17, VC 8, Summ(PD+ET) 50/27 Start of Run - 30.11.1991 at 19:37:53. End of Run - 30.11.1991 at 19:49:45. Number of events: 17224 (mode 6). Banks presented at this Run - LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). No RunStartRecord at this Run 30.11.1991 ==================== H1KMAL === COND. FOR RUN 11456,11459 I(p) = 440 mkA N(e)total = 33.7 *10**10 .................................................................. Run 11459. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches: 56, 67 - 76 filled p-bunches: 67 - 76 Trigger: Multitrigger from 8 following triggers: Data Taking Trigger Code (sec.) hex decimal 1) SumET only 1 FFF7 65527 2) SumPD only 1 FFDF 65503 3) SumET+SumPD only 1 FFFD 65533 4) SumET & SumPD 1 FFD7 65495 5) SumET & SumPD & anti(WaterVeto) 1 FF17 65303 6) SumET & anti(sumPD) & anti(WaterVeto) 1 FF07 65287 7) SumET & SumPD & anti(waterVeto) & SumET+SumET 1 FF15 65301 8) SumET & anti(SumPD) & anti(WaterVeto) & Calo 10 F707 63239 Thresholds: SumPD 199/17, SumET 199/17, VC 8, Summ(PD+ET) 50/27 Start of Run - 30.11.1991 at 20:26:09. End of Run - 30.11.1991 at 21:13:00. Number of events: 52089 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). The next runs was recorded for THE UP thresholds calibration Run 11471. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 40/20, SumET 40/20, SumET+SumPD 40/20. Start of Run - 01.12.1991 at 04:57:21. End of Run - 01.12.1991 at 05:02:02. Number of events: 10058 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11473. Trigger: SumET .OR. SumPD .OR. SumET+SumPD with 5sec. period of trigger changing. Thresholds: SumPD 30/20, SumET 30/20, SumET+SumPD 30/20. Start of Run - 01.12.1991 at 05:04:34. End of Run - 01.12.1991 at 05:08:01. Number of events: 10198 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC. LRTF,LRTC and LRTB(at the last event). 01.12.1991 ==================== H1KFOM === Run 11479 ............... Run 11479. 10 p-bunches, 11 e-bunches.(e - 26 Gev) filled e-bunches:136, 67 - 76 filled p-bunches: 67 - 76 Trigger: Multitrigger from 8 following triggers: Data Taking Trigger Code (sec.) hex decimal 1) SumET only 1 FFF7 65527 2) SumPD only 1 FFDF 65503 3) SumET+SumPD only 1 FFFD 65533 4) SumET & SumPD 1 FFD7 65495 5) SumET & SumPD & anti(WaterVeto) 1 FF17 65303 6) SumET & anti(sumPD) & anti(WaterVeto) 1 FF07 65287 7) SumET & SumPD & anti(waterVeto) & SumET+SumET 1 FF15 65301 8) SumET & anti(SumPD) & anti(WaterVeto) & Calo 10 F707 63239 1 Thresholds: SumPD 199/17, SumET 199/17, VC 8, Summ(PD+ET) 50/27 Start of Run - 01.12.1991 at 12:00:55. End of Run - 01.12.1991 at 12:14:48. Number of events: 19462 (mode 6). Banks presented at this Run -LREC(?),LRPC(?),LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). May be no StartRunRecord (LREC,LRPC) 01.12.1991 ==================== H1KMAL === Remarks for Run 11479 ... I(p)= 84 mkA , N(e)total = 13.7 *10**10 N(e)pilot = 1.9 * 10**10 N(e)1= 1.42 *10**10 N(e)(k+1)= N(e)(k) - dN N(e)10 = 1.0 *10**10 01.12.1991 ==================== H1KFOM === Bit Error at DPM ........ Today morning something happened with second (high) Megabyte of our DPM which was used for BeamArchive taking. Test of this memory showes that there is bit error from address B0B00000 (as You see from MacII) or D0B00000 (as You see from FIC). Problem was resolved with creation of the new releases of fourth desk accessories (b09H1LumiMon_10B, Bunches_b09, Energy_B09 and Intensity_b09) by Sasha Usik and creation of the new release of the OnLineProgram (H1LumiOnLineFIFOnew15). Now the beam archive is written into the second (high) Megabyte of the Bill's DPM which are used for VME-taxi (B0900000 - B09FFFFF). 01.12.1991 ==================== H1KFOM === New Release of OnLine.... From this day it is available the new release of the OnLine Program for H1Lumi subdetector. Its name is H1LumiOnLineFIFOnew16. This release can all that earlier releases could make. New features: - StartRunRecord must be written always (at earlier releases there was threshold of L2Keep frequence for this); - Before Start Run all HW bunch counters (31 x 220) are cleared obligatory (at previous release it was possible only due to reload of the OnLine Program; - It is possible to clear (31 x220) counters manually through special button at "BunchStatistic" and "Trigger_Stat" cards; - BeamArchiv is written into B090000-B09FFFFF memory. 02.12.1991 ==================== H1KMAL === CONDITIONS FOR RUN 11505. Short description of all actions WHICH WERE DONE DURING THIS SHIFT :FROM 21:50 01.12.1991 TO 00:10 02.12.1991 21:50 THERE IS ONLY THE PROTON BEAM AT HERA(10 BUNCHES) 21:55 the injection of the electron bunches (12 + 1) 22:02 The start of ramping of the electron beam up to 26.5 GeV 22:08 The end of ramping There are collisions from the end of ramping 22:45 The separation of beams for 2 min 23:11 The separation of beams for 7 min 23:28 the check of a new control file for e-beam when the beams were not separated. 00:08 the proton beam lost 21:48 I(p) = 1485 mkA, 21:55 n(bunches)=13,, N(e,1 bunch) = 2.23 * 10 ** 10 N(e,pilot) = 0.875*N(e,1) N(total at ring) = 26.6 * 10 ** 10 22:25 I(p) = 1355 mkA, N(e,1 bunc) = 1.95 * 10 ** 10 N(e,pilot) = 0.8 * N(e,1) N(total at ring) = 20.4 * 10 ** 10 22:30 I(p) = 1306 mkA N(e,1 bunc) = 1.83 * 10 ** 10 N(e,pilot) = 0.8 * N(e,1) N(total at ring) = 19.7 * 10 ** 10 22:40 I(p) = 1196 mkA N(e,1 bunc) = 1.83 * 10 ** 10 N(e,pilot) = 0.8 * N(e,1) N(e,5) = 1.47 * N(e,1) N(e,8) = N(e,9) = N(e,1) N(e,2) = N(e,4) = 1.2 * N(e,1) N(e,3) = 0.77 * N(e,1) N(e,10) = 0.95 * N(e,1) N(total at ring) = 18.0 * 10 ** 10 22:55 I(p) = 1073 mkA N(e,1 bunc) = 1.77 * 10 ** 10 N(e,pilot) = 0.78 * N(e,1) N(e,5) = 1.5 * N(e,1) N(e,6) = N(e,9) = N(e,1) N(total at ring) = 16.9 * 10 ** 10 23:20 I(p) = 926 mkA N(e,1 bunc) = 1.57 * 10 ** 10 N(e,pilot) = 0.83 * N(e,1) N(total at ring) = 14.5 * 10 ** 10 1 23:28 I(p) = 680 mkA N(e,1 bunc) = 1.43 * 10 ** 10 N(e,pilot) = 0.75 * N(e,1) N(e,total) = 13.2 * 10 ** 10 23:50 I(p) = 400 mkA N(e,1 bunc) = 1.30 * 10 ** 10 N(e,pilot) = 0.78 * N(e,1) N(e,5) = 1.45 * N(e,1) N(total at ring) = 11.4 * 10 ** 10 23:59 I(p) = 390 mkA N(e,1) = 1.29 * 10 ** 10 N(e,19 bunc) = 3.50 * 10 ** 10 N(e,total) = 11.4 * 10 ** 10 02.12.1991 ==================== H1KSHE === Run 11505 ............... Run 11505. 10 p-bunches, 12 e-bunches.(e - 26 Gev) filled e-bunches: 53, 66 - 76 filled p-bunches: 66 - 75 Trigger: Multitrigger from 8 following triggers: Data Taking Trigger Code (sec.) hex decimal 1) SumET only 1 FFF7 65527 2) SumPD only 1 FFDF 65503 3) SumET+SumPD only 1 FFFD 65533 4) SumET & SumPD 1 FFD7 65495 5) SumET & SumPD & anti(WaterVeto) 1 FF17 65303 6) SumET & anti(sumPD) & anti(WaterVeto) 1 FF07 65287 7) SumET & SumPD & anti(waterVeto) & SumET+SumET 1 FF15 65301 8) SumET & anti(SumPD) & anti(WaterVeto) & Calo 10 F707 63239 Thresholds: SumPD 199/17, SumET 199/17, VC 8, Summ(PD+ET) 50/27 Start of Run - 01.12.1991 at 22:09:25 End of Run - 01.12.1991 at 23:48:00. Number of events: 164729 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). Run 11506. 10 p-bunches, 12 e-bunches.(e - 26 Gev) filled e-bunches: 53, 66 - 76 filled p-bunches: 66 - 75 Trigger: Multitrigger from 8 following triggers: Data Taking Trigger Code (sec.) hex decimal 1) SumET only 1 FFF7 65527 2) SumPD only 1 FFDF 65503 3) SumET+SumPD only 1 FFFD 65533 4) SumET & SumPD 1 FFD7 65495 5) SumET & SumPD & anti(WaterVeto) 1 FF17 65303 6) SumET & anti(sumPD) & anti(WaterVeto) 1 FF07 65287 7) SumET & SumPD & anti(waterVeto) & SumET+SumET 1 FF15 65301 8) SumET & anti(SumPD) & anti(WaterVeto) & Calo 10 F707 63239 Thresholds: SumPD 199/17, SumET 199/17, VC 8, Summ(PD+ET) 50/27 Start of Run - 01.12.1991 at 23:54:54 End of Run - 02.12.1991 at 00:20:00. Number of events: 37347 (mode 6). Banks presented at this Run - LREC,LRPC,LREE,LRPE,LRTE,LRTN,TSTC, LRTF,LRTC and LRTB(at the last event). 02.12.1991 ==================== H01USA === Last LUMINOSITY ......... Luminosity calculated from archive data ( DPM ) for the last run: 01.12.91 LUMI Ip,uA Ne*10**-10 22:12 L = 2.6 * 10**28 cm-2sec-1 1400 26.6 22:50 L = 1.0 * 10**28 cm-2sec-1 1073 16.9 23:11 L = 0.7 * 10**28 cm-2sec-1 980 15.6 that is worse in comparison with Friday run: L = 1.1 * 10**28 cm-2sec-1 818 14.4 05.12.1991 ==================== F11LEV === all latest data are lost Another bad news (I mainly report on bad news, sorry but...) According to Jan Olsson, all runs in the range 11400 - 11507 are lost forever, due to the error in copying procedure made by somebody last week. This means, that we never will analyse our perhaps most interes- ting and important data, taken with a correct HV in a multibunch HERA regime. It's pity... 05.12.1991 ==================== F11LEV === all data are recovered... Ok, now I can send around a good news: After some discussions and attempts to restore our data, Jan Olsson succeeded to recover all mentioned above runs. So, we still have a chance to analyse "our perhaps most interesting and important data, taken with a correct HV in a multibunch HERA regime." 1 09.12.1991 ==================== H1KMAL === Dosimeters .............. Today the HERA-tunnel was opened for visits. The dosimeters have been pulled out the tunnel and handed to Herr Hans Jenssen , Gr.D3 Room 1c 279A, t. 23-86 for checkup. 12.12.1991 ==================== H1KMAL === Dosimeters .............. The results of doses in dosimeters from D-group are the following: ET - Dosimeter # 1 (was placed inside electronic box) - < 10 cGy ---- # 2 (front plane,beam plane, post ) - 3200 cGy ---- # 3 (beam plane,near beam pipe, front plane of ET) - 1600 cGy ..................................................................... PD - Dosimeter # 4 (was placed inside electronic box) - < 10 cGy - - # 5 (right side of shealding near e-beam plane 32 cGy - - # 6 (PD, beamplane ,near e- beam pipe ) 29 cGy 13.12.1991 ==================== H1KFOM === Additional FIC8230 ...... Yesterday, 12.12.1991 Bill put into our subsystem the additional FIC8230 for LUMI-branch. Now we hope garantee rate of reconstruction LUMI-events near 9 Hz. Appearence of this FIC opens new posibilities for many another decision which was difficult to make with single FIC8230 at our subsystem. Additioanal MacVEE for our system is ordered long time ago and must be delivered soon. After this we can make monitoring of our system from two MacII. Moreover - Alan Campbell proposed to attempt using of RISC-board at our system for LUMI-event reconstruction. He promised that we can have incrementing of reconstruction rate with factor 10 or 17. Now we have agreement with him to do the first test of H1Lumi-reconst- ruction package at RISC-board for preliminary estimation of reconstruction rate at this new for us CPU. Yesterday the new FIC8230 was tested with our subsystem. All is OK. Nearest plans - to create release of task for this FIC with reconstruc- tion package for Luminosity events. 18.12.1991 ==================== H1KFOM === Two FIC8230 in operation. Yesterday it was attempted simultaneous operation of two FIC8230 with H1LumiOnLine-reconstruction package. As You remember one FIC8230 can achive for rate of ReadOut and Reconstruction H1Lumi events near 9 Hz. When two FIC8230 operated with this task - double rate was achived - near 18 Hz. Very interesting information was got from this test attempt - about posibility RTF-program to use own global dual-ported memory without changing of absolute addresses (this addresses from region 20000000-2007FFFF are tuned during LoadRTF operation and are became 20100000-2017FFFF for CPU number1 etc.). It is possible work without terminal (program is not waiting of finishing of printing at terminal). It is possible to exchange of some blocks of data between FIC's CPU through additional DPM (for example with region D0800000-D0BFFFFF). It is possible to use the same COMMON/HHPACK/ for HHPACK-package for both CPU. And it is possible to use too the different one. The next step which must be done - attempt to use one FIC with interrupt environment and the next without interrupts - only for H1LumiOnLine-reconstruction package. It seems possible to prolong some activity for decrementing of time per one H1Lumi event at H1LumiOnLineRec-package. I hope to get some profit with time per event due to some changing at Ass-sources of H1LumiOnLineRec-package's modules.