*********************************************************************** * * * PART 4 PART 4 * * * * H1 LUMI LOGBOOK * * * * EP-DATA TAKING JUNE-JULY 1992 * * * * 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.JUN92.AUG92' DEST LI1 OVFL OFF NOHEAD * * * * * The following commands allow to inspect earlier logbook parts: * * * * LL1 ........ list Part 1 of the Lumi Logbook: June'91 - Aug'91 * * LL2 ........ list Part 2 of the Lumi Logbook: Aug'91 - Dec'91 * * LL3 ........ list Part 3 of the Lumi Logbook: Jan'92 - May'92 * * * * S.Levonian Opened: 1/06/92 at 9:00 * * Closed : 17/08/92 at 19:00 * * * *********************************************************************** 01.06.1992 ===================== H01USA === Night lumi shift .......... In the previous day shift the first lumi for energies 820x26.7 GeV was achieved and now in the night shift this collision is still continu H1 and Zeus provide data taking for this collision. At last we change our "Rates monitor" on "H1 Lumi monitor" and calculate luminosity. Forchunatly electron beam this run had two bunches so we can use our algorithm. Max lumi was 1.4*10**27 (16:00) and fall down now (0:43) to ~ 0.4*10**27 cm-2 s-1. 03.06.1992 ===================== H1KFOM === 10 p-bunches .............. Today firstly at 1992 it was injected into HERA p-ring 10 bunches simultaneously (all had neigbour positions). At H1CTRIG this bunches was looked with numbers 215,216,217,218,219,0,1,2,3,4 at the first injection (it was fixed at 15:45) and 1,2,3,4,5,6,7,8,9,10,11 at the second injection (ramping was finished at 20:31 with Ip=670 mkA and Ep = 820 GeV. p-beam was lost at 20:43 during attempts to prepare magnets of e-ring for injection of 11 bunches. Bunch statistics before beam lost the next (after ramping finish): H1CTRIG - 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 max 47 WaterVeto - 213,214,215,216,217,218,219, 1, 2, 3 max 214 PD - 213,214,215,216,217,218,219, 1, 2, 3 max 4 ET - 218,219, 1, 2, 3, 4, 5, 6, 7, 8 max 11 Maximum of p-current which was looked today was near 1.26 mA (as I saw). 04.06.1992 ===================== H1KFOM === ep-collisions 10 x 10 ..... Tonight ep-collisions was existed (at seems) during e-beam and p-beam coexistance at HERA. e-beam ramping was finished at near 3:37 and after may be 2 minutes the first ep-collisions of 10 p-bunches with 10 e-bun- ches was fixed with our ET&PD-trigger rate (as was looked at the pic- ture from BeamArchive of H1Lumi). Before collision at 3:37 the rate of ET&PD-trigger was estimated as 1150 Hz - and during the first collisions - 1400 Hz. So - HERA had at this moment the current luminosity value near 1.0*10**28 cm-2s-1. It was existed the next bunches (from analize of events which were fixed with H1CTRIG) (at all BG-bunch - statistics is near 200 ev.): 0 - 12322 - 75.7% 54 61% 1 - 11911 - 73.1% 46 52% 2 - 13616 - 83.6% 50 57% 3 - 12740 - 78.2% 44 50% 4 - 12510 - 76.8% 38 43% 5 - 13419 - 82.4% 36 40% 6 - 16286 - 100.0% 88 100% 7 - 13322 - 81.8% 44 50% 8 - 11872 - 72.9% 34 39% 9 - 8589 - 52.7% 34 39% 10 - 470 - 2.9% - - 11 - 783 - 4.8% 13 30% 18 - 289 - 1.8% - 19 - 1188 - 7.3% 44 50% - pilot bunch 45 - 846 - 5.2% - 153 - 883 - 5.4% - 197 - 756 - 4.6% - 218 - 262 - 1.6% - 219 - 3756 - 23.1% 4 5% At right two columns are written bunch intensity values which were retranslated by Sasha Usik from HERA Control Room at near 6:35 from ZEUSLumi-monitoring system (we have not this information at H1Lumi - but it exists at H1CTRIG - extremly needed to get it through LAN - Sasha Usik said that tool for this is ready - delay from John Coughlan H1CTRIG-team member). It seems that that it was existed the next community of e-bunches: 219,0,1,2,3,4,5,6,7,8,9 (11 e-bunches) + 12th-pilot (with number 19). But it seems too that only 0-8 bunches were collided with p-bunches and bunch 219 (with low intensity). But not undestandable - why number of events from 9 bunch more then from pilot-bunch. May be during ep-Running something was changed with synchronization of bunches. But it seems impossible. May be number of p-bunches was not 10 but 11? During this Running of HERA H1Lumi had monitored at HERA Control Room three rate as graphic and 13 rates as table. On graphic pictures it was monitored two rates of ET&PD-events from 19th bunch (pilot bunch) and from 1st bunch (one from collided bunches which had the same start intensity as 19th one). Common rate of ET&PD events was monitored too. At table it was possible to look for rates of ET&PD events at the next bunches: 0,1,2,3,4,5,6,7,8,19 and three rate of above mentioned. During all period (as Sasha said) it was not looked any difference at rates of pilot and collided bunch (exept short period near 10 min between 5:40 and 5:50 this morning). It was preliminary concluded that ep-collisions do not exist at H1 interaction Point. But HERA-people (as late said Evgenio) was shure that collisions existed (with their non-direct measurements). After detail analisis of BeamArchive picture with linear scale graphic of ET&PD events rate from all bunches it almost clear that ep-collisions existed and at the first lines of this message it was done its current luminosity value. There were near 7 situation at this period when the beams were not collided - it is seen that line for beam-gas interaction is very clear from first uncolliding situation up to last. It were existed different periods with better luminosity for H1 IP - near 6 min at begin of Running, from 4:00 up to 4:30, from 5:40 up to 5:50 (this period was reflected at H1Lumi-monitoring system at HERA-control room - the rate of ET&PD-events from 1st bunch incremented - 19th - not), from 6:10 up to 6:15 and some else short periods. Tonight we could not measure the any Integral Luminosity values and Wrote to LRTL-banks of the H1Runs not right values. Problems under studying - it was the first work with 10 bunches. May be at future situation will be better. During this period (near 204 min.) it was written 6 H1 Runs (118 min): 21585 - 04:15 - 04:28 - ep-collision 21588 - 04:33 - 04:36 - ep-collision 21590 - 05:11 - 05:26 - no ep-collisions 21592 - 05:32 - 05:46 ETAG-trigger - first 1/2 Run without ep-col 21596 - 05:49 - 05:57 - last 1/2 Run without ep-col. 21597 - 05:58 - 06:59 - 5 periods without ep-coll. In principle all this Runs have LRTS-banks (near 700 at all Runs). It is possible to make the detail analisis at off-line what was with ET&PD-rates of 19th and 1st bunches and understand why HERA-people cannot see the collisions at H1Lumi-monitoring system. It was not understood at all details the behaivour of Lumi-branch at H1LumiOnLineRecNew19 program. All this are under studying. 07.06.1992 ===================== H1KFOM === ep-collisions 10 x 10 ..... Yesterday 06.06.92 from 07:56 up to 08:55 (near 60 min.) it were existed 2nd at this seance ep-collisions 10x10. It seems from BeamArchive picture that all this time ep-collisions were existed up to p-beam was lost at 08:55. It was very short collisions and with new for us situation - without clear evidence of beam-gas interaction - after end of ramping collisions existed. And only first evidence of beam-gas collisions was looked after p-beam was lost. Firstly at this seance we looked for strange (non-correlated with ET&PD events rate) behaviour if WateVeto-counter. It was fixed 5 clear jumps at rate of this rate on 20% to low level and return to previous level after some minutes. During this period it was tuned the luminosity at Sourth Area with ZEUS-lumi monitor. It was not under- stood why after p-beam was lost the clear jump of ET&PD rate was looked for but WaterVeto rate - without clear jump. In principle procedure for on-line calculation of luminosity values exists but due to of waiting for ep-collisions it was found that very important procedure for delivering of bunch intensities to our H1Lumi (which was tested succesfully at day before when beams was absent) put into H1Lumi p-bunch intensities (non e-bunch intensities). It was needed to put the values of intensities with hand (which were got from ZEUSlumi-people by Malinovski). After 20 min from begin of ep-collisions new values of intensities were inserted (as seems not valid) - at this time it was possible to look for jump at our value of measured Lumi - from 2-3*10**27 cm-2s-1 up to 1.0**10**28. Due to inserting of new addresses of counters for beam archive (one address - counter of ET&PD events from pilot bunch - B012B324 and second address - the same counter from collided bunch - B012B308) H1LumiOnline-program was crashed at 09:42 and after some unsuccesful attempts to reload and restart was excluded from H1CDAQ from near 10:00 up to 16:00. Due to this crach it was found two bugs at both OnLine program. Thanks to Usik for this manipulation with inserting of new addresses. Now bugs are fixed and H1Lumi again at H1CDAQ from 16:00 up to now without any problems. Now it is prepared the new tools so called "CollisionMonitor" which we hope will help to detect the status collisons and simply coexistance e- and p-beams. John Couglah today made some corrections and now we must get from H1CTRIG information about e-bunch intensity and e-beam coommon current. It was improved the procedure of online luminosity calculation. We hope that the next ep-collision will be detected without large problems not only after its finishing but at beginning. During yesterday day and this night it was access to HERA-tunnel. This access was prolongated on today morning up to fixing of some problems with HERA. 10.06.1992 ===================== H1KFOM === first p-beam after repair.. Tonight first attempt to inject p-beam began at 03:34. There were more then 20 attempts to inject p-beam (10 bunches) up to 07:00. Last attempt was succesful (Ip after injection was 960 mkA). After ramping (which was finished at 08:12) Ip= 560 mkA and Ep=820 GeV. Now at p-ring of HERA exists stable p-beam with 10-bunches. Its numbers (as seen with H1CTRIG) are 1,2,3,4,5,6,7,8,9,10. PD and WaterVeto saw bunch numbers as 213,214,215,216,217,218,219,0,1,2 ET saw bunch numbers as 218,219,0,1,2,3,4,5,6,7. At 08:43 p-beam was lost. 10.06.1992 ===================== H01USA === pilot method .............. Some data from the last collisions runnings from the view point of pilot method ----------------------------------- _______________________________________________________________________ RUN. |Ie_t|Ie_b|Ie_p|r1 | r2 |r/r?| Rt | Rp| RL| L/ Lexp|Ipr_t|scale f. ----------------------------------------------------------------------- 2 bun| 400| 200|200| 2 |2.4 |1.2 | 180| 75| 30| 1.26e27| 36.5| 31.05| | | | | | | | | | || 16:00| | | | | | - | | | | - || _______________________________________________________________________ 10bun| 529| 44 |44 |12.0|13.8|1.15| 663| 48| 85| 3.57e27| 470 | 3.1 04.06| |(n6=| | | | | | | | | 06:20| | 88)| | | |1.2 | | | | 3.92e27| _______________________________________________________________________ 10bun| 756| 55 |200|3.76| 5.6|1.5 | 692|123|200| 8.40e27|1170 | 8.8 06.06| |(n6=| ? | | | | | | | | 08:00| | 88)| | | |1.53| | | | 1.10e28| _______________________________________________________________________ 10bun|1000| 91 | 95|10.5|11.7|1.12| 687| 58| 70| 3.00e27| 380 | 4.74 11.06| | | | | | | | | | | | 18:48| | | | | |1.24| | | | 6.00e27| | _______________________________________________________________________ 10bun|1040| 95 | 90|11.4|13.5|1.18|1310|102|150| 6.30e27| 410 | 5.33 12.06| | | | | | | | | | | | 22:10| | | | |13.6|1. | | | | 6.70e27| | _______________________________________________________________________ where: Ie_t - total electron beam current, mkA Ie_b - electron beam current per bunch, mkA Ie_p - electron pilot bunch current, mkA r1= Ie_t/Ie_p - currents ratio r2= Rt/Rp - rates ratio r= r2/r1=Rtot/Rbackgraund (> 1+3sigma(r) means there is collision) r? - r expected (scaled to 2bunch running) Rt - total (for all bunches) rate of lumi trigger, Hz Rp - rate of pilot bunch, Hz L - calculated luminosity,cm-2s-1 Lexpected - scaled luminosity to 2bunch running (~ Ie_t * Ipr_t) Ipr_t - total proton beam current, mkA Conclusions: - Lumi rate is small in comparison with background - for sensetivity of small lumi it is necessary to reduce statistical contribution from pilot bunch (which is proportional to r1). It is possible by increasing of averaging time keeping relativly small time for total rate for fast monitoring. - it is necessary to monitor r1,r2 & r (DA "Collision monitor") 10.06.1992 ===================== H01USA === stat.error of lumi measur.. For the error of lumi rate (Rlumi = Rall - Rpilots * (IEall/IEpilots) ) measurements we have the following formula: sigma(Rlumi)= SQRT( Rc/Tc + Rp*rI**2/Tp + Rp**2 * (sigma(rI))**2 ) where Rc,Rp - collided and pilot bunch rates Tc,Tp - averaging time for calculation of Rc and Rp rI - ratio of collided bunches curent and pilot bunch current If we calculate collided bunches current as sum of bunches currents and they are approximaly equal,then (sigma(rI))**2 ) = (dIp)**2 * (rI+rI**2), where dIp = sigma(Ip)/Ip. Finally we have: sigma(Rlumi)= SQRT(Rc/Tc + Rp*rI**2/Tp + Rp**2 * (dIp)**2 * (rI+rI**2)) Let estimate it for first 10 bunches running: sigma(Rlumi)~ SQRT(610/5 + 50*10**2/50 + 50**2 * (10)**-4 * (10+10**2)) ~ SQRT(120 + 100 + 25 ) = 16 Remember that Rlumi = 85 Hz > 3 * 16, so we are sure that it was really lumi for Tc=5 sec, Tp=50 sec, dI=10**-2. 11.06.1992 ===================== H1KFOM === off-line Lumi analysis .... During of last ep-collisions 10x10 at 06.06.92 between 08:00 and 09:00 it were written 3 H1Run by F.Eisele which was H1 Shift Lieder at morning 06.06.92. Run 21828 - from 8:20:56 up to 08:21:20 with 458 events (near 24 sec.) Run 21831 - from 8:27:02 up to 08:36:33 with 10864 events (near 9 min. Run 21835 - from 8:52:14 up to 08:57:11 with 4233 events (near 5 min.) p-beam was lost near 8:54 (as seems directly from collisions status at H1 IP). As seems first two Runs were written during ep-collisions and the last - first 1/2 with ep-collisions and the last - without. Tonight it was processed all this Runs for testing of the existance ep-collisions during this period. New procedure which was proposed by Sasha Usik was used for testing. This procedure with shure confirmed that at this time ep-collisions were at H1 Interaction Point. It was calculated the ratios - Itotal/Ipilot and Ratetotal/Ratepilot during all this period. And it was calculated so-called "Lumi-functio- nal" - the ratio of first value and the second above mentioned. Really after p-beam was lost this "Lumi-functional" has the value near 1.0. Before this moment - near 0.85 and at during Run21831 - near 0.65. At time period between Run21831 and Run21835 something happened with pilot bunch - its intensity was decremented from 200 mkA to 120 mkA. It was got different vectors which are kept at LOOK`s data set H1KFOM.YLOOK.R21828. This pictures reflect behaviour of different values with time (LumiLocalTimer never resets and it is possible to see all this pictures on non-broken time period beetween 08:20 and 09:05. Example of Job for creating of this pictures is kept at H1KFOM.LUMI92J (#F110606) - data set. Before this job it was created privat cartridge with banks HEAD,HEAR, LRTN,LRTS,LRTL -banks from two cartridges on which above mentioned Runs are kept (#SELECT-data set at this library). 10.06.1992 ===================== H01USA === small remark about LF ..... In DA "Collision Monitor" and in previous messages it was used origiona lly the ratio r=r2/r1 = (Lumi Functional in off-line)**-1. So the values of r: 1.53 and 1.18. It agrees with "on-line" analisis if the value 200mkA for pilot bunch is used (1.50 for first run). 11.06.1992 ===================== F11LEV === LUMI offline news ......... A flash on the off-line LUMI news --------------------------------- 1) Calibration problem. -------------------- I tried to understand how stable is our online calibration using the method which I explained before several times (shift e- and gamma- arms globally). Or, in other words, how sensitive the calibration is to the small global shifts of ET and PD coefficients. Main reason for doing that: ET and PD spectra look systematically shifted although the total energy peak is correct. My study shows that it is possible to obtain much more realistic energy spectra for the price of 20% worse sigma in E_tot peak. Example: Calibration set sigma(E_tot) --------------------------------------------- online (25.05) 24.16 1.00 C(ET)=0.95*online, C(PD)=1.47*online 26.49 1.23 --------------------------------------------- Therefore, I put into database not online CC, but shifted ones. It seems, that "LUMI" branch and "DAQ readout" branch indeed have quite different calibrations, but my message is that ET and PD arms must NOT be simply scaled with the SAME factor, since online LUMI spectra show higher ET and lower PD spectra compared to the expected ones. ET spectrum from the "DAQ branch" looks almost ok since it is artificially shifted down, therefore further correction is very small (5%). PD spectrum however, must be considerably corrected because it is also shifted down by the "DAQ branch" while it should be moved towards higher energies, therefore here corrections are large (47%). My final impression is that one cannot blindly trust our online calibration, and presently I still have no idea how to solve problem generally... 2) New LUMI reconstruction. ------------------------ Since two weeks a new "improved" offline LREC module is running in the official H1REC. The problem of a previous version was bad coordinate reconstruction (for the real data, not for the MC!) which according to Usik (and Serpukhov preprints) is an immanent feature of any shower hodoscope. Briefly explaining, in the new version two different approaches are used: a) in case of a single particle (ET - always, PD - if E(VC)<0.3 GeV) a sharing function is used as before, but with shifted mean estimate: before: = f() where =A(i)/A(i+-1) now: = 0.5*{f(+d)+f(-d)} b) in case of shower before PD (E(VC)>0.3 GeV) one cannot use sharing function, since there is no single shower in the detector, but rather many hits. Therefore in this case a simple weighted mean value is used (center-of-gravity). Results (especially for PD, which was my main worry since it is used for the LUMI corrections) are encouraging. All dips in PD profiles disappear (on those samples I had available for tests). X-distrib. at ET still has very thin dips, but overall picture also has improved a lot. I will stop with that, and I think, that this version (or at least algorithms) should be implemented online at the first possibility. 3) Playing with our data I got an impression that the PD is situated not in the median plane of the e-ring, but rather shifted up on approx 1cm... Is it possible at all? And how this can be checked independently? Please pay attension on that during LUMI runs (keep an eye on the correspondence between ET and PD profiles). 4) I have several correlation plots between trigger energy and rec.en. for ET and PD. I still have some problems to understand them fully. Perhaps somebody from online should also look on these pictures. 5) I did not make a detailed analysis of LUMI data from all our LRTL, LRTS, etc. banks. But if one would plot online Luminosity curve from the LRTN bank, it shows the same problem as in November run: a simple subtraction of a pilot bunch gives higher luminosity than expected (see e.g. 10 bunch mode runs from 6 of June: after ep collisions were stopped the remaining luminosity was at the level of 6*10**27 = 50% of the collision value. 6) Once more: for the sigma-tot determination it is very important to control single rates of all trigger elements involved. And better for each bunch separately (see my note from January'92 in LLO). Therefore, we have to include in our trigger (or h/w counters) at least BPC (and if possible, ToF-IA). 12.06.1992 ===================== H1KFOM === ep-collisions 11.06.92 .... Yesterday from 18:17 up to 18:53 and from 19:23 up to 19:31 at H1 Interaction Point it was fixed ep-collisions of 10x10 bunches. Current Luminosity values were at this period between 4.8*10**27 and 2.9*10**27 cm-2s-1. It was fixed (two times) the best conditions for luminosity at H1 Interaction Point - at 18:25 (near 6.6*10**27) and at 18:50 (near 1.0*10**28 cm-2s-1). Bunch numbers which were involved into ep-collisions: 0,1,2,3,4,5,6,7,8,9. Pilot bunch number - 19. During this collisions it was tested new tools for Lumi-evidence and calculation. It seems that we got right values of bunch currents from H1CTRIG (thanks to Sasha Usik and John Couglagh) - this tool was inserted into new releases of H1_Lumi_Monitor desk accessories: "LumiMon#f2_cp" and "Lumi_Mon#f2_cpii". Due to inserting of averaging of rates (on iteration procedure) for blue line at H1_Lumi_Monitor - it was possible to look for the two rates (total ET&PD-rate and rate of pilot bunch) with almost equal fluctuation (this is the step forward) - this update inserted into "Lumi_Mon#f2cpii"-release of "H1_Lumi_Monitor" desk accessory. It was tested the new tool for evidence (or pointing on presence) ep-collision - desk accessory "CollisionMonitor" at which three famous ratios are monitored with time - R1=Itotal/Ipilot (green line), R2=RateTotal/RatePilot (red line) and R1/R2 - Lumi Functional at blue line. We could look for that before collisions R1/R2 was near 1.0 value and during collisions near 0.83 - 0.88. In principle this tool is useful. It was checked Energy distributions at Lumi-branch - now all is OK - there is no low energy component at ET-spectrum. Problem disappeared itself (without any tuning at H1Lumi). It was checked overflow situations at ET and PD-channels. It seems that all is OK. Only e21 (which is disposed more closely to e-beam) has near 4.4% of overflow situation. All another channels - not more then 1% (mostly 0.5-0.8). During ep-collisions it was written by Eisenhandler which was H1 Shift Lieder at this time 3 H1Runs: 22625 - from 18:19 up to 18:25 - during ep-collisions 22630 - from 18:30 up to 18:50 - during ep-collisions 22631 - from 18:51 up to 19:19 - during no ep-collision 22634 - from 19:30 up to 20:02 - after p-beam was lost After p-beam was lost it was posibility to use the rest of e-beam for H1Lumi-calibration: Run22636 - from 20:15 up to 20:33 (temporary logging) near 50 Kevents Run22637 - from 20:33 up to 20:36 (temporary logging) near 5 Kevents Run22638 - from 20:36 up to 20:47 (permanent logging)near 30 Kevents All this events are ET&PD&anti(WaterVeto) - candidates to Pure Lumi Events. ETAG-trigger bit was switched on this trigger and we used H1CTRIG for writting of this events at Mode 0. Scaler factor for ETAG was changed from 8192 to 0 (on the time of writting of above mentioned Runs). Due to Egor's recomendation Run 22637 and Run22638 were written with new FADC shifts (30ns shift to "left") - At Run22636 this shifts were 192(ET)/138(PD) at last two Runs - 189/135. But due to appearence of message from E.Elsen at H1Run pinboard it seems that this changing was made not right. It seems that shifts must be the same as at all previous time (after tuning of ETA-trugger-bit at 18.05.92). It is possible to test this with attempts of calibration on Runs with different shifts. It was new asking from H1 Run Coordinator (U.Goerlach) and HERA Run Coordinator (R.Felst) about posibilty to put into HERA Control Room of rates which would be averaged with 10 sec. time interval - and reload LAN (update - once per 10 sec. - not once per 1 sec as was earlier). This asking was realized by Sasha Usik at new relaese of H1_Lumi_Monitor with name 'LumiMon_11.06%". New option for control of the time averaging is appeared at Init-card - now it was installed on 10 sec (600 ticks). At the next release of H1LumiOnLineRecNew19 it would be installed Lumi Functional as R2/R1 (it was asking of Sasha Usik and HERA-people). It must be near 1.0 when collisions are absent and more then 1.0 when its exist. 12.06.1992 ===================== H1KMAL === Cart. for 22636, 22638 Runs It was made the prived cartriges for the next runs: Run 22636 --> H1KMAL.LUMI92.CAR22636 - 39996 ev. Run 22638 --> H1kmal.LUMI92.CAR22638 - 23600 ev. 12.06.1992 ===================== H1KFOM === Calibration Runs .......... Egor was right. Something happened with timing. First observation of energy distributions which are created from Run 22638 (old shifts) and Run 22638 shows very bad situation for us. Due to last changing with timing at H1CTRIG or HERA (I don`t know who is responsinle for this - Egors knows) our old calibration coefficients don't work with new Runs (last ep-collisions Runs too). First evidence shows the next: Run 22636 (old shifts - or shifts for old timing): ETrec+PDrec - mean value 19.35, sigma = 1.38, assymetry exists ETrec - between 6 and 12 GeV - additional peak at 15 Gev (as seems due to e21) PDrec - between 7 and 14 GeV (resonable shape) Run 22638 (new shifts - shifted on 30 nsec) ETrec+PDrec - mean value 25.39, sigma = 1.42, assymetry almost absent ETrec - between 7 and 14 GeV - additional peak at 17 Gev (as seems due to e21) PDrec - between 9.6 and 19 GeV (resonable shape). First conclusions: 1) calibration coefficients which inserted indo H1 Data Base are not valid for last ep-collisions Runs (too small); 2) we can make calibration on Run 22638 for ET and PD-channels but we have not Run with ET&PD-trigger at Mode 0 with new shifts for WaterVeto calibration; 3) it is possible to suppose that relative values of calibration coefficients were kept but first evidence that this is not so - e21-changing (at relative values with its neigbour); 4) e21-really has more then all other overflow situations - near 4.4% It is not undestandable - what can happen with this channel 5) first view on the PD-energy distributions per cell says that at this arm there are problems too;- 6) May be we must to repeat our calibration procedure 25.05.92 with moving of ET-table etc. But we need good e-beam with 26.7 GeV during 4-5 hours with posibility single using of CDAQ? 12.06.1992 ===================== F11LEV === PD position ............... Gentlemen, I am now almost sure, that our PD coordinate system is mirror-reflected w.r.t. H1 coordinate system. PD profiles from the run 22636 show =1.3, =-1.0, while 2-dim spot on PD and also 2-dim coordinate distribution at ET exactly correspond to the case: =-1.3, =+1.0, simulated by MC. If this is not an LREC "feature" then you should again check carefully online cannel connection in PD. Can you check with the old LREC (which I guess you are still using) and for this run? I will analyse the run 22638 and also look into the LREC code more carefully: may be there I reflect sign for PD coordinates? But I don't think so... Once more: I expect the following coordinate system and numbering: y(cm) 5 -|------------------------- | 20 | 21 | 22 | 23 | 24 | |----+----+----+----+----| | 15 | 16 | 17 | 18 | 19 | |----+----+----+----+----| 0 -| 10 | 11 | 12 | 13 | 14 | --> Center of |----+----+----+----+----| HERA ring | 5 | 6 | 7 | 8 | 9 | |----+----+----+----+----| | 0 | 1 | 2 | 3 | 4 | -5 ----------------------------> x(cm) -5 0 5 PD face plane when looking from the H1 IP (along e-beam direction) Can it be, that Malinovsky (or somebody else) put PD on the platform upside-down ("kverhu zopoj") ? This can be checked by moving PD platform down and watching in which direction beam spot at PD goes. 12.06.1992 ===================== F11LEV === Overflow at ET/PD ......... This is a table of overflow situations at ET and PD during last runs (not full statistics has been used): ------------------------------------------------------------------- Run # ET events # ET ovfl % # PD events # PD ovfl % ------------------------------------------------------------------- 22636 13298 758 5.7 12884 1325 10.3 22638 23511 1243 5.3 23494 2953 12.6 ------------------------------------------------------------------- Percentage of the overflows in different cells (see fig below) exactly corresponds to the hit intensity in the detectors: ET (central layers) PD +------------------------+ | | | | | | |----|----|----|----|----|----|----| |----+----+----+----+----| | | | | | | | | | | | | . | | |----|----|----|----|----|----|----| |----+----+----+----+----| | 99 | . | . | | . | | | | | . | 1 | 5 | | |----|----|----|----|----|----|----| |----+----+----+----+----| | | | | | | | | | . | 7 | 64 | 19 | | |----|----|----|----|----|----|----| |----+----+----+----+----| | | . | 2 | . | | +------------------------+ Run 22638 shows the same as previous one (even more prominent): =1.26, =-1.0 and 2-dim spot at PD is cut in such a way, that indicates PD-coordinate system reflection (X => -X; Y => -Y) Onliners, check the situation! 13.06.1992 ===================== H1KMAL === Vacuum and background ..... Short remarks about Vacuum at IP during beam operation: Is is known that number of bremsstsahlung events on residual gas depends on the vacuum at beam pipe. But vacuum conditions too are connected with the intensety of colliding beams. It means that we will have the higher backgrownd rate with the increasing of the colliding bunch number. The picture shows the experimental dependence of the residual gas bremsstrahlung rate from the elec- tron bunch intensety, which indicates a vacuum value for present conditions - I(E) = 0.4 mA, I(p) = 0.04 mA.- 2.0 x 10*(-9) mbar. _____________________________________________________________________ | | | | | | | |Hz - | | | * | |70 - | | | * | |60 - | | | | |50 - | | | * | |40 - * | | | * | |30 - | | | | |20 - | | | | |10 - | | | | | |____º____º____º____º____º____º____º____º____º____º____º__ Ie | | 20 40 60 80 100 120 140 160 180 200 (uA) | |___________________________________________________________________| Next information from last Runs may be usefull for estimations of the backgrownd level during beam operation. Beams intensety Vacuum at IP -10 No any beams at NERA - 1.2 x 10 (mbar) -9 I(p) = 1.1 mA - 2.9 x 10 (mbar) -9 I(e) = 0.4 mA, I(p) = 0.04 mA - 1.7 x 10 (mbar) -9 I(e) = 1.0 mA, I(p) = 0.4 mA - 5.5 x 10 (mbar) -9 I(e) = 0.6 mA - 5.0 x 10 (mbar) -9 I(E) = 0.5 mA - 4.6 x 10 (mbar) -10 5 min after beam lost - 7.0 x 10 (mbar) Note, that it aproximately corresponds to data from measu- ring from two different Runs: two bunches 31.05 and 10 bun- ches 12.06 : -10 31.05 P = 1.7 x 10 mbar R = 38 Hz (for Ie = 0.1 mA) -10 12.06 P = 5.5 x 10 mbar R = 128 Hz (for Ie = 0.1 mA) There is factor about 3.3 for the increasing of backgrownd and the vacuum condition changes. 13.06.1992 ===================== H1KFOM === ep-collisions 10x10 + 1 ... Yesterday, 12.06.1992, from 21:40 up to 22:45 ep-collisions were registered at H1 Interaction Point. It were collided 10 p-bunches with energy 820 Gev (Icommon = 400 mkA) with 10 e-bunches with energy 26.7 GeV (Icommon = 1100 MkA). The values of currents are for start time. Our new tool for registration of ep-collisions with so-called "Lumi- functional" worked reasonable. Maximum value of current luminosity was estimated as 7.6*10**27cm-2s-1 This value was registered twice - at 21:40 - after 2 min. after finish of ramping and at 22:09 when HERA-people made best conditions for luminosity at H1 Interaction point. During this ep-collisions it was written Run22723 with standard set of trigger-elements (by Eisenhandler who was H1 Shift Lieder). Run22723 was started at 22:07 - and finished at 22:30 - so it inserted into itself the events during best Luminosity conditions at H1 Interaction Point. Tool "H1 Luminosity Monitor" due to time problem (may be) did not work. It was tested new Desk Accessory "LumiMon_11.06%" at tandem with new DAs at HKR_H1Lumi MacII. In principle all worked OK. At the begin of monitoring (as always at very hot time) it was crashed twice on both MacIIs. After installation of stable work it kept his history almost all period of ep-collisions. As seems the period of averaging with 10 sec - too long. May be at future it is needed to install 5 sec. Egor made new tool for Rate monitoring with any history and with any scales with simple updates of different options. It seems that it is more convinent that Usik's "RateMonitor". Egor made this tool due to Brasse's requests at last days. Tool was made at SuperCard technology. Shame to You, Sasha Usik! Egor made this tool for some days - Your product up to now has some problems (You started this work at March!). It is extremly needed to understand problems with "H1 Lumi Monitor" - why it sometimes don`t work. Why fast monitor up to now not tested? It is needed too - it seems that it must be more convinent for Luminosity Presentation. It was found else one error at H1LumiOnLineRec - I hope that at new collisions new release will be work without problem with energy spectra at FIC#2. Today it existed posibility to calibrate our detectors with e-beam. Firstly with 10 bunches and good intensity. It was made the next steps: 1) it was written some raw data on IBM-cartridges with TriggerMode0 (release H1LumiOnLineFIFOC) - new shifts - see earlier message; Run22727 - 102183 events - Trigger ET&PD; from 23:30 up to 23:47 "ETAG" was installed as "ET&PD&", it was remove 8190 scaling for ETAG and remove all another trigger sources (only ETAG). Run22730 - 106075 events - the same trigger; from 00:00 up to 00:19 it was written with request of E.Elsen - he made some changing at H1CTRIG and asked to repeate the same Run (at remarks of H1LogBook it is written - "Switched CT summing card5/Lumi") Run 22725 was written with noncorrect installation of trigger conditions at H1CTRIG (existed another sources of triggers). from 22:57 up to 23:26 with 146516 events. All this Runs are written on permanent cartridges. 2) After this "Luminosity"-branch was swithced off from H1CDAQ and we tryied to calibrate our detctors with release H1LumiOnLineFIFOA(but remember that this is not absolute calibration - different shifts with H1LumiOnLineFIFOC - only relative CC). In principle with trigger ET&PD&anti(waterVeto) we got the good preliminary result - this CC can be as start values for off-line calibration. 3) Very bad news - CC very depend from rate. All channels with maximal rates (e21 and p07,p08) has now another CC then with 1 bunch calibration. And this channels have very large quantity of overflow situation: et21 - 6.7% pd07 - 6.5% pd08 - 2.4% It means that HV-set on our detectors depends from rates. We probably must have different HV-sets for 1 bunch-mode, 10-bunch-mode, X-bunch mode etc. 4) Now it is undestood that it is needed to write our Lumi-events through "Photoproduction"-branch - with good scaling factor - as at ETAG or more. Egor said that it is not very difficult. We need this events for testing of used CC at photoproduction branch. 5) The task of nearest days - to carry out the calibration on data of Runs 22727 and 22730 and to tune it for reosanable energy spectra. May be it would be the last our calibration for this data taking - as seems at this monthes we could not have more then 10 bunches. 13.06.1992 ===================== F11LEV === Overflow, calibration ..... There is an important difference between ET and PD situations w.r.t. overflows due to the high rates: at ET channel 21 will always be in a very hard conditions, next - 22, 23, etc. - only central layer, while at PD a situation will strongly depend on the e-beam angles at IP - a spot center may be in principle in any place within (realistically) 3*3 central PD cells. Here you cannot expect that pd07 and pd08 will have a highest rates as now. In a longer term, under more or less stable beam conditions the hotest spot should be around crystal #12 (corresponding to zero beam tilt). Thus, if for the ET one can foresee in advance a few HV settings, say for a) R<1kHz, b) 150kHz, for the PD this is more difficult. Relatively good news is that in fact for the first day (in fact first year) physics only ET calibration is really crucial... For your information. I have prepared a simple routine which will be called from IBM logging job of Jan Olsson to access our LRTL (and in future LRTS) bank, prepare LUMI, beam profile and bunch statistics plots and write them on a special file on the IBM. This file will be permanently updated (like present single event file for the H1ED) and everybody can display and plot our online luminosity monitor data in a real time during data taking. Therefore, please do all your best in order to put into LRTL bank reasonable data! From Monday on all H1 collaboration will watch on our LUMI information directly. Note, that at the beginning I will not apply any corrections to these data (since I cannot: not enough knowledge accumulated yet about behaviour of our new system). Just to remind you: please, check and report on the results concerning the situation with PD orientation. This is an important issue for the lumi calculation (correction factors depending on the beam angles at H1 IP). This should not be too difficult in principle: one must either to scan with the e-beam in hor and vert planes +- 0.2 mrad (request to the HERA people), or to move PD platform (this of course can be done only in vert. direction - but this is also something). If the orientation is correct, then the position must be wrong (PD center is off on 10-15 mm in one or even both axes). Fomenko, have you checked all our banks on the subject of sub-header (1st - # of columns, 2nd - # of rows) ? People are still complaining (they are mostly using an old data, but are you sure about new data?) 14.06.1992 ===================== H1KFOM === PD is installed right ..... Today morning at 6:00 it was made test of right installation of PD-detector. Movable platform with PD was installed on position 473 mm. Sasha moved it on position 463 mm. Monitor "PhotonBeamPosition' showed that Y-profile changed from -1.0 on 0.0. It means that PD has adequate response on this moving - it was installed right. At this time it was existed e-beam with 12 GeV and current near 10 mkA. Trigger on LumiBranch was installed as SumPD due to very slow rate of ET&PD events (low intensity of e-beam). Movable platform was returned into previous position - 473 mm. I had short talking with F.Brasse about future posibility of investigation of behaivour X-coordinate plot at ET with switched off H1 Solenoid (when it would be possible - may be some occasion - with e-beam and swithched H1 Solenoid). He had agreed. Answer for Levonian`s question about Lumi-banks Nrow,Ncolumn: all is OK. All banks of H1Lumi have right subheaders. 14.06.1992 ===================== H01USA === Lumi out .................. About so called "lumi functional" r. It pecisely equals to Rtot/Rbg, where Rtot - total (for all bunches) rate of lumi trigger, Rbg - total background rate on residual gas. So r = 1 when we haven't collisions. The problem was that the measured values of r for last 10 bunches collisions were closed to 1 (mainly ~ 1.15 - 1.2 ). It requires more higher statistical accuracy of our measurements because we have to calculate lumi out as the difference of two close values (Rtot - Rbg). It was done and new tools were prepared (as it informed in previous messsages). New measurements confirmed - we mainly have Rlumi onthe the level ~10-15% from background. 16.06.1992 ===================== H1KFOM === LRTL-bank is corrected .... Due to right remark of S.Levonian yesterday it was fixed bug at subroutine LRTLbankFill.f of H1LumiOnLineRecNew19-program for FIC#2. At all previous Runs with LRTL-bank it was noncorrect disposition of data with Xpdrough and Ypdprecise. Yesterday this bug was corrected and after near 11:00 16.06.1992 at all next Runs the LRTL-bank is written to H1DataFlow with correct disposition of high mentioned values (as written at DDL-discription). 16.06.1992 ===================== H1KFOM === New Calibration Coeff.Set.. From Run 23170 it was introduced the new calibration coefficients for PD-,ET- and Spectr.WaterVeto- channels. This coefficients was obtained at off-line calibration procedure with processing of Run22730. This Run was written 13.06.1992 from 00:09:34 up to 00:18:38 when e-beam with 10+1 bunches existed during almost 5 hours (after finishing of 4th ep-collisions 10x10+1). It was good posibility to tune our calibration coefficients for this type of intensity (as experience shows - for 1x1+1 ep-collisions it is needed another calibration coefficient set). It was the first serious calibration after timing changing (see message at LLO from 12.06.92). Calibration coefficient set is the next: All calibration coefficients are at MeV/FADCcount units PD - detector pd20=1.627 1.668 2.291 2.427 1.960 pd15=1.521 1.567 2.402 1.979 1.690 pd10=1.739 2.010 2.018 1.898 1.940 pd05=1.521 1.567 2.402 1.979 1.690 pd00=1.627 1.668 2.291 2.427 1.960 ET - detector et42=3.326 3.860 3.317 3.406 4.158 3.276 3.385 et35=3.125 3.671 3.292 2.437 2.743 2.531 2.799 et28=3.388 3.376 3.058 2.979 2.473 2.756 2.591 et21=2.475 3.722 3.309 3.193 2.825 2.525 2.697 et14=2.937 2.846 3.274 3.068 3.187 2.901 2.644 et07=2.293 3.145 3.370 3.577 3.166 2.726 3.387 et00=3.080 3.122 3.146 3.133 2.889 2.860 3.120 Water Veto: 7.555 MeV/FADCcount This set of CC will be appear at LREC and LRPC-banks at RunStartRecord of each Run. Remember that LREC and LRPC-banks at KEEP-environment will keep the CC-set for FIC#2 (Luminosity branch). It is needed to find correction factor for recalculating of this CC to Photoproduction branch. Set of CC for #FIC2 was obtained yesterday during 9.5 hours of good electron-beam (13 bunches with start value of total e-beam current near 1200 mkA). This set is the next: PD - detector pd20=0.211 0.214 0.512 0.454 0.319 pd15=0.194 0.173 0.693 0.527 0.292 pd10=0.297 0.277 0.359 0.337 0.373 pd05=0.294 0.180 0.209 0.251 0.322 pd00=0.301 0.215 0.204 0.311 0.308 ET - detector et42=1.039 1.218 1.044 1.064 1.706 1.030 1.077 et35=0.975 1.349 1.104 1.018 1.146 1.028 1.192 et28=1.039 1.013 1.144 1.261 1.062 1.131 1.005 et21=0.818 1.238 1.092 0.985 1.031 0.987 1.070 et14=0.921 0.928 1.093 0.972 1.122 0.880 0.811 et07=0.716 0.987 1.038 1.114 0.985 0.870 1.061 et00=0.965 0.976 0.983 0.985 0.908 0.897 0.976 Water Veto: 3.673 All CC for FIC#2 are put at relative units (convinent to calibration procedure at FIC#2-board). For creating of MeV/FADC units it is needed to make the correction procedure: all CC for PD and WaterVeto must be multiplied on 3.89 and else one multiplied on tunning factor 1.0/0.72. all CC for ET must be multiplied on 3.65 and else one multiplied on tunning factor 0.72. This coefficients are constantly changed due to permanent calibration on the FIC#2 board and once per 11 sec are put into H1LumiDataFlow at KEEP-bank environment. The value of this CC at KEEP`s LREC and LRPC-banks are at ordinary units (at MeV/FADC counts) - similar as at StartRunRecord`s LREC and LRPC-banks. 17.06.1992 ===================== H1KFOM === Bunch Current Problem ..... It was appeared unwaitable problem for Luminosity measurements with our algorithm. Firstly it was observed on the data of e-beam at night 15.06.92. Off-line analisis of LRTL,HEAR,LRTN-banks which were collected from all Runs which were written during e-beam activity shows that something wrong at values of bunch currents. It is imposible to use the value total current of e-beam (this value as was observed has digitization factor as 200 mkA) - naturally we used the sum of bunch currents as total current of e-beam due to digitization factor as 1 mkA). But if You look behaivour of Itotal/Ipilot with time - it is very strange picture with jumpings up and down. This behaviour has direct reflection on our current luminosity values (and integral lumi too). Tonight this situation became more bad. We got from H1CTRIG information about bunch currents which are wrong. This is common problem of all. ZEUS look for the same strange picture. May be some people at HERA-machine who are responsible for this measurements can help to H1Lumi and may be ZEUSLumi? Now, for example the total current of e-beam is 3580 mkA (as it is looking for at TV-screen) - the sum of bunch currents is at 2.7 time less.There are no any correlation between bunch currents and rates of Lumi-trigger at this bunches. This is the problem which must be resolved before nearest ep-collisions. First that it would be possible to do - we need only 2 right currents - total and current at pilot bunch. In principle it would be possible to make direct measurement on the oscilloscope screen at HERA Control Room and by hand (!?) to insert this relative values to our system. Only this two values. 17.06.1992 ===================== H1KFOM === e-beam 17.06.92 (night).... Tonight it was some activity of HERA e-beam. Before start of this activity it was planned some investigations of H1Lumi with e-beam with installed collimator and without. But during test attempts to install collimator (at HERA CCR by Felst) - it was found that there are some problems with collimator control. This part of activity became impossible. But after 23:00 e-beam appeared. We looked for very long time 12 GeV e-beam with up to 14 bunches and with very high intensity (near 4 mA per 14 bunches for example - it was design intensity per e-bunch - near 270 mkA per bunch). Fistly we observed very good energy distributions on 12 GeV at Lumi- nosity branch (it became possible due to new calibration coefficient set). Beam position during this 12 GeV e-beam existing was the next: Xmean =-0.4 cm, Ymean =-2.8 cm. H1 Solenoid was swithched on. ET coordinate plot was without assymetry - not the same as we looked last time. At 02:25 it was made the first attempt of ramping (Ie=3730mkA at start of ramping). At this time on SumPD and SumET it was installed thresholds as 12 units (near 3 GeV). The rates were the next after end of ramping: CherenkovWaterCounter - near 72 kHz; ET&PD-total - near 15 kHz and rate at single bunch #4 (one from 12 existed bunches) - near 1.2 kHz. High mentioned thresholds are optimal for e-beam 12 GeV. At 02:33 it were installed the optimal thresholds for 26.7 GeV e-beam - as 20 units on both Sums. After ramping e-beam lost its current with time (320 mkA per minute) and at 02:36 was lost. The second attempt to make ramping with injected 12 GeV e-beam with 14 bunches (Ie=3.770 at start of ramping) was made at 03:52. The rates were the next: Cherenkov Water Counter - near 70kHz, ET&PD total near 12 kHz (new thresholds - 20) and single bunch #4 (one from 14) - near 700 Hz (new threshold 20). The behaivour of e-beam after ramping was the same as at first attempt (very short living time): 03:58 - 3.17 mA 03:59 - 2.51 mA 04:00 - 1.98 mA 04:03 - 1.46 mA 04:04 - 1.42 mA 04:05 - e-beam was lost and simultaneously at H1 Control Room was power failure - power on short time was down and after one second up. At H1Lumi subsystem only FADC crate was switched off during this jump of power supply. High Voltage - OK. All another crates was found switching on. After reloading of both FICs the system was ready to operation. All monitoring facilities lived not crashed. One interesting impression from this both rampings - after finish of ramping (as seems) the bunch currents had almost right sum. May be HERA-people cannot measure right current with 12GeV-beam - only with 26.7 GeV? Little remark to e-beam activity at 15.06.1992 (9.5 hours) - at this period HERA-people said that some magnets was installed on the 12 GeV energy and some on 26.7 GeV. And for the question of Evgenio - which is the energy of beam - somebody answered - "This is very intersting question...". At off-line analysis of 9.5 hours of beam history this question appeared again - energy of e-beam at HEAR-bank was 12 GeV during our wrong "luminosity measurements" - when we had "very deep" negative integral luminosity - may be this was due to above mentioned impression?. As seems after appearing of 26.7 GeV at HEAR-bank the values of LuminosityFunctional became more reasonable - near 1.0. But this is only impression. It must be tested and checked again. Example of wrong bunch currents during preparing to the second ramping Time TV-value SumOfBunchCurrents NumberOfBunches 3:46 3.470 0.846 11 3:47 3.450 0.862 12 3:49 3.850 1.014 13 3:50 3.910 0.814 13 3:50 4.010 1.654 14 3:54 3.770 ????? 14 - start ramp. 3:58 3.170 2.852 14 3:59 2.510 2.870 14 ?:?? 2.420 2.620 14 ?:?? 2.270 2.620 14 ?:?? 2.190 2.370 14 ?:?? 2.110 2.530 14 ?:?? 2.060 2.530 14 ?:?? 2.020 2.440 14 ?:?? 1.990 2.440 14 4:00 1.980 2.320 14 ?:?? 1.940 2.320 14 ?:?? 1.840 2.130 14 ?:?? 1.670 2.050 14 ?:?? 1.560 1.780 14 ?:?? 1.520 1.640 14 4:03 1.460 1.520 14 ?:?? 1.430 1.422 14 4:04 1.420 1.384 14 4:05 e-beam was lost with jumping of power supply at H1 During 12 GeV e-beam existing at HERA - today all time the difference between TV-screen value and sum of currents was almost 3-4 times. Sum was always less then TV-value. HERA-people said that TVscreen value was right. This morning S.Levonian will be surprised with our new "luminosity measurements" on e-beam. But this is the problem of bunch currents - our rates are reasonable. Let's make "clean" test - 26.7 GeV e-beam must be clear without any "...this is very intersting question..". May be our problems are due to random coincidence of different things. 17.06.1992 ===================== H1KFOM === LRTL-bank is corrected .... Due to right remark of S.Levonian yesterday it was fixed bug at subroutine LRTLbankFill.f of H1LumiOnLineRecNew19-program for FIC#2. At all previous Runs with LRTL-bank it was noncorrect values of bunch rates and total rate of ET&PD events. This values was more then real ones on factor near 10 (but a little less). After Run 23329 all is OK. 18.06.1992 ===================== H1KFOM === Bunch currents OK ......... Today during short 3 hours activity with 12 GeV e-beam it was with please found that now (as seems) all is OK with bunch cuurents values. During this activity our "CollisionMonitor" showed the LumiFunctional value near 1.0 (0.95,0.97,1.01,1.02,1.03 etc.). But not resolved prob- lem is with absence of fluctuation around 1.0 during long time. It was possible to look the values less then 1.0 during 100-200 sec. (at this time we are collecting good collection of "negative" integral lumi). At the next 100-200 sec. it was possible to look for the values of this functional with more then 1.0 (at this time our "negative" collection increases to zero value and sometimes it was began the collection of "positive" lumi) etc. As seems the main reason of this behaivour is the digitization of bunch currents values (now the values for bunch current has neighbour values with difference on 2mkA). 18.06.1992 ===================== H1KFOM === New Lumonosity Algorithm... Today after discussion with A.Usik it was decided to prepare new algorithm for current luminosity value calculation. Sasha proposed to use his formula for estimation of statistical error of luminosity measurements as basis for putting non-zero values luminosity into A1-value (current luminosity value at our present luminosity measure- ment philosophy). It was proposed to calculate every DT1 sec (now 10 sec.) this statistical error and if the calculated current luminosity value (positive) more then 3*Sigma - only at this case - the value current luminosity value will be update to this value - at another case luminosity is 0 (never used negative values). At this case we never will look for "negative" integral luminosity. This algorithm will be inserted as the next (4th) option. At present routine we have 3 options (1st - used only positive lumi values, 2nd - positive and zero, 3rd- all possible - positive, zero and negative). Formula for calculation of statistical error is kept at LLO at H01USA-message from 10.06.92. 18.06.1992 ===================== H01USA === Stat. error of lumi func... Statistical error of "lumi functional"(r=r2/r1=Rtot/Rbackground): sigma(r) ~< SQRT( 1/(Rtot*Tt)+1/(Rp*Tp)+(dIp**2)*(1+1/r1) ) where: Rtot - total (for all bunches) rate of lumi trigger , Rbg - total background rate of lumi trigger on residual gas. Rp - lumi trigger rate of pilot bunches, Hz dIp - sigma(Ip)/Ip. Ie_t - total electron beam current Ie_b - electron beam current per bunch Ie_p - electron pilot bunch current r1= Ie_t/Ie_p - currents ratio r2= Rt/Rp - rates ratio Tt,Tp - averaging time for calculation of Rtot and Rp F.ex. for 10 bunch collision of 11.06 (18:48) we have: SQRT(1/(690*1)+1/(60*10) + 10**-4) ~= 6% fot Tt,Tp = 1 and 10 sec SQRT(1/(690*5)+1/(60*50) + 10**-4) ~= 3% fot Tt,Tp = 5 and 50 sec 18.06.1992 ===================== H01USA === r for last runnings........ Some data from the last collisions runnings from the view point of pilot method ----------------------------------- _______________________________________________________________________ RUN. |Ie_t|Ie_b|Ie_p|r1 | r2 |r/r?| Rt | Rp| RL| L/ Lexp|Ipr_t|scale f. ----------------------------------------------------------------------- 1 bun| 400| 200|200| 2 |2.4 |1.2 | 180| 75| 30| 1.26e27| 36.5| 1.0 31.05| | | | | | | | | | | | 16:00| | | | | | - | | | | - | | _______________________________________________________________________ 10bun| 529| 44 |44 |12.0|13.8|1.15| 663| 48| 85| 3.57e27| 470 | 3.1 04.06| |(n6=| | | | | | | | | | 06:20| | 88)| | | |1.2 | | | | 3.92e27| | _______________________________________________________________________ 10bun| 756| 55 |200|3.76| 5.6|1.5 | 692|123|200| 8.40e27|1170 | 8.8 06.06| | |(?)| | | | | | | | | 08:00| | | | | |1.53| | | | 1.10e28| | _______________________________________________________________________ 10bun|1000| 91 | 95|10.5|11.7|1.12| 687| 58| 70| 3.00e27| 380 | 4.74 11.06| | | | | | | | | | | | 18:48| | | | | |1.24| | | | 6.00e27| | _______________________________________________________________________ 10bun|1040| 95 | 90|11.4|13.5|1.18|1310|102|150| 6.30e27| 410 | 5.33 12.06| | | | | | | | | | | | 22:10| | | | | |1.19| | | | 6.70e27| | _______________________________________________________________________ where: Ie_t - total electron beam current, mkA Ie_b - electron beam current per bunch, mkA Ie_p - electron pilot bunch current, mkA r1= Ie_t/Ie_p - currents ratio r2= Rt/Rp - rates ratio r= r2/r1=Rtot/Rbackgraund (> 1+3sigma(r) means there is collision) r? - r expected (scaled to 1bunch running) Rt - total (for all bunches) rate of lumi trigger, Hz Rp - rate of pilot bunch, Hz L - calculated luminosity,cm-2s-1 Lexpected - scaled luminosity to 2bunch running (~ Ie_t * Ipr_t/Nbunch) Ipr_t - total proton beam current, mkA 19.06.1992 ===================== H1KFOM === New Release of OnLine ..... From Run 23540 the new release of H1LumiOnLineFIFOC was involved into work with H1CDAQ+H1CTRIG. Four changes were realized: 1) at each Run it is killed the first LRTL-bank which is created at FIC#2 asynchronous. This changing was made due to reset at RunStart subroutine of all HW Bunch Counters and possible negative or non-adequ- ate rate creation during this time (it must be checked - may be it is needed to kill and the second LRTL? I am not shure but it is possible that the second LRTL is noncorrect too - may be only the second...). 2) on the request of Manfred Zimmer it was involved right creating of possible readout error codes. Before this release H1LumiOnLineFIFOC created ROERROR=$40000000 when unwaitable situation had appered at BOS-bank structure. At this case information from our Luminosity branch not transferred to H1CDAQ (from this only event) and this type of ROERROR made possible of Event Building from all another H1 branches without information from H1Lumi. This type of error was very rare but existed in principal. Before this release the message "Luminosity: no error" sometimes had appered at MessageLog of H1CDAQLOG. It was strange message-nobody does`t put this type of ROERROR into MessageLog. It was only evidence of some ROERROR without its type. Now the next codes of ROERROR were introduced: 4 - problems with BOS-structure of LREF-bank; 5 - problems with BOS-structure of LREE-bank; 6 - problems with BOS-structure of LRPF-bank; 7 - problems with BOS-structure of LRPE-bank; 8 - problems with BOS-structure of LRTE-bank; 9 - problems with BOS-structure of TSTC-bank; 10 - problems with BOS-structure of LRTF-bank; 11 - problems with BOS-structure of LRTN-bank; 12 - problems with BOS-structure of LRTC-bank; 13 - problems with BOS-structure of LRTL-bank; 14 - problems with BOS-structure of VETE-bank; 15 - problems with BOS-structure (not right the total length). 3) At this release it was made attempt to create own logbook for the last 100 Runs with information about Integral Luminosity values (total and effective) at DPM. In principal it would be possible to make some monitoring tool for showing of this information at on-line to anybody who interested. 4) From this release it is possible to look for any bunch statistics with "Bunches_hw"-desk accessory (yesterday release of A.Usik) inde- pendently from FIC#1 status (earlier it was impossible to look this information if Run was stopped or if background area of FIC#1 was not operated due to high frequency of L2Keep-events). 19.06.1992 ===================== H1KFOM === e-beam 26.7 Gev 19.06.92 .. Today morning at 5:40 it was injected 12 GeV single bunch of electrons into HERA e-ring. At 5:53 Itotal on TV screen was 420 mkA (on the our system only 226 mkA). The ramping was finished at 06:20. This beam lived up to 07:28 (near 1 hour). At this time Luminosity branch was included into H1CDAQ and sent to H1DataFlow LRTL,LRTS,LRTN- banks. Run23551 - was fnished 06:37. Run23552 - from 06:39 up to 06:46 Run23554 - from 06:49 up to 07:12 Run23555 - from 07:13 up more then 07:28. Else one it was existed e-beam at HERA (from 10:20 up to 11:35) with 5 bunches. At this period Luminosity branch was not included into H1CDAQ. 19.06.1992 ===================== H1KFOM === off-line analysis of Lumi.. It was analyzed the LRTL- and LRTN-bank contents from Runs 23551,23552, 23553,23554,23554 and 23555. It was found that there is some bug at calculation of rate at LRTLFill-subroutine of H1LumiOnLineRecNew19- program for FIC#2. 1) main problem - when LRTL-banks are accepted into H1CDAQ with rare rate (due to rare rate of L2Keep for example or due to little pause at data taking during Run (this is the feature of H1CDAQ - CDAQ is thinking - may be near 20 sec. and after this - continue of data taking ) - it is looking for non-adequate with e-beam behaivour jumps at rates. This bug is obvious but it is needed to fix it. (Run 23552 - good ocasion for finding of this type error - only 15 events per 7 min.). Five cases of "H1CDAQ thinking" was registered due to this error 06:27,06:30,06:47,07:22.07:24. 2) the second problem - large value of "luminosity" during ramping. (1.2*10**28cm-2s-1) - I think that decision of this problem - large time of averaging of "pilot"-bunch. At this dynamic period the rate of pilot bunch must be calculated may be without this type of averaging. 3) during almost 1 hours the value of current luminosity had average value near 2.0*10**26 sm-2s-1 (from 06:20 up to 07:28). It must be zero value.It is possible hope that new option 4 will help to H1Lumi to have zero-value when it really zero luminosity. 4) not understood the jump of current value of luminosity at the time when e-beam was killed - jumping was on 2.0*10**27 cm-2s-1. It was not found any jump at rate and any another reason. High mentioned problems are under study. I hope to fix bug and issue the new release of H1LumiOnLineRecNew19 without it before new ep-coll. It is possible to look for a little addition at RunSummary dumps Jan Olsson added special value per each Run - I.LUMI - it seems - Integral Luminosity value. For example for this Runs this values were the next (I don't know which integral - effective or total): Run 23551 226*10**27 cm-2 (mainly due to ramping period large current luminosity value) Run 23552 2*10**27 cm-2 near 7min. Run 23553 0 near 1min Run 23554 -36*10**27 cm-2 near 24min. Run 23555 20*10**27 cm-2 (part of Run up to 07:57) near 15 min with e-beam 20.06.1992 ===================== H1KFOM === p-beam activity............ This night p-beam alives again. The first attempt to inject p-beam was at 02:44 20.06.1992. After 3 or 4 attempts now it is made continuesly injection of 40 GeV-protons into HERA p-ring (from 06:11). It is pity but information about total p-beam current and p-bunch currents do not retranslated on TV-screen and through H1CTRIG. Nobody (exept HERA-people) know about currents values. At 07:00 p-beam was lost. 21.06.1992 ===================== H1KFOM === e-beam with 9 bunches ..... Yesterday, 20.06.1992, during presence at p-ring of single(#0) p-bunch it was activity of HERA e-beam (from 14:06 up to 17:54). At period from 16:06 up to 16:52 at HERA e-ring 9 e-bunches (from #0 up to #8) existed. The maximal value of total current at e-ring was near 2600 mkA (with 9 bunches). Ramping was started at 16:29 and finished at 16:31. Only near 6 min. 26.7 GeV e-beam was coexisted with single p-bunches. p-beam was lost near 16:37. During this period it were written H1Runs (from 23698 up to 23707) on temporary cartridges (19 cartridges). It was choosen most intersting period with e-beam (last part of Run 23701, Runs 23704,23705,23706). This Runs were written on 3 cartridges from 16:01 up to 16:40. From this Runs it was made selection of HEAD,HEAR,LRTL,TMDM and LRTN - banks and written on cartridge H1KFOM.EPXXXB.F206. This cartridge was processed with simple tool which is kept at H1KFOM.LUMI92N(#B210692)-data set. Preliminary results of this processing: 1) e-bunch currents - our old problem: It seems that this problem became not so unresolved as seen at past. Two graphics was made with behaivour of e-beam total current with time - one with value which is possible to get directly from TMDM-bank (with 100 mkA accuracy and 200 mkA digitization factor) and the second with value which is calculated as sum of all bunch currents (each from this currents is measured with 1mkA accuracy and 2 mkA digitization factor). And naturally it was made all 9 graphics with behaivour of all bunch currents with time. Next evidences it is possible to fix: a) Itotal from TMDM-bank had always the reasonable value - the incre- menting values during injection phase, stable - during preparing to ramping and decrementing - during ramping and life time of 26.7GeV e-beam (minimal value was registered as 8 units (800 mkA) during injection phase, maximal value - 26 units (2600 mkA) when injection was finished). b) Itotal which calculated as sum of all bunch currents had almost always nonreasonable values (exept the time with 26.7 GeV e-beam 7 min. after end of ramping). Itotal became the same as previous value - firstly at this almost 40 min. time interval. c) All bunch currents had nonreasonable behaivour with time during all period with 12 GeV e-beam and during ramping - especially - when almost all became on short time with zero value (exept bunches #0,#1 and #8. After finishing of ramping almost all current had the equal behaivour - its values after large jump became rea- sonable: #3 - 250 mkA; #4 - 250 mkA, #5 - 250 mkA, #6 - 260 mkA, #7 -260mkA As was proclaimed earlier #0,#1 and #8 had not zero values but lit- tle jumping it was looked for: #0 - on 60 mkA up to 240 mkA #1 - on 70 mkA up to 260 mkA #8 - on 60 mkA up to 220 mkA. But this jumpings were at different time after finish of ramping: #2,#3 and #8 - immediately after end of ramping; #0,#4,#5 - after 1 min. #6 - after 2 min. #1 - after 3 min. #8(last) - after almost 7 min. when p-beam was lost. I think that this different times of getting reasonable values are connected with some synchronzation of bunch position. After #8 bunch got his reasonable value - firstly from last 30 min. both Itotal had almost equal values. Our famous LuminosityFunctional became got value near 1.0 at this period. Conclusion: in principle it is possible to use Itotal as sum of bunch currents but with care (You must be shure that ramping is finished and all syncronization manipulation are finished). 2) beam position during this very intersting period: a) during injection before ramping Xpd near 0.0, Ypd between -2.2 and -2.4 cm; b) during ramping - dynamical changing : Xpd from 0.0 to 1.8cm and 1.0cm to finish of ramping; Ypd from -2.4 to 0.0cm to finish of ramping; c) 26.7 GeV e-beam - Xpd near 1.0 cm; Ypd - near 0.0 d) at moment of p-beam was lost: e-beam position was changed with jump: Xpd from 1.0 cm to -0.9cm Ypd from 0.0 cm to -2.7cm. e) rest of processing time period position was the same as d). 22.06.1992 ===================== H1KFOM === e-beam with 11 bunches .... Yesterday 21.06.1992 it was fixed some activity of HERA e-beam. It began at 12:48 and finished at 15:25 ( near 2.5 hours). During this period at p-ring existed 10 bunches with common current near 170 mkA. For the first view it was not fixed ep-collisions. At 13:48 the total e-beam current was near 2000mkA per 11 bunches. Luminosity branch was involved into H1CDAQ environment at 13:47. At this time ramping was finished, thresholds on SumET and SumPD was installed as 199/20 (both) - low thresholds are near 5 GeV. At e-ring existed 11 bunches. From currents disposition numbers of bunches were the next: e-beam: 0,1,2,3,4,5,6,7,8,9,19 p-beam: 0,1,2,3,4,5,6,7,8,9 Our trigger counters looked for e-beam bunches as shifted on 1 BC: 219,0,1,2,3,4,5,6,7,8,18 (at this bunch counters it were fixed rates from ET&PD-events. It were written some H1Runs at period from 13:47 up to 15:25 (when Luminosity branch was included into H1CDAQ): 23744,23745,23746,23748 - as temporary data 23749,23750 - as permanent data. p-beam was lost at 15:03. e-beam was killed at 15:25. At 14:05 it was moved C1 and C3 collimators (it was fixed the decrementing of rates at Cherenkov Water Counter - from 2.8kHz to 1.9kHz, ET&PD total rate - from 280Hz to 190Hz, ET&PDpilot rate - from 25 Hz to 14Hz). It was made during Run23744. At 14:30 it was fixed unwaitable jump of all rates: CherenkovWaterCounter - from 1kHz up to 7.5kHz ET&PD total rate - from 60Hz up to 1.1kHz ET&PD pilot rate - from 5Hz up to 80Hz After this jump all rates stayed at this new level (may be more optimal e-beam orbite?). From 14:30 up to 15:25 all this rates had behaivour as ordinary. All this period it was translated bunch currents from H1CTRIG to H1Lumi - but all values were zero. H1CTRIG had the reasonable values. Something was wrong with LAN-transmitting. It was proposed that may be new release of task which retransltes this currents to H1Lumi is incorrect. E.Elsen installed the old release but without testing - e-beam was killed. After some Egor's manipulation with H1Lumi-trigger the FADC-shifts on Luminosity subbranch (not Photoproduction)were changed from 100(ET) and 48(PD) to 98(ET) and 40(PD). Naturally default calibration coefficients for this subbranch became not correct and the value of TriggerEfficiencyKoefficient must be less then at previous e-Runs when it was near 0.84. During nearest e-Run it is needed to find new values of calibration coefficients for this subbranch. 22.06.1992 ===================== F11LEV === Rates in LRTL wrong? ...... Yesterday, during ep-collisions, LRTL banks with zero luminosity have been written by online Lumi system (perhaps, due to the zero current values obtained via LAN, although there were quite good currents in both beams). As a consequence, run summary of Jan Olsson logging job has produced Integrated Luminosity = 0, and offline lumi monitor showed also zero lumi (but non-zero trigger rates). In principle, i could correct lumi values offline (taking current data from Elsen's TMDM bank) however, it seems that LRTL contains wrong rates (!) or at least inconsistent: e.g. 21/06 at 14.43:34 bunch rates were the following: 9,8,8,10,9,10,6,4,4 and 7 -> 75 Hz, while total lumi rate was approx. 850 Hz. I also noticed the same in our old data from the first ep-collisions (31-May/1-June): always sum over the all bunches is much less than total rate (word 221 after subheader in LRTL) Fomenko, can you test again what you are filling in the LRTL bank? P.S. In the meantime we discussed with Fomenko LRTL content, and it turned out, that at least presently it is correct (for old data not) I simply forget to change conversion factor for bunch rates from the former 0.01 to the actual 0.1 23.06.1992 ===================== H1KFOM === Bunch Currents News ....... There are a lot of news connected with bunch currents: 1) John Couglagh said that really his new release of task for retran- slation of bunch currents to H1Lumi was issued with bug (he prepared this release for retranslation p-bunch currents too but it was not possible to test it with real situation). Today new release was tested (Egor,John and Sasha Usik). From their words - all is working now. There is memory region at H1Lumi with p-bunch currents values and with p-beam total current: B0A89770 - B0A89ADC - 220 real values (units 1mkA) - p-bunch currents B0A89AE0 - real value (inits -100 mkA) -p-beam total current 2) 22.06 at 22:00 it was registered (firstly at our experience) that both beam bunch currents did not transferred to H1Lumi at all (yester- day this array was transfered but with zero values - today no transfer- ring at all !!!). After midnight consultatioon with Egor,Sasha and Evgenio it was decided that it would be during the next possible reasons: a) MacII of H1CTRIG does`t see both our MacIIs at H1LAN (it was looked for with our MacII when only reboot of MacII at H1 Control Room made possible getting info forom HERA Control Room's MacII); b) may be John Couglagh put on this night else one new release which was not tested. The possible ways to do something (if e-beam will be appeared) - a) to try reboot H1CTRIG-MacII; b) to phone to John and get consultation and recomendation. Let`s wait e-beam. This morning it is needed to discuss high mentioned problems with John. 3) A little about off-line analisis of bunch currents from e-beam and p-beam coexistance at 21 June 1992 (H1Runs 23744 - 23750). (it was not fixed ep-collisions at this time as it was written by S.Levonian at his message from 22.06.1992). a) all information about both beam bunch currents was got from TMDM- bank which is written at each H1Event with H1CentralTrigger branch; b) all high mentioned Runs were written after finishing of ramping and during coexistanse of stable e-beam with 11 bunches (#0 - #9 + #19) and p-beam with 10 bunches (#0 - #9). Energies were 26.7 Gev and 820 GeV.The total beam currents were at begin of Run 23744 (13:48 21.06.92) - for e-beam near 2000 mkA, for p-beam - near 175 mkA. c) the e-beam bunch currents are looking for better (sums is near total e-beam current value). Behaivour with time of the total e-beam current and sum of all e-beam bunch current is looking for as similar (it was not so for 12 GeV e-beam - see for example Runs23701-23706 (time period between 16:01 and 16:40 at 20.06.1992). d) but it is appeared the new problem: if You look for with care the behaivour of each e-bunch current value with time You can see the next situations (at this time period): - very often situation when the value of e-beam bunch current has 2 mkA fluctuation ( it seems reasonable due to minimal digitization cell may be - but in principle it was promised that digitiztion cell value will be 1mkA) - this is not very large problem; - not more rare situation when the value of e-beam bunch current has 64 mkA fluctuation (it seems that something wrong at measurement toll of this current - may something as bit error at bit which is responsible for value 64 - bit number 5 if low bit is number 0). - sometimes (very rare) it was seen fluctuation into low side on 16 and 20 mkA ( may be it is too bit errors at 3 and 2 bits of digitization tool). - I think that this evidence will be useful for responsible person at HERA-team for e-bunch current measurement (as I know -Mr.H.W.Horn) e) it seems that no any problem with p-bunch current measurements - no any (64,16,20 mkA) fluctuation - only 2mkA - that is under- standable due to minimal digitization cell. 4) What would be if H1Lumi at 21.06.92 during Runs23744-23750 got this high mentioned e-bunch currents (with 64,20,16 mkA fluctuations) from H1CTRIG? Preliminary analyse shows that LumiFunctional had the mean value near 1.15-1.25 during Runs 23749 and 23750 (Rtot/Rpilot was near 13.0 and Itot/Ipilot was betwen 15-16). It means that H1Lumi would put into Integrated Luminosity enough good collection of non-existed lumino- sity. ZEUSLumi-people as Sasha Usik said had registered the jumping at value of pilot bunch current value too during this time. It means that problem of bunch currents is our common problem with ZEUSLumi-team. Really on the graphic with behaivour of pilot(#19) e-bunch current value with time it clear seen that at near 14:10 it was fixed jumping on 64 mkA to low value and after this this value never jupmped to up value. For today - no more serious problem for luminosity calculation as decision of problem with correct measurement of e-beam bunch current. 23.06.1992 ===================== H1KFOM === Bunch Counters Shifted .... Egor made shift of all Bunch Counters on 1 BC due to situation which was seen at 21 Lune 1992. Now it is possible to wait then rates of ET&PD-triggers will be fixed at the same bunches for which e-bunch currents value will exist. 23.06.1992 ===================== H1KFOM === New Usik`s Desk Accessory.. At the H1Lumi Desk Accessory family it is appeared the new member: "LumiMon_22.06!". It seems that it is new release of "LumiMon_20.06!" but with additional posibility to receive from H1LAN the values of p-bunch currents and total value of p-beam current. May be it is needed to make something as "LumiMon_23.06%" which would be the next generation of "LumiMon_11.06%"? May be it is needed to prolongate the generations "LumiMon#f2_cp" and "LumiMon#f2_cpii" with posibility to read bunch currents? For this day it is needed to make some reminder (may be at LLO?) which from 5 high mentioned Desk Accesories is used or must used at different situations. For today it is difficult to remember all delicate nuances of using each from this DA. Sasha, make please something as reminder or recomen- dator of using of Your LumiMon-family Desk Acessories if it is not very difficult for You. 23.06.1992 ===================== H1KFOM === p-beam activity ........... It seems that from today the problems with HERA p-beam finished. P-beam with 820 GeV which was appeared at HERA p-ring 10.5 hours ago (near 18:00 22.06.92) is living with very low decrementing of its current (10mkA per 8 hours). Now (03:20 23.06.92) the p-beam total current is 550 mkA (10 bunches). Two hours ago this value was 560 mkA and 10 hours ago - 570 mkA. It is pity but due to problem with LINAC- it is impossible to wait now new ep-collisions. But good p-beam living means that at nearest days we must be ready for hot work with ep-collisions. It is waitable situation very long time. 23.06.1992 ===================== H1KFOM === Proposal .................. I addresse this message to S.Levonian. Yesterday morning Sergey said that in principle it is possible to recalculate the current values of luminosity (and to make some correc- tion to Integrated values) at off line procedure with using of LRTL- and TMDM-bank contents. I think that it is needed to create this tool (for any case). First occasion of usefulness of this tool will be may be today. It is possible to make correction on uncorrect measured values of e-bunch current. May be Mr.Horn will make something for changing of this very bad situation to best one but may be it will get some time. But from another side - may be today will be began ep-collision. In principle (as seems) it is possible to make some tool for correction of uncorretly measured currents due to next obvious errors at measuring: 1) as was looked for from behaivour of e-bunch currents with time the next region of real current values is "dangerous" for HERA measurement tool: 174 mkA - 128 mkA. If real current lays at this region - the measured value can be on 64 mkA more and measured value can be or really from this region (174-128) or on 64 mkA more (from 238 to 192) - it depends from hitting another bit. 2) It is looked for from high mentioned graphics that when real current lays at region 142-128 mkA - measured values always layes at region 206 - 192 mkA (so "1" at bit #7 and "0" at bit #4 always are the reason of false "1" at bit #6). I have proposal to make some algorithm for recognition of this uncorrect measurements and introduce it into any LumiMonitoring Tool (OnLine or Offline). Let`s try to make this tool together. It is possible to use data from Run 23744 to test this new tool. What is Your opinion? 23.06.1992 ===================== H1KFOM === Remark about Pilot-Bunch .. As I understood from talking with S.Levonian some days ago he proposed to involve at pilot bunch not single bunch as we made earlier but all bunches which are not involved into ep-collisions. I think that it is not always right. From off-line analysis of the Runs 23744-23750 there are some evidencies: 1)e-bunch currents existed only for bunches #0-#9 and #19; 2)rates ET&PD events existed mainly at this bunches but it were existed else 15 bunches (all bunches between #9 and #19) and some bunches after #19 - total quantity is near 15 additional bunches. It means that if You will use total rate ET&PD events as 221 word of LRTL-bank - You can make some systematic error - due to simple reason You have not distinct value of total e-beam current. If You will use the sum of bunch currents as total e-beam current - You nothing know about currents at this 15 "additional" bunches. It means that You must use sum of bunch ET&PD rates as total rates only for those who has the distinct value of current. 24.06.1992 ===================== H1KFOM === ep-collisions 10x10+1 ..... Yesterday, 23 June 1992, from 13:01:21 up to 14:47:55 (near 1 hour and 46 min) at H1 Interaction point were registered ep-collisions. It were collided 10 p-bunches with Ep=820 Gev and 10 e-bunches with Ee=26.7 GeV. Pilot-bunch(with #20) existed for Luminosity measurement. At the start of colisions total e-current was near 2000 mkA and total p-current 630 mkA. Numbers of collided bunches - from #0 up to #9. On-line measured mean value of total luminosity value is estimated (preliminary) as 1.5*10**28 cm-2s-1. Maximal value estimated as 2.0* *10**28 cm-2s-1. Integrated Luminosity per Runs and per Running must be estimated and corrected at off line procedure (as seems due to some not resolved problems - on-line values are not correct). During ep-collisions it were written 9 H1 Runs: 23904 - 12:57:07 - 14:13:54 23905 - 14:15:22 - 14:16:54 23906 - 14:20:12 - 14:20:22 23907 - 14:20:23 - 14:20:34 23909 - 14:22:54 - 14:24:47 23911 - 14:26:43 - 14:30:05 23912 - 14:30:23 - 14:38:00 23913 - 14:39:00 - 14:46:00 23914 - 14:47:21 - 14:47:35 This very succesful Running was interrupted unwaitable power fail at DESY. HERA stopped. All needed details of this HERA Running will be written late. 24.06.1992 ===================== H01USA === last collisions ........... Some data from the last collisions runnings from the view point of pilot method ----------------------------------- _______________________________________________________________________ RUN. |Ie_t|Ie_b|Ie_p|r1 | r2 |r/r?| Rt | Rp| RL| L/ Lexp|Ipr_t|scale f. |Ie_c| | | | | | |R/I| | /Ltheor| | ----------------------------------------------------------------------- 1 bun| 400| 200|200| 2 |2.4 |1.2 | 180| 75| 30| 1.26E27| 36.5| 1.0 31.05| | | | | | | | | | | | 16:00| | | | | | - | |37.| | - | | _______________________________________________________________________ 10bun| 529| 44 |44 |12.0|13.8|1.15| 663| 48| 85| 3.57E27| 470 | 3.1 04.06| |(n6=| | | | | | | | | | 06:20| | 88)| | | |1.2 | |109| | 3.92E27| | _______________________________________________________________________ 10bun| 756| 55 |200|3.76| 5.6|1.5 | 692|123|200| 8.40E27|1170 | 8.8 06.06| | |(?)| | | | | | | | | 08:00| | | | | |1.53| | 62| | 1.10E28| | _______________________________________________________________________ 10bun|1000| 91 | 95|10.5|11.7|1.12| 687| 58| 70| 3.00E27| 380 | 4.74 11.06| | | | | | | | | | | | 18:48| | | | | |1.24| | 62| | 6.00E27| | _______________________________________________________________________ 10bun|1040| 95 | 90|11.4|13.5|1.18|1310|102|150| 6.30E27| 410 | 5.33 12.06| | | | | | | | | | | | 22:10| | | | | |1.19| |113| | 6.70E27| | _______________________________________________________________________ 10bun|1640| 148|164|10.1|13.2|1.31|1480|101|350| 1.50E28| 620 | 12.6 23.06| | | | | | | | | | */ | | 13:35|1480| | | | |1.34| | 62| | 1.60E28| | | | | | | | | | | 1.56E28| | _______________________________________________________________________ */ max measured lumi for this run - 1.70E28 cm-2s-1 where: Ie_t - total electron beam current, mkA Ie_b - electron beam current per bunch, mkA Ie_p - electron pilot bunch current, mkA r1= Ie_t/Ie_p - currents ratio r2= Rt/Rp - rates ratio r= r2/r1=Rtot/Rbackgraund (> 1+3sigma(r) means there is collision) r? - r expected (scaled to 1bunch running) Rt - total (for all bunches) rate of lumi trigger, Hz Rp - rate of pilot bunch, Hz R/I - = (Rp/Ie_p)*100mkA L - measured luminosity,cm-2s-1 Lexpected - scaled luminosity to 1bunch running (~ Ie_c * Ipr_t/Nbunch) L - calculated by W.Bialowons from theory : =1.7E29*Ie_c*Ie_p/Nbunches for present conditions (currents - mA). Ie_c = Ie_t - Ie_p - electron currents of collided bunches Ipr_t - total proton beam current, mkA All information with pictures are available in both H1Lumi logbooks ( H1&HERA control rooms). Esential points: 12:47 and of ramping Ie_t = 2.60 mA Ipr_t =0.62 mA 13:03 collisions 13:07 1.87 0.62 13:30 C1,C2,C3 collimators are moved IN => all rates went down (factor ~2), but big fluctuation of pilot rate disapeared ! ~14:00 the integrated lumi of video "LumiMonitor" was reseted , so final number 2.6E31 is resonable (total for all running expected ~ 8.0E31) 14:48 1.16 0.54 14:55 power failure 0 0 24.06.1992 ===================== F11LEV === LUMI problems ............. There are also offline figures available for the long run 23904 from the last collisions. And unfortunately they show clear problems both in the new CTL (Central Trigger Logic) and LUMI trigger. In many cases CTL tells that there was ET-trigger whereas there were nothing in ET, which lead to the "crasy ET rates" as was stated in the H1 logbook. Due to this error (?) in CTL eTAG trigger was switched off for the last big run (see H1EP). More important for us (CTL will be checked anyway by Elsen and C) is a wrong PD calibration for the trigger which seriously deteriorated our ET-trigger element: too many lumi events have been accepted... These two problems are new compared to earlier runs. Third one is the same as before in the first ep-collisions data: ET-spectrum shows always significant dip around 15+-1 GeV where one would expect very good acceptance. The reason is not clear for me. Overflows in ET cannot explain it, since it would correspond to the 25-30% of those. By the way, in the last runs (on the total statistics above 30000 events, 700 of them having etag energy) percentage of the event having overflow in ET is now 10%. Luminosity curve is better then before, but still not perfect. 25.06.1992 ===================== H1KFOM === Integrated Lumi Values .... It is possible to determine the Integrated Luminosities per Runs from analize (at off line) of the behaivour of this values with time. There is very interesting evidence at histos 904 and 905 at LOOK-data set H1KFOM.BLOOK.R23900 (produced from processing LRTL,LRTN,TMDM banks from Runs 23900 - 23913) - this two histos are the behaivours of both Integrated Luminosity Values (Total(904) and Effective(905)) with time. These pictures have two part - first from 12:09 up to 13:01 (from 0 min up to 52 min) and the second - from 13:01 up to 14:49 (from 52 min. up to 160 min.). First part gets the time of preparing to ep-collisions (injection, ramping, synchronization of bunch disposition) and the second one - all period during ep-collisions up to power failure. Behaivour of integrated luminosities during first period it is impossible to predict. There are a lot of different reasons for wrong calculation of current luminosity values at this period(negative or large positive): 1) not right measurement of e-bunch current during 12 GeV e-beam (but at this Running I can remove this supposition) - at all e-Runs before 23.06.1992 - really the e-bunch currents was not correctly measured during 12 GeV-ebeam; 2) absence or not right putting of the pilot bunch number 3) very large jumping of rates (both Total ET&PD or Pilot ET&PD) during different tunning or adjusting manipulation of HERA people and due to Pilot ET&PD Rate slow return to some averaged value after this jumping ( during this Running it was used iteration formula for calculating of Pilot ET&PD-rate); 4) during some minutes after finish of ramping sometimes (for example H1 Run 23701) it was looked for some synchronization manipulations HERA-people when only after 7 minutes all e-bunch currents became with reasonable values. 5) it was seen at Run23305 that at the finish of ramping the values of all e-bunch-current are zero and after some seconds - large jump to up value as reasonable value All this reasons or one from their can put into integral luminosities some negative or positive collection. There are some interesting evidencies at the second period (during ep-collisions): 1) at 13:01 we had large collection of negative luminosities due to some from high mentioned reason (near -2.1*10**31 cm-2). 2) from 13.01 up to 13:15 both luminosities (total and effective) were incremented (it is adequate behaivour due to ep-collision pre- sence). At 13:15 the value of total integral luminosity was -0.4* 10**28 cm-2 and effective integral luminosity was near the same value. 4) at 13:15 it was fixed some activity of HERA-people - attempt to find more optimal condition for ep-collision at H1 IP - at this time the Xpd changed with jump from 0.7 to -0.3 cm and after this jump again to 0.7 cm, Ypd jumped from 0.15 cm to -2.4 cm and after this jumped to -0.3cm. At this time it was fixed jumpings at both Pilot and total rates of ET&PD. It was the reason of putting additional negative collection of Luminosity - integrals again became "more negative" - its were decremented on 1.0*10**31 cm-2 value and became with value near -1.7*10**31 cm-2. 4) from 13:15 up to 13:52 both integral values again were incremented with almost constant rate (good sign of presence of stable Luminosity). At 13:52 the value of both integrals were:total was near 1.3*10**28cm-2 effective - a little less (near 1.25*10**31 cm-2). 5) at 13:52 it was fixed else one putting of new portion of "negative luminosity" to both integral values (it was fixed simultaneously the jumpings at values of 3 e-bunch currents (#0, #4, #5) - Itot/Ipb fixed the large jump to value more then 20 ) - You can see histos 1000,1003,1004 and 700 at the same LOOK-data set and put You eyes on time 104min. It was the last case of putting of negative luminosity collection into integrals. Due to not very complicated geometrical calculation it is possible to estimate real values of both Integral Luminosity values for Run 23904 (most long at this Running) - Total Int. Lumi - near 6.0*10**31 cm-2 Effective Int. Lumi - near 4.6*10**31cm-2. As me seems another Runs do not need with correction of Integrated Luminosities - it was right values at RunSummaries. And the last (may be interesting for S.Levonian) remark: At 13:52 it was fixed very interesting event at H1 or at H1Lumi or may be at anywhere else (time may be randomly coincidents with high mentioned last case of putting of negative luminosity into both integr) DEAD TIME OF H1 BECAME VERY LARGE due to incrementing of L2Keep frequency and this large dead time kept up to finish of Running (up to power fail). It is possible to see this incrementing of dead time at histo 905 (after time 13:52 up to 14:49). Effective Lumi was incremented with very low portions. As preliminary analyse shows it was happened (may be) due to manipulation of "somebody" at H1CDAQ shift with Trigger Rate Prescaling option at H1CTRIG. I found very interesting message at H1LogBook - satellite. "14:20 - Trigger Rate Prescalling Adjusted" (!!??) In principle (as explained Ueli Straumann) technicaaly it is possible to make this during the H1Run. But it is very bad tone - for any manipulation with any options at any subsystem it is needed to stop H1Run, to make manipulation with option, to write something about into H1LogBook and to start new H1Run. It is very strange else due to very rare posibility to take data at ep-collisions (this Run is only second collection of data from ep-collisions with switched on trackers) Egor remembers that somebody near this time asked his -"What happened with ETAG? Is it possible to check rightness of this trigger bit setting?". Egor with care checked all setting. All were OK. But somebody said that unwaitable high rate of ETAG is registered. May be somebody during high mentioned "TriggerBitAjustment" mistaked and changed ETAG prescaling factor from 8192 on low factor? But it is obviously that last part of ep-collisions Running (from 13:52 up to 14:49) is written mainly with ETAG-trigger bit source. Is it really so? Is it possible to check data after 13:52 on ETAG frequency? 25.06.1992 ===================== H1KFOM === Some Proposals ............ I have two ideas due to Levonian's message: 1) about lumi events at ETAG-trigger bit data flow: is it difficult to check (or may be it was checked already) where lumi events disposed along Running? May be its are disposed randomly or may me disposed locally at one place? If the second supposition is true - may be this is the consequence of Egor's checking of ETAG trigger bit setting (see previous message about "somebody") - in principle during this checking Egor could switch on short time lumi-event on ETAG-trigger bit (technical reason). If not - no idea. 2) about srange acceptance behaivour at region 15+-1GeV. May be (only supposition) our ET-cells have bad calibration. It is pity but all our calibration (off-line) was made with fixed ET-position. Only 24 May we moved ET-movable platform and had good weights for cells from 3.5 raws (e14 - e18; e21- e27; e28-e34; e35-e41). 23 cells were never calibrated with shure. In principle it is pos- sible to discuss this question with H1Lumi community and to decide something with nearest calibration on nearest e-beam with 10 bunches a) variant with old HV: - to get data with ET&PD&anti(waterVeto) or ET&PD with moving ET movable platform along Y-axis as far as possible at both directions OR - to ask of Egor to make topological trigger for getting of events from non-central layer hitting of ET (we never made this attempt) b) variant with new HV: - may be due to evidence of enough large events with overflow (10%) let`s return to discussion of posibility to install the new HV set for 10 bunches mode (it is needed to make the next manipula- tion - to decrease HV on e21 and on all cells of PD and make the same as at (a) point proposed). 25.06.1992 ===================== F11LEV === eTAG trigger was wrong? ... We carefully looked into the data together with E.Elsen and came to the definite conclusion: CTL was always right and provided consistent decisions. The problem must be in our system: Igor send ET-bit not in a proper time. The reason must be found by our experts. More details in today's H1 meeting. Be prepared to answer a nasty questions! If somebody from online side is going to be present on this meeting, he can come to my office before to look on the data and try to prepare explanation. 26.06.1992 ===================== H1KFOM === 1 BC Shifted ETAG ......... Really after off-line analyze of VETE-bank which keeps the information about our 5 trigger bits (WaterVeto-64th bit,ETAG-63th bit,PD-62th bit, ET-61th bit and ET+PD-60th bit) position at pipe line during its stopping due to L2Keep which was caused with ETAG we can say with shure that ETAG-trigger bit position during last ep-collisions was shifted on 1 bunch crossing (on T0-1 position) and S.Levonian could not look at any energy distributions any adequate pictures. The question about high rate from ETAG is not understood yet (under studying). It seems that not ETAG is the reason of high rate of L2Keep due to simple reason - after switching off ETAG at Runs23712-23715 the high rate of L2Keep was kept. I hope that careful studying of TLV1-bank can help to resolve this question. 26.06.1992 ===================== H1KFOM === ETAG Had Ordinary Rate .... From off-line analisis of TLV1-bank at Runs 23904, 23905, 23912 it is possible to note that ETAG-trigger bit had ordinary rate (not high rate). The incrementing of L2Keep-rate at middle of Run 23904 not because ETAG - as seems due trigger element "ZVTX-sig1 * not(CIP -bkwd" which had main including into L2Keep-rate. It was switched of at Run 23912 - all became resonable. ETAG was switched off without any reasons (as seems preliminary). But due to error at ETAG correlation with T0 - it is not important. ETAG was right in principle but put signal into H1CDAQ not in time. All detectors got information from another BC when ETAG hitted L2Keep. 26.06.1992 ===================== H1KSHE === ETAG Was in time (T0) ..... Accoding my last (this morning 26.06.92) investigation Etag TB. was in time. I can not move it without moving Hck signal which arrived from central trigger logic. The aver T.bits VC,PD,ET .. that I simply connect to the same cabel can have any delay becouse they are our internal logic signals from that Etag is formed. For permanent cheking the Etag correct time I have refferece Global OR TBit from VetoWall system and no time shifts was found. Cheers. 26.06.1992 ===================== F11LEV === eTAG trigger was wrong .... I have looked into VETE bank as Igor asked me, and to my understanding it is quite clear, that eTAG trigger was set wrong. I still don't know the reason for that, but as I already said before this must be checked by experts (since I do not understand much in the online trigger area) I have analysed 2 samples: 1) only selected events from the Run 23904 having E_trig(ET) > 4 GeV 2) all events on the DST from the runs 23905-23913 (appr. 700 ev.) Values I mainly looked on were: eTAG trigger bit, E_trig(ET),E_rec(ET) VETE bank contained essentially 3 (out of 64 possible) bits. Format of VETE is the following (according to the official description): col_1: Bunch no (in these runs from -2 to +29) col_2: GPTP_1 bits (0....31 in my numbering) col_3: GPTP_2 bits (32...63 in my numbering) The three bits I found in VETE were 28, 29 and 30 (i.e. GPTP_1 only) I do not know which bit means what, but it was always offset between all of them (exept may be 1% of events where bits 28 and 29 came at the same bunch crossing). As far as I understand, Fomenko had similar observation. If Igor is interested, I have many Event Display pictures containing ET,PD responces, and trigger info from TEL1, TLV1 and VETE banks. My conclusions: 1) eTAG trigger bit arrived to CTL not in a proper time (whether there was shift in BC, or T0, or event # I don't know and don't care). 2) CTL always (100%) made an adequate decision based on our eTAG bit. 3) As a result there were no correlation between eTAG trigger and LUMI detector responce: in those cases when eTAG bit was set, there were nothing in ET, and wise versa: if ET contained energy above thre- shold, eTAG bit was absent. 4) In 50% of events a good correlation was observed between E_trig in ET and E_rec (linear correlation with a slope close to 1.0: correct calibration), in others 50% E_trig>threshold, while E_rec=0. Before this a good fraction was much higher: approx. 90% 5) There was found also a linear correlation between E_trig(PD) and E_rec(PD). Unfortunately, a slope was far from 1.0, showing that online calibration used for the h/w trigger decision is wrong: C.C. are typically in 3 times less than those used for the offline reconstruction. As a consequence, much more lumi events were accep- ted by eTAG trigger (since what trigger saw as PD energy was under- estimated and often satisfied threshold condition). Now, since Igor is quite sure (see message above) that LUMI system itself provided correct eTAG trigger bit, the reason must be found between Igor's output and CTL input. What can be between: VETO GPTPs? I don't know. Who knows? +-------+ +-----------+ +-+ +-+ +----------+ | LUMI | | LUMI trig.| |G| |G| | | | detec-|===>| electro- .|=>|P|==>............. ==>|P|=>| C T L | | tors | | nics | |T| |T| | | | ET,PD | | | |P| |P| | | +-------+ +-----------+ +-+ +-+ +----------+ | | V V here eTAG bit here eTAG bit was wrong was correct (I.S.) (S.Levonian, E.Elsen) Concerning high eTAG trigger rates. Unfortunately there are no direct measurements available, but according to U.Goerlach people could not mix bit #14 (as Igor thought) with something else, since ALL triggers where eTAG was used got very high rates. My opinion is that this is not so important now. It would be nice to understand what happend with eTAG trigger, but already taken data cannot be corrected w.r.t eTAG information. Better concentrate on future and try next time to check system more carefully and do not allow everybody on CDAQ shift to switch off eTAG trigger! 26.06.1992 ===================== F11LEV === LUMI data presentation .... Now something completely different. Last year H1 LUMI Monitor was much better and considerably more succe- sful then ZEUS one. Now ZEUS has improved a lot. I saw offline pictu- res from them and must admit that they are now better than our. I am not aware about data quality, but online and offline data presentation by ZEUS Lumi Monitor is really on the professional level now. Why don't we improve as well? Those who has any ideas concerning data presentation, both online and offline are welcome to participate in the discussion. I think experi- ence of such experts like Bill Haynes is very useful. 27.06.1992 ===================== H1KFOM === (5) Conclusion Is Not Right As seems to me (5) conclusion of S.Levonian is not correct. After last serious changing of calibration coefficents of ET and PD (16.06.92) nothing was made with coefficients for Trigger Sums (last its update was made very long time ago - it was not so important as seems). The values of coefficients for Trigger Sums up to now was installed: CCETtrig = 0.004 GeV/FADCcount CCPDtrig = 0.00215 GeV/FADCcount CCET+PDtrig = 0.00498 GeV/FADCcount In principle it is possible to change its for best correlation line slope (if it is needed). I shall try (at offline) to find its best values for existing calibration coefficients. But the main - this coefficients does not affect by no means on trigger decision. Last changing at slope of correlation line was only due to last calibration coefficients update (16.06.92). So - this way of thinking "anti(PD) is not right at ETAG trigger bit making" which I looking for at least twice at last S.Levonian's message (24.06.92 - "..wrong PD calibration for the trigger which seri- ously deteriorated ET-trigger element..." and 26.06.92 ".. much more lumi events were accepted by ETAG trigger (since what trigger saw as PD energy was underestimated and often satisfied threshold condition)..") is in principle posible but not correct at present status of ETAG. Last analysis of VETE-bank shows that ETAG was very clean (during ETAG-presence it was not PD an WaterVeto trigger bits). Only shift on 1BC was problem and it was no any problem with ETAG-making. Lumi events which S.Levonian looked for at last Running were appeared only due to shift on 1bc (as me seems). Bremsstrahlung events have enough large cross-section for random appearence at neigbour bunch X-ing (especially for case of 10 neigbour bunches). (4)-conclusion is not understandable at all - very little information "50% of events - good correlation ETrec and ETtrig 50% of events - bad correlation of its". If ETAG had 1BC shift it must be no any correlation of this values as seems. If correlation exists may be Egor was right - it was not any shift? It must be checked else one with involving of VETE-contents may be for best diagnose. May be this 50% - also bremstrahlung events from neigbour bunch X-ing. Natu- rally ETtrig must have good correltion with Erec for this events. Egor yesterday said that GPTP-2 on the last 5 bit (59-63) has infor- mation about pipeline of our trigger bits (last 32 bunch X-ings). Mapping is the next: bit 59 - ET+PD trigger bit; bit 60 - ET trigger bit; bit 61 - PD trigger bit; bit 62 - ETAG (ET&anti(PD)&anti(WV)) trigger bit; bit 63 - WaterVeto trigger bit; This is the same information which must be put (at nearest future) into LRTN-bank (T0-1,T0,T0+1). Information about col_1 at VETE bank: now this information is not right. It must be tuned soon with VetoWall-people and it will be tuned on T0 for VetoWall subsytem (our T0 only randomly may be at the same place). Now position of T0 for H1Lumi at this GPTP is 19 or 20 from begin of pipe-line (it must be understood late after last Egor`s tuning of ETAG). 27.06.1992 ===================== F11LEV === End of the discussion ..... With this message I stop this endless discussion (from my side, you may continue of course) since I see no useful outcome, just spend of the time. Note, that I don't want to draw any further conclusions exept the main one which is clear: in the last data there were problems with the trigger from our subsystem. I believe, Igor will carefully check the situation before and during the next ep-runs. 1) VETE bank content. - I dont care about col_1, I just explain what I found there. If it is wrong, complain to yourself: VETE bank is your "product"; what I have seen: in 45% of events bit 28 (from GPTP_1) was found in BC=17 (col_1=17), in 40% - in BC=18 and the rest was scattered over 16 different BC (from 2 to 26). bit 29: 45% in BC=17, 40% in BC=18, the rest in 9 BCs (12-26) bit 30: 45% in BC=18, 40% in BC=19, the rest in 11 BCs(11-26) - In all of the tested events from the runs 23904-23913 there was found n o t h i n g in GPTP_2 word (col_3). I assumed that your numbering is differnt from my (0...31 bits in your case correspond col_3 and 32...63 to col_2) but even if so, I do not understand why only bits 60,61,62 (in your numbering) were present. I never saw 5 bits as expected from your explanation 2) Energy correlations. - the natural way to check trigger is to compare E_trig versus E_rec Therefore, I always did this, and observed clear difference bet- ween data from June 1 and June 23. I tried to describe my pictures in a "simple words", but I stress again that everybody can come to my office and look on them, if my explanations are not clear. Try to summaraze them once more: a) in spite of the part of statistics show linear correlations between E_trig and E_rec both in ET and PD, the slopes are different for them: June 1: ET-slope = 0.95, PD-slope = 1.45 June 23: ET-slope = 1.0, PD-slope = 4.0 I would be happy to understand clearly why we should live with PD C.C. different in 1.45 times for trigger and reconstruction (perhaps Fomenko knows an answer), but 4.0 is out of any rea- sonable limits; b) if this is true, then even with a correct timing (no shifts in T0, BC or whatever) one would expect quite a lot of lumi events to be accepted by eTAG trigger, since trigger threshold E_trig (PD) > 2-3 GeV will accept gammas with real energy of 8-12 GeV. c) If E_trig from LRTN bank have nothing to do with real trigger decisions why then to put them into the bank? Of course I assume, that E_trig from this bank somehow correspond to the values which have been used to produce trigger bits. d) Finally, in principle Fomenko is right saying that in case of wrong timing it has no sence to try to find any correlations between E_trig and E_rec. However, what warried me is the fact that it WAS a correlation, but with a wrong slope (PD case). I would understand no correlations at all, but I cannot explain correlation with a wrong slope to be a result of a time shift. 27.06.1992 ===================== H1KFOM === Tuning of Trig.Sums CC..... It were tuned calibration constants for Trigger Sums on the data of Run22730 (13.06.92) - 10 bunches 26.7 GeV e-beam. CCETtrig = 0.00442 GeV/FADCcount CCPDtrig = 0.00612 GeV/FADCcount CCET+PDtrig = 0.0044 GeV/FADCcount This new CC will be to work after Run 24417. 29.06.1992 ===================== H1KFOM === ep-collisions 10x10+1 ..... Tonight from 01:46 up to 02:15 at H1 Interaction Point it were fixed ep-collisions of 820 GeV p-beam with 10 bunches (#0-#9) and 26.7 GeV e-beam with 10 collided bunches (#0 - #9) and one pilot bunch (#19). Preliminary estimated maximum value of the current luminosity is near 3.5*10**27 cm-2s-1. ep-collisions existed near 0.5 hour. ep-collisions finished dur to p-beam was lost (firstly part of p-beam was lost and after 3 min. p-beam was lost totally). During ep-collisions it were written 2 H1Runs - 24565 (near 15 min) and 24568 (near 9 min.). ETAG was tested and as seems worked correctly. It was fixed unordinary the ratio of WaterVeto and ET&PD total rates. Rates were the next (during collisions): WaterVeto - 5000 - 3000 Hz, ET&PD total - 150 - 100 Hz, ET&PD pilot - 7-5 Hz. Dur to very low rate of pilot bunch it was looked for its large fluctuation - "CollisionMonitor" did not work. It was fixed two problems with getting of bunch currents from H1CTRIG - firstly - when Bill killed H1CTRIG-application and installed 'TEK-storage'-application. It was found and corrected. And the last problem - the values of bunch currents during near 15 min was got as zero values. Elsen found the reason and resolved this problem before ep-collisions. Bill had prepared to write Runs with ep-collisions on local H1 Local Storage (H1 had near 200 clean cartridges and was ready to write ep-collisions data into TEK-storage) due to not working DESY IBM (28.06.92 was very hot day and DESY IBM due to climat problem was stopped). But before ep-collisions DESY IBM was switched on again and all was made as always. It were appeared unwaitable problem with monitoring of calibration coefficients at Luminosity subbbranch (not photoproduction). Problem under studying. 29.06.1992 ===================== F11LEV === eTAG trigger ok in last run Quick analysis of the latest ep-data (taken today around 2-3 p.m.) shows that eTAG trigger is now okay. No shifts, CTL input/output always correspond to the LUMI detector response. More details on the trigger meeting tomorrow. It could be that I will just provide a brief summary for Eckhard Elsen before meeting and he will present 2-3 foils Still one unclear question exists concerning "dip" around 15 GeV at ET energy spectrum. Now it is even more prominent. I would say even that it looks now like more or less obvious background from off-momen- tum electrons (large peak around 21 GeV), if not some new trigger or calibration artefact. Needs more thinking and analysis. 29.06.1992 ===================== H1KFOM === two ep-collisions 10x10+1 Today it was fixed twice with the same p-beam and different e-beams ep-collisions at H1 Interaction Point. Ten bunches of 820 GeV protons had collided with 10 bunches of 26.7 GeV electrons and one electron bunch was existed without colliding as reper - as pilot bunch. First ep-collisions started near 10:43 and finished near 15:08. The second ep-collisions started near 16:35 and finished at 19:39. During first collisions it were written H1 Runs (first number is 24599 the last 24630). During second collisions it were written H1 Runs from 24638 up to 24654. Integral Luminosities Values which were calculated at OnLine ( and are preliminary estimations) the next: First ep-collisions: Total - near 5.2*10**31 cm-2 Effective - near 4.3*10**31 cm-2 Both ep-collisions: Total - near 7.7*10**31 cm-2 Effective - near 6.1*10**31 cm-2 As You read at HERANEWS pinboard - our estimation of current lumino- sity value was another as ZEUSLumi-team at first ep-collisions and ZEUSLumi`s value was more reasonable. Preliminary analyze of situation shows that (as seems) threshold at PD-arm of our H1Lumi-system seems more then earlier (reasons under study). In principle this explanation put answer on the question - why our luminosity value estimation less then ZEUS (we had another acceptance but used 23.8 mb cross-section). ET-coordinate plot shows that there is a little population of high energy electrons at ET&PD-events (due to absence of low energy photons). The maximal values of current luminosity were: 1.2*10**28 cm-2s-1 at first ep-collisions (at near 10:53) and 8.0*10**27 at the second ep-collisions (near 16:37). The behaivour of current luminosity value with time was different for different Running: at first ep-collisions the degardation of current lumi value was more then at the second: First ep-collisions: Second ep-collisions: Value*10**27 Time Value*10**27 Time 12.0 10:53 8.0 16:37 4.0 12.00 5.0 17:30 2.0 13:00 4.0 18:30 1.8 14:00 3.8 19:30 1.5 15:00 Time slice of bunch current values at 12:21:15 29.06.92(first collis) and bunch rates of ET&PD-events: e0 - 121 mkA p0 - 53 mkA 21.2 Hz e1 - 126 mkA p1 - 60 mkA 27.1 Hz e2 - 90 mkA p2 - 67 mkA 17.3 Hz e3 - 117 mkA p3 - 71 mkA 23.5 Hz e4 - 91 mkA p4 - 73 mkA 19.2 Hz e5 - 83 mkA p5 - 76 mkA 8.6 Hz e6 - 103 mkA p6 - 73 mkA 26.3 Hz e7 - 61 mkA p7 - 74 mkA 12.5 Hz e8 - 92 mkA p8 - 70 mkA 16.5 Hz e9 - 94 mkA p9 - 67 mkA ??.? Hz e19 - 111 mkA p19 - 0 mkA 19.6 Hz. Rate of ET&PD total - 197 Hz Rate of WaterCounter - 6800 Hz Rate of PilotBunch ET&PD - 19.6 Hz. BeamPosition Monitor values at 14:33 29:06:92 (first ep-collision) Xpd=-0.77cm, Ypd=-0.52cm. 30.06.1992 ===================== H1KFOM === New Release of OnLineProgr. It was issued the new release of H1LumiOnLineRecNew19-program for FIC#2 (LumiMeasurement FIC). The next changing was made: 1) the last changing of values for FADC-windows were implemented before this release - 100(ET),48(PD) at this release - 98(ET),40(PD) 2) it was implemented new mode for PilotBunchRate averaging during large rate jumping: before this release RatePilotPure was calculated as last measured va- lue of PilotBunch Rate if new (last measured value) was more then RatePilotPure*3.333 or less then RatePilotPure*0.1666 at this release - the same but ... more then RatePilotPure+3*sqrt( abs(RatePilotPure)) ... or less then RatePilotPure-3*sqrt(abs(Rate- PilotPure)). It was made due to problem which was appeared when we had experience with low rate of PilotBunch(some Hz - less then 10 Hz). "CollisionMo- nitor"-desk accessory did not work - only jumpings. 3) It was changed the default value of WaterCounter Calibration Coef- ent (due to last night experience) - but only for Luminosity subbbranch (not Photoproduction !!!!). Into NewFastLumiMonitor-environment it was added new option - it is possible now to switch off the LRTS-bank (if it needed). Special button was added on card "BanksSet"-menu "DAQStatus" - item "BanksSet". It was made due to request of Jan Olsson sometimes to switch off this bank (very large - almost 30 Kbytes). This switching off must be tested with H1CDAQ (with default this bank always on) due to involving of new branch at subroutine OutBanks.f (before this never worked). 30.06.1992 ===================== F11LEV === LUMI banks setting ........ I forgot to mention yesterday, that in some runs (or pieces of runs) LRTN bank was absent for unknown (for me) reason. Perhaps our online system is too flexible allowing to switch on/off any set of LUMI banks. But I thought we agreed that some absolute minimum of banks should be present always: LREE,LRPE,LRTE,LRTN. Others can be optional. Another warning: overfows at ET are still increasing. In the data from yesterday there was found 19% of those (on the limited statistics: 5700 events -> 350 eTAG candidates). In photoproduction (eTAG) trigger I also observed some evidence of higher PD threshold compared to (at least) 1 bunch mode at June 1. That means, that eTAG events are not so clean as before: more events with E(PD) of the order of 6-9 GeV are accepted by eTAG trigger. This is in agreement with a guess that less lumi events were accepted by LUMI trig ger due to the PD threshold (see previous message of A.Fomenko). 01.07.1992 ===================== H1KFOM === three ep-collisions 30-01.7 I am sorry but my friends (Y.Soloviev - yesterday at day time, I.Shevi- kov tonight) nothing wrote about ep-collisions which were fixed from yesterday morning up to end of last night). I hope that they will write more detail about its later but before its message I shall put a little information about this ep-collisions (which I found at H1Lumi LogBook): 1) 1st - from 11:06 up to 15:19 ( a little more then 4 hours) at 30 June 1992. It were written the next H1 Runs during this period: 24732 - 24738 Integrated Lumi per Running - total 1.31*10**32 cm-2 effective 2.45*10**31 cm-2 2) 2nd - from 17:28 up to 20:22 ( a little less then 3 hours) at 30 June 1992. It were written the next H1 Runs during this period: 24752 - 24765 Integrated Lumi per 1st and 2nd Runnings (was fixed at 20:09 13 min before end of the second Running - later info is absent) total 8.30*10**32 cm-2 effective 5.51*10**31 cm-2 3) 3rd - from 00:30 up to 03:48 ( a little more then 3 hours) at 01 July 1992. It were written the next H1 Runs during this period: 24791-24793,24805,24809,24811,24823,24829,24833,24834 Integrated Lumi per Running - total 1.21*10**32 cm-2 (from Egor`s calculation due to nor right monitoring beca- use problems with bunch numbers) effective ????????????????? 01.07.1992 ===================== H1KFOM === two ep-collisions 01.07.92 Today it was fixed two ep-collisions of 820 GeV protons with 26.7 GeV electrons (10x10+1). 1) 1st collisions were started at 09:18 01.07.1992 and finished at 10:25 (existed only 67 min) due to unwaitable e-beam lost. It were written the next H1 Runs during this period: 24853 - 24859 The values of beam current after ramping: Ip = 600 mkA Ie = 1830 mkA Integrated Lumi per Running - total 7.66*10**31 cm-2 effective 6.06*10**31 cm-2 The current value of Luminosity during this Running was near 3.0 - 2.5 * 10**28 cm-2s-1 Maximal value was fixed at beginning of ep-collisions - near 6.0*10**28 cm-2s-1. 2) 2nd collisions were started at 12:17 01.07.1992 and finished at 13:21 (existed only 64 min) due to unwaitable e-beam lost. It were written the next H1 Runs during this period: 24861 - 24863 The values of beam current after ramping: Ip = 590 mkA Ie = 2280 mkA Integrated Lumi per both 1st and 2nd Runnings total 1.82*10**32 cm-2 effective 1.50*10**32 cm-2 The current value of Luminosity during this Running was near 3.0 - 2.5 * 10**28 cm-2s-1 Maximal value was fixed at beginning of ep-collisions - near 5.5*10**28 cm-2s-1. Between this two Running I switched off the H1Lumi bank LRTS. This bank will be switched on only with asking of S.Levonian. At the begin of the second Running I switched on new option for calculation of PilotRate (on 10 sec. averaging) - the fluctuation of measured Lumi became less. 01.07.1992 ===================== H1KFOM === third ep-collisions 01.07 Today afternoon at 15:12 it was began the injection of new e-beam. Proton beam was kept with Ip=590 mkA. Ramping was started at 15:23 with Ie=3079mkA (10+1 bunches) and was finished at 15:27. At this time ep-collisions were started with current luminosity value near 5.0*10**28 cm-2s-1 (Ip=590mkA,Ie=2740mkA) At 15:30 collimators for protection from synchrotron radiation were moved. At first time Ie was decremented with high rate: 15:27 - 2740 mkA 15:33 - 2300 mkA 15:36 - 2140 mkA 15:37 - 2060 mkA 15:36 - 2140 mkA 15:54 - 1560 mkA 16:01 - 1615 mkA (Ipilot = 138mkA,I#0-I#9 = 114 - 151 mkA) 16:08 - 1450 mkA 16:11 - 1372 mkA 16:17 - 1318 mkA 16:43 - 1250 mkA (Ipilot = 112mkA,I#0-I#9 = 93 - 122 mkA) 17:36 - 1060 mkA 18:04 - 930 mkA 18:15 - 860 mkA 18:41 - e-beam was killed with asking of H1 Run Coordinator D.Newton Integrated Lumi per 1st, 2nd and 3rd Runnings total 2.45*10**32 cm-2 effective 1.92*10**32 cm-2 The current value of Luminosity during this Running was mainly near 1.2* 10**28 cm-2s-1 Maximal value was fixed at beginning of ep-collisions - near 5.0*10**28 cm-2s-1. It were written the next H1 Runs during this period: 24871 - 24902. At 18:54 it was attempt to inject new e-beam with "very old" p-beam Before ramping this beam was lost (at 19:31). 01.07.1992 ===================== H1KFOM === Bunch Currents Problem .... Today firstly was observed the unwaitable situation with bunch currents delivering into H1Lumi from H1CTrig. At 20:09 it was started new e-beam injection. On bunch currents monitoring card it was possible to look for current from first (#0) bunch - but after this it was obviously that Ie is incrementing - we saw incrementing rate of ET&PD-total, we saw incrementing value of Ie on TV-screen but at our subsystem we had onle current from #0-bunch. Petr asked ZEUSLumi team - they answered - all is OK with currents. It means that currents are measured right and in principal are transla- ting into H1CTRIG. Our H1 Run Coordinator was informed by Petr with this problem. I informed of H1 Shift Leader - Mr.Kiesling. He talked with E.Elsen and the problem was decided. The reason was due to last bad status of H1CDAQ (Running without IBM Logging - the program on IBM was killed). After Abort Run and attempt (unsuccesful) to Start Run H1CTRIG received right information and retranslated to H1Lumi. 10 minutes of ep-collisions existed without our measurements. At 20:33 we started to measure the luminosity at 4th Running of 01.07. Really ep-collisions existed from 20:23. Current value of luminosity at the last 25 min. is near 7.5-8.5*10**27 cm-2s-1. 02.07.1992 ===================== H1KSOL === Luminosity RUNS ........... During Lumi run started at 20.15 and finished at 0.37 the following H1 Runs were logged on IBM: Run 24918 - 24922. 04.20 the next ep-run started,p-current=420,e-current=1100 microamps. The max value of lumi of order 7*10**27. The following H1 runs were logged during this ep-run on IBM: Run 24930 - the last 15 minutes, Runs 24931 - 24935. Problems in this shift: 1.Integrated luminosity value at time 23.52.35 = 2.9*10**32 This value at time 00.47 = 2.7*10**32 2.Before last run it seems to be RESTART from CDAQ was done and default options were installed - Lumi trigger was changed and iteration pro- cedure for luminosity calc. was not switched off. 3.Just before end of last run shift coordinator inform me that the Etag trigger rate increased by factor 10 (trigger bit 0 in word 1). !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! In accordance with D.Newton request we should zeroed integrated ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Luminosity before each ep-Run! ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 02.07.1992 ===================== H1KFOM === New Release of OnLine ..... Today it was introduced the new release of H1LumiOnLineNew19-program for FIC#2. The next changing were made: 1) new calibration coefficients set for Lumi-subbranch (not Photopro- duction !) were installed as default values (CC was got yesterday during ep-collision Runnings with good statistics of ET&PD&anti(WV) events (near 100000) and CC for WaterVeto was got 30.06.92 with ET&PD events and fixing of ET and PD calibration coefficients (calibration weight near 1000.0); 2) it was installed as default option for not using of averaging with iteration formula of the pilot bunch rate ( its rate will be calcu- lated now as earlier - averaging on last DT1=10 sec.); 3) It was also removed the option which was introduced at previous release - I returned to previous calculation of RatePilotBunch for "CollisionMonitor"-desk accessory during large jumping - not +-3*sqrt(PilotRate) for recognition of large jumping but jumping more then 3.333*PurePilotRate and less then 0.1666*PurePilot Rate. NOTE: Yesterday I asked Sasha Usik to write into LLO his proposal about PilotRate jumping recognition. Today I found nothing at LLO. This is not good as me seems. I don't know why but Sasha ignores last my asking to write something into LLO (for example- little remarks about last releases of DeskAcces- sorries). As result - at new release of DA "H1_Lumi_Monitor_ 02.07" - it is appeared some new values which are monitoring Lumi=X.XXe+XX +- X.XXe+XX (sigma) Rlumi=0X.XXe+XX Spec.lumi = X.XXe+XX Rbg/100mkA = XXXXX I don't know what is this and where I must know about this. But it is possible that today somebody will ask - what is this Soloviev said that Sasha wrote all into LLO - but nothing at LLO. This is not good too. 02.07.1992 ===================== H1KFOM === Bunch Currents Problem (re) Today the yesterday problem of bunch currents was discussed with John Coughlan. All details of this event were reported to him. He got some time and just now put information that it was possible situation. No problem with bunch currents receiving with H1CTRIG when status of H1CDAQ is "Running"-without problems or "Stopped". Yesterday it was fixed the status "Running"-with problems (yellow line at IBM Logging- task - "No Channel Program Running on the IBM"- No New Event-message at Message Log"). In principle there is recomendation - when the same problem will appeare at future - the best way to avoid it - ask H1 Shift Leader to make "StartRun" (with Abort or Stop of Previous Running which had problems (mentioned above for example). 02.07.1992 ===================== H1KFOM === Estimation of Lumi Value .. Today morning David Newton discussed the problems of Lumi-measurement with me and Youri and said that at Monday we put Lumi-values less then it was predicted HERA-people (on 2 times) but yesterday we put Lumi- values on near 2 times more then it were predicted. He gave to us the formula for Lumi value estimation from knowing of electron and proton currents ( this formula is used by HERA-people for estimation of possible luminosity value): L = 7.0*10**27 * ( Ie(mA)/1.6 ) * ( Ip(mA)/0.8 ) where L - current luminosity value (cm-2s-1) Ie(mA) - total electron current at milliAmp Ip(mA) - total proton current at milliAmp D.Newton said that this formula is got from B.Wiik. 02.07.1992 ===================== H1KFOM === Bill's promissings ........ Today Bill promised to change hard disc at H1Lumi MacII with new (120 Mb capacity) and to add memory into H1Lumi MacII up to 8 Mbyte. 02.07.1992 ===================== H1KFOM === ETAG counts at Run 24935 .. It was analyzed first 12890 events from 20283 events of Run 24935. This Run was started at 06:02 02.07.92 and finished due to end of beam. At H1Lumi logbook Youri wrote that at 06:20 H1 Shift Leader Mr.Pascaud said him that he is looking for high rate at ETAG*V*Z*T trigger bit (bit 0 at Trigger Word 1). Ordinary rate was near 0.5 Hz. At this Run he is looking for rate near 7 Hz (14 times more). Really from first 12890 events of this Run 4996 events was produced with this trigger source. At this Run it was involved not all trigger bits with ETAG: bit 0 - etag * v * z * t -4996 events from 12890 bit 1 - etag * v * TOF-IA - 50 events from 12890 bit 2 - etag * v * z * BPC - 165 events from 12890 bit 3 - etag * v * z * zvtx-Sig1 - 47 events from 12890 bit28 - etag * v near 100 events from 12890 (but prescale factor existed) bit14 at Subtr.1 was switched off Really this piece of data got 18 min. - so rate of bit 0 was near 4.5 Hz (averaging at all time period). All our archive kept trigger rates at this time had not any jumping (ET&PD total, ET&PD-pilot and WaterVeto). 02.07.1992 ===================== F11LEV === H1 gated luminosity ....... As it turned out after discussion during todays physics plenary, and also after I clearify the point with Eckhard Elsen, the H1 gated lumi (what you call "effective luminosity") is calculated incorrectly. I remember, that I asked about this one month ago and got an answer, that dead time is correctly taken into account. However, it is not true since between runs the dead time counter which Fomenko is using, stays as it was at the end of the previous run (intentionally!) while we have to use of course value of 0 (100% of dead time between runs). Please correct on that as soon as possible! You must have a signal at the end of the run, so it should not be a problem to distinguish that now there is no data taking (time between runs). 03.07.1992 ===================== H1KSHE === Etag again ................ I very ask all of H1LUMI Shifts to run DA "Intensity_b09" and looking after the red line. This line reflects the rate of Etag trigger. When this rate reaches unwaitable value please call me as soon as possible at any time and please do the same when central trigger will show relevant rate increasing. Unfortunatly this strange behavior of Etag trigger happend twice for the last time and I can not catch the situation. 03.07.1992 ===================== H1KSHE === Luminosity Run............. Yeststedy 03.07.92, it was detected two unexpected increasings of Etag trigger rate. First at 18:46 , 2min duration and second at 21:40, 0.4 min duration. Unfortunately both of them had the visible correlation with corresponding increasing rates in Veto/Wall system. So probably this efect is due to some manipu- lations in e-beam region, caused for instance by keeping beam alive automatic and has different nature then was observed earlier. Luminosity Run : Start at 01:35 04.07.92 Stop at 07:00 04.07.92 max. Lumi 2.8 * 10**28 ! (something wrong) <--- why do you total Lumi 1.17* 10**32 think so ? eff. Lumi 5.94* 10**31 (S.Lev.) becouse of estimated value < 2.0*10**28 cm-2s-1 for given currents (I.Shev) Data logging: Runs: 25113,25114,25115,25116,25117 04.07.1992 ===================== H1KMAL === Luminosity Run 3.07 - 4.07. During last two shifts (3.07 - 4.07) the new collisions at HERA were run. The proton beam was stored at 15:20 3.07.92 with current 1.04 mA. At 17:49 the 1.02 mA electron current was ramped. The collisions started from 17:57 with the Luminosity value about 2*10**28 and continued up to 22:00 (L = 4*10**27). Running was stopped due to the electron beam loss. New attempt to get collisions was made at 1:50 ( 4.07.92) with Ip=0.72 mA and Ie=1.45 mA. The stable regime for Luminosity running was achived at 2:33 with Luminosity value 2*10**28. But unfortunately at this time the H1 had not the Data loging and we updated the erroneous values of electron bunch cur- rents (old values??). Due to this reason we had the mistaken Luminosity value: incresed about 35%. This divergence have disappeared with the start of H1 Datataking at 3:04. From this time we have the correct luminosity value, coinciding with the expected(Bialovons). During last shift the jumps of the VETO rates were observed again. It seems that they really are connected with the H1-start(stop) procedure. At 7:00 the Luminosity run was cut short due to the proton beam loss. The two curves: green - total rate of trigger and blue - rate of back- ground, separeted before that ( at MaCII screen ) have merged. 06.07.1992 ===================== H1KFOM === ep-collisions 10x10+1 ..... After midnight from 0:52 06.07.92 up to now (03:57) it were fixed ep-collisions. Ten bunches of 820 GeV protons are collided with 10 bunches of 26.7 GeV electrons (bunch numbers from #0 up to #9). Bunch #19 of e-beam exists as pilot-bunch. At 0:52 total proton beam current was 1320 mkA and total electron beam current was 1410 mkA. Current luminosity value was fixed at this moment as 3.5*10**28 cm-2s-1. At 01:35 its value was near 3.0*10**28 cm-2s-1, at 02:45 - 2.0*10**28 cm-2s-1, at 03:45 - near 1.5*10**28 cm-2s-1. Now (04:12) - Ip=1280 mkA, Ie=650 mkA, L= 1.4*10**28cm-2s-1. During ep-collisions H1 wrote the next Runs (up to this moment): 25237,25238,25239,25240(now written). On this moment (04:15) - Integrated Luminosity Value is near 2.48*10**32 cm-2, Effective - near 1.07*10**32 cm-2. Runs 25237-25238 were written with large dead time of H1. From Run 25239 it was changed (from 0 to 16) prescale factor for very fast trigger bit (bit 14 - ZVTX-sig1*...) and now dead time of H1 is near 40% (rate of L2Keep- near 8-10 Hz). As seems this ep-collisions put on H1 and ZEUS the record value of luminosity for today. We never looked for this values of lumi. Information for thinking: e32-cell at ET as seems is dead. On the calibration monitor it has very low value of weight. First evidence of this type of behaivour was looked for at previous ep-collisions. I changed the constant for labeling of t0 at VETE-bank (at 01:58) during Run 25237. Default value is 2, now is 14. This manipulatiion is made at BankSet card of NewFastLumiMonitor. S.Levonian asked to all of H1Lumi shift to fix sometimes the current status of "Energy Plot". I fixed it three times (at 01:27, 01:50 and 02:10). The situation is equal without any changing with time. Coefficient of Lumi-event trigger is near 0.84 (not changed). At single rate of ETAG I looked for rate near 1300 Hz. It was not fixed any jumping at rate of ETAG. I tested status of LRTS-bank. It was switched off before my shift and now too. It is very pity but new H1CTRIG bank TCUR with bunch currents which is written may be once per 50 sec. at KEEP-environment is not correct. First test of this bank contents at tthe data of ep-collision from 29 June 1992 shows that especially e-bunch currents almost always are crashed with another bank-contents. The length of this bank is strange too. I sent to E.Elsen e-mail with asking to test else one the contents of this bank. 06.07.1992 ===================== H1KFOM === D.Newton`s information..... Yesterday evening David Newton gave to me very interesting data from his investigation during last ep-collisions. He (not always) wrote next current values: Ip, Ie, Current Lumi values (from H1Lumi). He said that at addition to previous information from B.Wiik he now has four different estimations of so-called Specific Luminosity Value: As You remember - formula from B.Wiik was presented at message from 02 June 1992: L = 7.0*10**27 *(Ie(mA)/1.6) * (Ip(mA)/0.8) this formula is equivalent to the next: L = 0.6*10**29 * Ie(mA) * Ip(mA) / N , where N- number of bunches First coefficient is different for different experts at HERA: 0.6 - B.Wiik 1.4 - F.Willeke 1.7 - W.Bialowans 2.0 - E.Lohrmann D.Newton defined the value of this coefficient from H1Lumi-measured Luminosity value and found that (data from Friday 3 July, 18:00-22:00) At the start of ep-collisions - this coefficient is nearest to E.Lohrmann`s value,at middle phase - close to W.Bialowans and F.Willeke `s values and at the end of ep-collisions - close to value which was predicted by B.Wiik. In principle (if TCUR-bank will be corrected) it is possible to test this conclusion on the different ep-collision Runs. 06.07.1992 ===================== H1KFOM === ep-collisions 10x10+1 (2nd) At 05:28 06.07.92 e-beam with 527mkA was killed and ep-collisions about I wrote at previous message was finished. Last Run which was written with previous ep-cpollisions is 25249. This ep-collisions was continued almost 4.5 hours. Integrated Lumi at the last moment was 2.2*10**32 cm-2 and effective- 8.7*10**31 cm -2. It means that during "WarmStart" it is appeared the negative value of Luminosity and put large collection of negative integral luminosity into both integral values. I made attempt to switch on the very old mode (1) of calculation Lumi- for the next ep-collisions (when next measured value is negative - the previous value is got and never negative value put into both integral values). The p-beam was kept with Ip=1260 mkA. At 06:36 (after one hour) new e-beam with 10+1 bunches was ready. Total e-beam current was 1480 mkA at the start of ep-collisions. At first period it was fixed the value of luminosity as 3.8*10**28 cm-2s-1. Now we have Ip=1110 mkA and Ie=1120 mkA, L=2.3*10**28 (07:06 06.07.1992). From beginning of this ep-collisions it was wrote the next H1 Runs: 25250,25251 and current Run25252. Evgenio said that this shift was fantasical - we never got so much luminosity from HERA! 06.07.1992 ===================== H1KSOL === Luminosity Runs ........... Luminossity Run started at 6.30 was finished at 11.20 coarse of quenching alarm in P-ring. The total integrated Lumi - 1.6 * 10 ** 32 Effective - 9.86 * 10 ** 31 The following H1 runs were logged 25252 - 25290 During this ep run beams seperation in space was performed for time interval about 15-20 min. The Luminosity goes down during this time by factor 10. Usik said that the separation was done not completely as they were afraid to lost beams. 06.07.1992 ===================== H1KFOM === TCUR-bank OK now .......... Today morning E.Elsen said that really it was existed some problems with structure of TCUR-bank at previous Runs. He hopes that now this problem is resolved and it is possible to test the contents of this bank at last Runs (may be this night Runs). It is good news for us. 07.07.1992 ===================== H1KSHE === Luminosity Runs............ The two lumi runs; from 20:57 (06.07.92) to 00:23 (07:07:92) - first one and from 1:40 (07.07.92) to 07:26 (07.07.92) the second had taking. Nothing unusual happend to be write very much about. Luminosity Run: 20:57(06.07.92) - 00:23 (07:07:92) max. Lumi(start of run) 2.2 * 10**28 cm-2s-1 total Lumi 9.4 * 10**31 cm-2 eff. Lumi 6.99* 10**31 cm-2 L at the end of run 4.0*10**27 cm-2s-1 Data loging: Runs: 25329 - 25342 Luminosity Run: 01:40(07.07.92) - 07:26 (07:07:92) max. Lumi(start of run) 1.5 * 10**28 cm-2s-1 total Lumi 7.8 * 10**31 cm-2 eff. Lumi 5.3 * 10**31 cm-2 L at the end of run 3.2*10**27 cm-2s-1 Data loging: Runs: 25348 - 25373 07.07.1992 ===================== F11LEV === Lumi data from online ..... Hello, I have a simple request to Lumi shifts. Could you provide lumi data in a COMMON form for EACH luminosity run? Just fill a sort of a table, e.g. in the following way: Date: 7/07/92 Collision time: hh:mm - hh:mm ! Start and end collision times Currents (mkA): Ie=...., Ip=.... ! beam currents at start time Peak luminosity: 3.5*10**28 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: ! Integrated lumi H1 gated lumi: ! So called "effective" lumi H1 runs: 25237-25249 ! Which runs were recorded Additional comments: ! Here you can put any comments ! concerning lumi data. This would help a lot for the offline analysis (before we will have an automatic procedure updating database etc.) Of course all other important observations should apper as well (like unusual behaviour of trigger rates, calibration news, etc.), but the LUMI table should be filled for all ep-collisions! Please, do not ignore this request. 07.07.1992 ===================== H1KFOM === M.Zimmer's request ........ Today morning Manfred Zimmer asked to make some activity for delive- ring of current luminosity value at beginning of Run and at finishing of Run to H1 CDAQ supervisor through LAN. Me and Egor said that at H1Lumi-community we have LAN-man - Sasha Usik - and for him (we hope) there are no problem to add into the next release of H1_Lumi_Monitor the posiibility to contact with Manfred`s MacII with H1CDAQ supervisor facility on the board. Asking to Sasha Usik - contact please with Manfred for technical details understanding. May be it is needed to translate at the EndOfRun the values of Integrated Lumis (Total and H1Gated) - discuss please with Manfred - is it needed or not. I think that it is needed to translate to Manfred's MacII the values which are made at FIC#2-board - not internally calculated at H1Lumi_Monitor. In principle it is possible to discuss any other proposals. 09.07.1992 ===================== H1KFOM === ep-collisions 10x10+1...... Date: 8/07/92-9/07/92 Collision time: 19:37 - 03:59 ! Start and end collision times Currents (mkA): Ie=2500, Ip=1000 ! beam currents at start time Peak luminosity: 4.8*10**28 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.76*10**32 ! Integrated lumi H1 gated lumi: 1.40*10**32 ! So called "effective" lumi H1 runs: 25495-25519 ! Which runs were recorded 09.07.1992 ===================== H1KSOL === Lumi Run .................. Date: 9/07/92 Collision time: 11:17 - 17:03 ! Start and end collision times Currents (mkA): Ie=1500, Ip=1000 ! beam currents at start time Peak luminosity: 2.0*10**28 ! Max lumi, usually at start time ! Total lumi: 9.56*10**31 ! Integrated lumi H1 gated lumi: 6.19*10**31 ! So called "effective" lumi H1 runs: 25523-25546 ! Which runs were recorded Additional comments: Hera people gave us on misstake 3 pilot bunches: #19,#23 and #26,with approximately equal bunch currents: #19 = 48 microamps #23 = 47 microamps #26 = 51 microamps For background measurments bunch # 19 was used. One could observe from on line data that systematic shift in lumi measurments is of order 1.%, in spite of that algorithm #1 for Lumi was swiched on. One should check it in off line analisis. 10.07.1992 ===================== H1KSHE === Luminosity Run ............ Date: 10/7/92 Collision time: 04:40 - 07:40 ! Start and end collision times Currents (mkA): Ie= 2100 Ip=1190 ! beam currents at start time Peak luminosity: 5.2*10**28 ! Max lumi, usually at start time ! Total lumi: 1.5*10**32 ! Integrated lumi H1 gated lumi: 1.25*10**32 ! So called "effective" lumi H1 runs: 25575-25588 ! Which runs were recorded Additional comments: 9 +1 - e.filled bunches, 10 - p.filled bunches i.e. it was additional proton pilot bunch. 10.07.1992 ===================== H1KFOM === ET CC Behaivour with Time As You remember our H1Lumi-system puts LREC- and LRPC-banks at diffe- rent places. First place - at RunStartRecord - this banks contain the values of calibration coefficients for "Photoproduction Brunch". This values never changed after last difficult calibration procedure (if You remember - getting special Run with etag as ET&PD trigger, off- line calibration, inserting of new values into H1LumiOnLineFIFOC- release). The second place - at KEEP-environment - this banks contain the values of calibration coefficients for "Luminosity brunch". This banks now are written into H1DataFlow each 11 sec. (after next near 100 events passed through calibration). This values are changed permanently during presence of 26.7 GeV at HERA e-ring due to existing of permanent calibration procedure at FIC#2 which is responsible for luminosity measurements. It is clear that CC set for this both branch are different due to different channels (preamplifiers, FADCs) and 10nsec accuracy of FADC-digitization. But in principle we can wait that there is set of special coefficients (own coefficient for each 75 amplitude channels of ET,PD and WCounter) which it is possible to use for getting of "real" CC at "Photoproduction Branch" from measured and monitored CC set at "Luminosity Branch" with multiplication. As You know now at off-line analize it is used not changable after last calibration set of CC (16.06.92 after last timing changing). It were analized the behaivour LREC- and LRPC-banks contents with time during one of the last ep-collisions (06 July 1992 06:36-11:20). Near 280 min. time period was observed. This is the short observation of this preliminary result (only for ET just now): 1) it is obviously now that CC for channels which have high rate are changable with time. ET had 10 channels with high rates at this ep-collisions as pictures show ___________________________________________ | | | | | | e33 | e34 | e-beam ___________________________________________ X | e21 | e22 | e23 | e24 | e25 | e26 | e27 | ___________________________________________ | | | | | | | e20 | ___________________________________________ 2) all these channels CC had the same behaivour with time - jumping on less value (from start values which were remebered from last ep-collisions finishing when rates were not so high as at start) and after that incrementing with time on start level. It means that really at first time of collisions all high mentioned channel had enough high individual rate (may be more then 400 KHz as was installed by Belousov and Petr two weeks ago) and as result pulse height was incremented and CC was decremented due to this situation. 3) Which are the scale of problem: ___________________________________________ | | | | | | 2.4%| 2.4%| e-beam ___________________________________________ X | 6.5%| 4.3%| 6.9%| 6.1%| 5.1%| 3.5%| 2.9%| ___________________________________________ | | | | | | | 6.0%| ___________________________________________ This percent digits shows which are the deep of first jumping down of CC during high rate appearence. 4) Possible ways of using this information: - do not correct CC at Photoproduction Branch but take care that we have this possible source od systematic error at energy spectra - to try correct CC for Photoproduction brunch with using of some parametrical formula of behaivour with time, But I am afraid that it is very delicate tuning procedure ( it depends from present rates) - may be is is needed to correct with take into account the values of current rate). But we have not information about rates at individual channels - only integrated rate per ET or PD or Wcounter through LRTS-banks contents processing. And it depends from prehistory (which were rates during finishing of previous ep-collisions - these rates defined CC-set at start of present ep-collision). In principle it depends from beam position (especially for PD). I think that it is enough difficult manyparametrical task. In principle this task can be resolved but it is needed to collect inforamtion about behaivour of CC with time from all ep-collisions and make some conclusions. 5) all another channels at ET (exept 10 high mentioned) had CC changing with time at region from -1.40% up to +1.5%. e41-channel had behaivour of CCe41 similar as high rate channel but without jumping at the first period - may be it means that this channel have bad calibration coefficient and its CC incrementing on 2.1% during 280 min. is due to finding of more precise value for CCet41. 6) In principle there is the set of special coefficients which are connected values of CCset for "Photoproduction Branch" with ones for "Luminosity Brunch" Ksp(i) = CCph(i)/CClumi(i). This set were got from start situation at analyzed ep-collisions (may be it is not right - only preliminary): e00=1.22 e01=1.23 e02=1.24 e03=1.23 e04=1.21 e05=1.23 e06=1.34 e07=1.23 e08=1.20 e09=1.26 e10=1.29 e11=1.24 e12=1.20 e13=1.18 e14=1.12 e15=1.11 e16=1.05 e17=1.20 e18=1.16 e19=1.13 e20=1.14 e21=0.80 e22=0.83 e23=0.83 e24=1.00 e25=0.85 e26=0.89 e27=0.88 e28=1.08 e29=1.16 e30=1.01 e31=0.95 e32=0.82 e33=0.95 e34=1.06 e35=1.26 e36=1.06 e37=1.05 e38=1.07 e39=1.02 e40=1.10 e41=0.96 e42=1.23 e43=1.35 e44=1.20 e45=1.22 e46=1.09 e47=1.21 e48=1.21 At future calibration we must measure the CCset during the same time at both branches simultaneously and fix this relation coeff. set during similar conditions at both branches. Now it is possible to analyze another data from another ep-collisions. May be it will be found another interesting correllation with different measured parameters and CCset behaivour with time. Situation with PD-CCset is more difficult due to very large depen- dence from beam-position at prehistory and at present collisions. This data under studing and understanding. 10.07.1992 ===================== H1KFOM === Archive of ep-collisions Some days ago Evgenio and me decided to make H1Lumi archive of info- rmation about each ep-collisions which we observed. The basis for making of this archive is the contents of LRTL and TCUR banks. In principle (as You can understand from my previous message) it is important to collect and LREC- and LRPC-banks too. This activity must be made immediately after finishing of next ep-col- lisions due to short live time of F11JOL.H01.TESTCAL.GXXXXV00cartridges May be the contents of this cartridges is kept anywhere else (after some days) but as seems only 100 cartridges involved into loop for collection of StartRun/Keep/EndRun-banks and only 100 last cartridges it is possible to use for selection of LRTL- LREC- LRPC- TCUR-banks. In principle it is possible to select these banks from H1RAWD.C92XXXXX cartridges - but as short experience shows - this procedure get more CPU-time for selection (for example - selection of LRTL-, TCUR-, LREC- and LRPC-banks with HEAD-bank as basis gets near 2 sec. of CPU IBM 3090 if You select ones from TESTCAL-cartridges and near 90 sec if the same is made from H1RAWD-cartridges. First step for archive creation - making of lists with different interesting information: list of Runs with Start/Stop time, list of H1GatedLumi-values per cartridge and per Run (at mb-1), list of H1RAWD-cartridges with Runs from this collisions, list of TESTCAL- cartridges, list of values of p- and e- currents (rough from HEAD) during RunStart and StartOfNewCartriddge time, list of TriggerSetting from HEAD for each Run etc. All this very interesting information it is possible to select from Jan Olsson's complete summaries. Second step for archive creation is the making of data set on cartridge which keeps all high mentioned banks from all Runs which were written during last ep-collissions. The last step - making of different pictures from this data at LOOK-environment and putting its into special folder at 121 room with name "ep-collisions July 1992". Example of lists is kept at H1KFOM.LUMI92U library: RUNS19, LUMI19, KEEP19, RAWD19, CURR19, TRIG19 - data sets. Examples of JOBs for the second step (for so called 19th collisions) are kept at library H1KFOM.LUMI92U with name #Z0907S1-#Z0907S5, #Y0907S1 and #X0907S1. Example of JOB for the third step is kept at the same library with name #C090792. The next pictures are produced with this type of Job (x-axis always time at minutes from StartOfFirstRun at ep-collision period): 300 - Total rate of ET&PD-events (at 0.1Hz) 2000 - 2009 2019 - ordinary set of ET&PD bunch rates(at 0.1Hzunits) (in principle there are all 2000-2219 vectors) 903 - CurrentValue of Luminosity (at 10**25 cm-2s-1 units) 904 - Total Integrated Lumi values per H1Runs (at 10**25 cm-2 units) 905 - Effectiv Integrated Lumi values per H1Runs (at 10**25 cm-2 units) 1000 - 1009 1019 - ordinary set of e-bunch currents (at 1mkA units) (in principle there are all 1000-1219 vectors) 4000 - 4009 - ordinary set of p-bunch currents (at 1mkA units) (in principle there are all 4000-4219 vectors) 1500,1501 - Total e-beam current (at 1 mkA units) 4501,4502 - Total p-beam current (at 1 mkA units) 800,801 - Lumi-event trigger efficiency koefficient (rough and pure) 802-805 - Xpd,Ypd(rough,pure) 806 - Acceptance Correction Coefficient. 993 - Coefficient at Wiik`s formula (0.6-2.0) - see message about Newton`s information 06.07.92 message at LLO). 5001-5049 - CCs for ET 6001-6026 - CCs for PD and WaterCounter. Now there are existed the next cartridges with collection of LRTL-, TCUR-,LREC-,LRPC- and HEAD banks for some ep-collisions: H1KFOM.EP290692.A12 1st and 2nd ep-collisions from 29.06.1992 H1KFOM.EP290692.A3 3rd H1KMAL.EP060792.A15 15th H1KMAL.EP060792.A16 16th H1KMAL.EP060792.A17 17th H1KMAL.EP080792.A18 18th H1KFOM.EP090792.A19 19th H1KMAL.EP100792.A20 20th The full list of all ep-collisions from 29 June 1992 is the next: 1. 29.06.1992 01:46 - 02:15 2. 29.06.1992 10:43 - 15:08 3. 29.06.1992 16:35 - 19:39 4. 30.06.1992 11:06 - 15:19 5. 30.06.1992 17:28 - 20:22 6. 01.07.1992 00:30 - 03:48 7. 01.07.1992 09:18 - 10:25 8. 01.07.1992 12:17 - 13:21 9. 01.07.1992 15:27 - 18:41 10. 01.07.1992 20:23 - 00:37 11. 02.07.1992 04:00 - 06:40 12. 03.07.1992 17:57 - 22:00 13. 04.07.1992 01:35 - 07:00 14. 06.07.1992 00:52 - 05:28 15. 06.07.1992 06:36 - 11:20 16. 06.07.1992 20:57 - 00:23 17. 07.07.1992 01:40 - 07:26 18. 08.07.1992 20:37 - 03:59 19. 09.07.1992 11:17 - 17:03 20. 10.07.1992 04:40 - 07:40 10.07.1992 ===================== F11LEV === Archive of ep-collisions 1) Before you start to produce hundreds of cartrages, consult with Jan Olsson. We discussed two weeks ago with him an automatic proce- dure selecting all KEEP stuff plus RunStart/RunEnd records on the separate cartrages. It has no sence to duplicate information. Note, that finally it will be a huge amount of tapes with this kind of information. 2) It is very good that at least Fomenko started to look into our data relatively seriously and regularly. But I have one small comment concerning already created LOOK files: why do you choose so crasy units: 0.1Hz and 10**25cm-2s-1 ? It is good for the bank content for the reason of accuracy, but not for the data presentation. Therefore, I would like to ask you to change these units in a job creating LOOK output files as soon as possible (since this is trivial): 0.1 Hz --> Hz, 10**25cm-2s-1 --> 10**27cm-2s-1 = 1/mb sec and for integrated luminosity use units of mkb-1 (until we will get much higher luminosity, say 10**29-10**30, then nb-1 would be more suitable). 10.07.1992 ===================== H1KFOM === Archive of ep-collisions As me seems (from simple estimations) the number of archive cartridges with only LRTL-,TCUR-,LREC-,LRPC- and HEAD-banks must be not more then 1-2 (non hundred as Levonian predicted). Another inconvinience if we will not do own cartridges - large quantity of F11JOL.H01.TESTCAL...- cartridges per each ep-collisions (10-30).Another subdetectors put into EndRunRecord and RunStartRecord and (may be KEEP) much more info- rmation then H1Lumi. It is possible to combine all high mentioned cartridges on single (only with keeping of time flow - 14 ep-coll. must be before 15, 15th before 16th etc.). Another problem:I could not find F11JOL.H01.TESTCAL-cartridges with number which differs more then on 100 from last number. May be this cartridges are renamed or may be they are scratching with new information (100 cartridges at loop?). Really no problem with the second remark of Levonian. New release with this little update now exists at the same library with the same name. 11.07.1992 ===================== H01USA === About specific lumi ....... There is only one precise formula (definition) for calculation of present measured spesific luminosity: Lsp = L/( Sum(Ie_i*Ip_i) ), (1) i where L - measured lumi, Ie_i - electron current in i-bunch, Ip_i - proton current in i-bunch. The idea of specific lumi is very simple - it is really specific i.e. it is normalised on currents and reflects the quallity of collision. This value is provided for HERA people (and available in H1 CR also ) and is used for understanding - is the collision optimal or it is necessary to continue the tunning. Theoreticaly specific lumi depends on parametrs of present beams ( bunch size f.ex.) and must be (theoretically) constant during one running. From 3.07. Lsp is recorded in H1 HERA logbook. It is interesting also provide specificlumi for every bunch: Lsp_i = Li/( Ie_i*Ip_i ), (2) Theoretically it must be equal for all bunches. If it is not so, then may be something happens with beam's bunches (idea of Malinovskogo) or there is some unperfect of HW (as Egor said). Separation of this effects - another question. NB. Note for obosnovanija (1) that in the case of optimal collision L ~= Sum (Ie_i*Ip_i *cross-section) 11.07.1992 ===================== H1KFOM === TESTCAL is temporary set It`s really so that only last 100 dataset with RunStart/KEEP/RunEnd records are kept with F11JOL.H01.TESTCAL.GXXXXV000 names on disk (!) (not cartridges as I wrote earlier). One day later this information it is possible get only from H1RAWD- cartridges (this procedure naturally more long that from disk). Today I tryed to repeat the procedure for selection of our H1Lumi- banks from #20-ep collisions (10.07.1992 morning) - it is impossible - data sets F11JOL.H01.TESTCAL.G8140 -...G8147 are not in BB catalog. Be carefull - try to use fast data set during one day after ep-colli- sions. 12.07.1992 ===================== H1KFOM === 24% CC changing at LumiRun At last ep-collisions (#20 at our local counting - 10.07.92 from 04:39 up to 7:40 - near 3 hours) it was fixed maximum current lumi- nosity value for all time of HERA-comissioning - near 7.0*10**28 cm-2s-1 at the start of ep-collisions. It was happened due to large values of p-beam current (1250 mkA) and e-beam current (2500mkA) at the start time of ep-collisions. This ep-collisions were the best test for today for investigations of the behaivour of calibration coefficients with time (due to highest rate at our detectors for all time of HERA-comissioning at 92) As was tested by A.S.Belousov and P.Smirnov under high rate (near 400 kHz) the amplitude on photomultiplier output became more then before this frequency threshold under some fixed HV. With less HV this "frequency threshold" becomes more (up to 1MHz). As seems effect of this type behaivour it was looked at last ep- collisions. As You know - we have at #FIC2-bord the permanent calibra- tion procedure which naturally for current situation defines the more or less optimal values of calibration coefficients set. Before ep-collisions at #FIC2 it were remembered the last values of calibration coefficients which were optimal for rates which existed at the end of #19th ep-collisions (naturally less rates then at the start of #20th collisions). Naturally the behaivour of all calibration coefficients for most hitted channel was the same - all CC jumped to low value (for compensation of effect which was looked A.S.Belousov and P.Smirnov). __________________________________________________ | | | | | | | | e-beam __________________________________________________ X | 24.0%| 8.0%| 8.0%| 8.0%| 6.0%| 12.0%| 3.0%| __________________________________________________ | | | | | | | | __________________________________________________ The most "jumped" CC at PD were p16 (24%), p17 (9%), p18 (12.5%). All this "jumped" CC were incremented with time and after 180 min. became closly to start values (but due to relatively high rates at the finish of #20th ep-collisions they stayed less then start values e21(-13%), e22(-1.5%), e23(-6%), e24(return to start value), e25(-1.5%) e26(-5.5%),e27(return to start value), p16 (-10%), p17(return to start value), p18(-11%-without return direction). I want to note that this type of changing exists "inside" 10-bunches mode of HERA-working - so it is impossible to find single HV-set for 10 bunches mode (or 60 bunches mode etc.) and to hope that all will be OK with analog trigger sums and with calibration coefficient set. It is needed additional actions for adequate getting of ET- and PD- response for analize of energy spectra at Photoproduction Branch. 12.07.1992 ===================== H1KMAL === Run-archive 06.07 - 10.07 Information from Start/Run/KEEP/EndRun for ep-collisions during period: 06.07.02 - 10.06.92 ( LUMI Runs 15 - 20) is collected on Cartridge H1KMAL.EPJUL92.A1520. There is the LOOK File for this data ( Runs 25250 - 25588) - H1KMAL.ALOOK.R25250, made with the help of "ARCHIVE"- programme (Fomenko"s name #C090792). 12.07.1992 ===================== H1KSOL === Proposal for ep-arhive .... I propose the following points for Lumi arhive: 1.Dont divide the Lumi Summaries into seferal files but make a complete one for definite date.Let us do agreement about name of this file,for example,LS920710 means that in this file all summaries from RunStartRunEnd Record related to Lumi at date 10.07.92 is collected.It seems to be much convieniently to look for needed information.Furthemore,everybody who wants to have information concerned to definite item can make it easily from this file.It will be usefull too to add to this file information about data set on cartridge which keeps Lumi data (so called second step in Fomenko's message). Here below is an example of an entry in such file: >>> Start RUN Summary --------------------- <<<<< NRUN NrofEvts Ev.Fst Ev.Lst DATE TIME <---> DATE TIME 25576 1939 0 1953 920710 43953 920710 45217 SYSMOD DAQMDE XI FEB CTLVRS DETSTA I.LUMI 00005081 00000004 0BFE 003F 00000000 00000000 24969 CTCNF1 CTCNF2 TRIG1 TRIG2 NMASKST0 NMASKST1 NMASKST2 NMASKST3 FDD80BF8 03A00000 00140160 1418FC7F 1418FC7F 1F0FBFA3 00000100 00000000 Eelec Eprot Polari Ecurr Pcurr Bfield Bcurr Patmo 22100 819901 0 26 12 11371 181 1005 RunStart/KEEP/RunEnd records written on F11JOL.H01.TESTCAL.G8141V00 Output Data Set Name HERA04.H1RAWD.C9201232 Permanent Lumi Output Data Set Name H1KMAL.EPJUL92.A1520 Permanent >>> End RUN Summary -------------------- <<<<< 2.To get a common userid on IBM for H1 LUMI (f.e.H01LUM),under that we can collect all Lumi summaries,cartridges and may be something else.In this case one have no need to know under which userid Lumi summaries or cartridges exist. 11.07.1992 ===================== F11LEV === Archive of ep-collisions I must say, that I don't like this non-professional stuff. All kind of information (exept full content of LRTL banks within Runs) already now is possible to get using very poweful DB2 queries (see messages of J.Strahota). All J.Olsson's Run Summaries go automatically to the IBM data base, and then can be inspected by everybody with a professional QMF tool. "Zachem opjat lepit ubljudka ?" Moreover, in future it is foreseen to keep all useful lumi information also in the H1 database. The only useful thing for the time being is to collect LRTL banks in a separate cartridge, and since Fomenko estimated space needed for that of the order of 1-2 tapes, there is no need to create special catalog for them. Of course, person who takes care about selecting LRTL etc. banks, should append new information to the same cartridge rather then create 100 small files which again will be scattered over many different cartridges... 13.07.1992 ===================== H1KSHE === Luminosity Run 21.......... Date: 13/7/92 Collision time: 00:00 - 03:54 ! Start and end collision times Currents (mkA): Ie= 1890 Ip=1050 ! beam currents at start time Peak luminosity: 2.8*10**28 ! Max lumi, usually at start time ! Total lumi: 9.80*10**31 ! Integrated lumi H1 gated lumi: 8.24*10**31 ! So called "effective" lumi H1 runs: 25884-25893 ! Which runs were recorded Additional comments: 9 +1 - e.filled bunches, 10 - p.filled bunches i.e. it was additional proton pilot bunch. From 00:08 to 00:30 it was beam separation, so quality of zero for lumi measurements can be estimated. 13.07.1992 ===================== H1KSHE === Luminosity Run 22.......... Date: 13/7/92 Collision time: 07:52 - 08:50 ! Start and end collision times Currents (mkA): Ie= 1600 Ip=1500 ! beam currents at start time Peak luminosity: 4.8*10**28 ! Max lumi, usually at start time ! Total lumi: 7.45*10**31 ! Integrated lumi H1 gated lumi: 7.17*10**31 ! So called "effective" lumi H1 runs: 25898-25900 ! Which runs were recorded Additional comments: 9 +1 - e.filled bunches, 10 - p.filled bunches i.e. it was additional proton pilot bunch. At 08:20 80% of p-beam current was losted. 13.07.1992 ===================== F11LEV === LUMI KEEP data ............ There is a problem with our KEEP data. In spite of removing LRTS bank, it is still too much for the present scheme (LRTL is approx. 1.2 kb per 10 sec). This prevents other subsystems keep their similar data: after 10 min corresponding file is full and does not accept further data till the end of the run. After preliminary discussion with J.Olsson and J.Strachota two solutions were proposed: 1) For the time being remove LRTL bank at all (don't store it) and after getting more disk space for the online logging job switch on LRTL again. (J.Olsson). Then for this period LRTL will be available only in the RAW data tapes. 2) Try to use standard H1 slow control approach: keep only significant changes w.r.t. already stored information (J.Strachota). This by the way should allow always store also LRTS information but in very compressed form. I personally prefer second solution as more general and conveniet. It also delivers the possibility to use all powerful tools of H1SC system By the way, why Usik stopped to join SC group? I though it was decided that he will be responsible for the SC of LUMI. Second solution assume some additional thinking from our side, but Jiri is eager to help us. I also attach last mail from him. Dear Sergei, thank you very much for the information. I propose the following definitions of Luminosity Slow Channels based on what I see in your bank LRTL (of course they may be some good SC's outside LRTL): LDR0 0 1 RATE1/RTLUMI ... LDR0 0 220 RATE220/RTLUMI LDR0 0 221 RTLUMI LDR0 0 222 PLTEFF LDR0 0 223 RLTEFF LDG0 0 224 XPROF0 LDG0 0 225 XPROF1 LDG0 0 226 YPROF0 LDG0 0 227 YPROF1 LDG0 0 228 ACCC LDO0 0 229 FADCEFF LDO0 0 235 RH1LUMI/RUNLUMI LDO0 0 236 RC/LLT LDN0 0 230 RC LDN0 0 231 LLT LDN0 0 232 CTLV LDN0 0 233 RUNLUMI LDN0 0 234 RH1LUMI To my understanding, warnings should be set on too weak bunches which are supposed to be filled. Warnings AND alarms should be defined on all the other differential quantities. Finally, the integrated quantities (accumulators) should have neither warning nor alarm but should be pre- sent in each Slow Event generated. I don't need to remind you that the SE's are triggered either by a TRANSition (change of state between Normal/Warning/Alarm/Lock) or TIME or SIZE or ComMaND (or CONTinuation). You also know that all slow channels will be presented by the standard way in Argus, on terminal/Mac_DA monitoring, logged together with the data and on the SEAF (slow event archive file) from which we can see all the plots I have shown you. I propose, that your famous group helps ours to come to some deserved prominence by adding this way of monitoring to your well esta- blished (but not so reasonable) current method. I am sure we can work together well and I have a hope that it could be a success. Privet! Jiri 13.07.1992 ===================== H1KFOM === Else one about TESTCAL.... This is the piece of message from Jan Olsson which (I hope) will be useful for us: "............. One more information concerning TESTCAL files. You can find a copy of all TESTCAL files for permanent data on summary files; F11JOL.H01.SUMTCL F11JOL.H01.BCKUPTCL.R24272.R25899 The backup cartridges are made as soon as 240 MB of TESTCAL data have been collected on SUMTCL disk file. Cheers, Jan O. ................." 13.07.1992 ===================== H1KFOM === LRTL-bank MUST be at H1CDAQ I had a little discussion with Jan Olsson about our LRTL-bank status. As me seems it is possible to propose the 3rd solution of mentioned at today S.Levonian`s message problems: We can switch on this bank into the H1DataFlow only when ep-collisions exist. It would be good if this procedure would make automatically. At future Jan Ollson promised to select H1Lumi-KEEP-banks on special data set (specilal cartridges) together with TCUR. I think that contents of LRTL-bank is useful for not only H1Lumi-peo- ple and any attempt to switch off this bank during ep-collisions is very bad solution. Using of Slow Control tools really very useful and must be realized as soon as possible but (to Jan and to Jiri opinions) this tools cannot keep so much information as it is possible to do it with H1CDAQ-information. SC-events will be very rare (I hope) but for keeping of real history of each ep-collision this information will be not enough (especially now when finding of different correlation at different measured values is very important task). I think that we MUST use the H1CDAQ-data flow for keeping of this information. In principle it is possible to discuss any changing of current format of LRTL-bank (for example to realize zero-suppression). In principle it is possible to transfer not each LRTL (it is not very good solution - we will loose the part of history - but temporary it is possible). We can change DT1 (from 10 sec to 30 sec. for example) due to recei- ving of new values of bunch currents onle once per 30 sec. It is logically - and we really will decrement the statistical error of our measurements. Why we decided to make measurements once per 10 sec.? DT1 is option and it is possible to change it. But main - we never must change H1DataFlow for this type of informa- tion. It would be our large mistake. 13.07.1992 ===================== H1KFOM === Else Info from Jan Olsson.. This is the last message from J.O. with attempt to understanding - why sometimes we could not read his TESTCAL-data sets: "............ Hallo again! I looked closer on your job which you sent to me. I see that you use RSELECT features. Then it is important to know that on the TESTCAL files there is a mixture, namely RUNDATA records for Run End and Run Start "events" and also for FARM events (which are added Non Event Data records), while all other KEEP records are labelled RunEvent But on the file F11JOL.H01.SUMTCL and on the bckup cartridges, all records, including the KEEP ones, are labelled RUNDATA !! This is the correct labelling, since it is really nonevent data only. I dont understand the following JCL part: //* Reading from a several cartridges: //G.FT01F001 DD DSN=F11JOL.H01.TESTCAL.G8339V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8340V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8341V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8342V00,DISP=SHR,LABEL=(,,,IN), // UNIT=AFF=FT01F001 The last part, UNIT=AFF should only be for cartridges. For diskfiles, it is enough to have it like //G.FT01F001 DD DSN=F11JOL.H01.TESTCAL.G8339V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8340V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8341V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8342V00,DISP=SHR,LABEL=(,,,IN) and then you can add also a much larger number of files. I dont know what happens and if this makes a difference. I suggest to ask a FPACK expert otherwise, maybe Sergey Levonian? ......." 13.07.1992 ===================== F11LEV === LRTL-banks ................ I do not understand why Fomenko got so exited: nobody wants to suppres LRTL info completely, but it must be realized, that present situation cannot last forever: already now we are really loosing LRTL banks from KEEP files, they only are present in the raw data tapes (see again my previous message). J.Strachota's solution will keep really useful info only, not everything. E.g. zero suppresion will be done automatically, etc. Concerning J.Olsson remark. Correct JCL are the following: //* Reading from a several cartridges: //G.FT01F001 DD DSN=F11JOL.H01.TESTCAL.G8339V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8340V00,DISP=SHR,LABEL=(,,,IN), // UNIT=AFF=FT01F001 // DD DSN=F11JOL.H01.TESTCAL.G8341V00,DISP=SHR,LABEL=(,,,IN), // UNIT=AFF=FT01F001 // DD DSN=F11JOL.H01.TESTCAL.G8342V00,DISP=SHR,LABEL=(,,,IN), // UNIT=AFF=FT01F001 //* Reading from a several disk files: //G.FT01F001 DD DSN=F11JOL.H01.TESTCAL.G8339V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8340V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8341V00,DISP=SHR,LABEL=(,,,IN) // DD DSN=F11JOL.H01.TESTCAL.G8342V00,DISP=SHR,LABEL=(,,,IN) Note, that "AFF" card must be present after EACH new file exept very first one! It means that all cartridges will be read from the same device, thus only one unit needs to be allocated to the job by the system. For the disk files it is not necessary at all, J.Olsson is right. I do not beleive, that "AFF" card may affect reading of a disk files in such a way to provoke I/O errors. However, I never saw your proble- matic outputs, therefore I cannot blindly say what could be a reason for this error. 14.07.1992 ===================== H1KSOL === Luminosity Run ............ Date: 14/7/92 Collision time: 02.10 - 02:23 ! Start and end collision times Currents (mkA): Ie= 1260 Ip=1180 ! beam currents at start time Peak luminosity: 3.0*10**28 ! Max lumi, usually at start time ! Total lumi: 1.42*10**31 ! Integrated lumi H1 gated lumi: 1.40*10**31 ! So called "effective" lumi H1 runs: 25971 ! Which runs were recorded Additional comments: 9 +1 - e.filled bunches, 10 - p.filled bunches i.e. it was additional proton pilot bunch. e-pilot bunch #10 P beam got lost during tuning for Lumi,so only Lumi data are usefull. Init of calibration was done after end of e ramp After p beam lost e beam existed about 1 hour and Run #25972 was recorded with only e beam. It is interesting to check the CC behavior during these two Runs because: 1.First 5 minutes collimators were out and then were moved in (rates were changed) 2.Then p beam get lost and we had only e beam. (One more change in rates) 14.07.1992 ===================== H1KFOM === Archive of ep-collisions As seems we must change our ideology of ep-collisions archive making. Due to last contacts and information from J.Olsson it is possible to use cartridge with RunStartRecord/KEEP/EndRunRecord-information. For today it is only one cartridge for very long period. Its name is: F11JOL.H01.BCKUPTCL.R24272.R25899 I tested the posibility to select LRTL-,TCUR-,LREC- and LRPC-bank from this cartridge to any (temporary) own cartridge from different Run ranges. The procedure of making special data set with information from needed ep-collision now is very simple. You must know First Run Number and Last Run Number at needed ep-collisions and after this with changing of option at RSELECT You can create temporary data set on car- tridge. And after this You can use this temporary data set as source for the third step of archive making.The examples of JOBs for selection data for needed ep-collisions are kept at library H1KFOM.LUMI92V as members: ##A13707 - for selection data for #07 collisions (01.07.92 09:18-10:25), ##A13708 - for #08 collisions (01.07.1992 12:17-13:21) ##A13709 - for #09 collisions (01.07.1992 15:27-18:41) etc. After this step it is possible to do submit JOB for pictures making (example at H1KFOM.LUMI92V-library with names #C140792,#D140792,#E1407- 92 etc. Main - we never will be create the own archive cartridge - only using of H1CDAQ-created (Olsson's created). All created own cartridges it is possible to remove now. Last problem which is not resolved - sometimes our LRTL-banks are disappeared from this data set (TESTCAL and later H01.BCKUPTCL..). As seems this problem must be resolved at future. In principle for this case we ever can use the selection of LRTL-banks from H1RAWD-cartridges (it will be get at 100 times CPU-time more then this type procedure) - but (it is good) this cases not very often. 14.07.1992 ===================== F11LEV === H1 trigger meeting news.... There were several important news presented at the last H1 trigger me- eting which could be of general interest within H1 LUMI group. 1) New CTL cards are installed. Now 128 input trigger elements grouped in 8 (16*8) can be supported, and also 128 trigger bits at the CTL output are available. For all of them +- 16 bunch crossings history can be kept. New CTL is more flexible and not so restrictive as before. For example, an overall time adjustment is no longer neces- sary (i.e. the requirement that all trigger elements from all sub- detectors must arrive at the same time). The only time constraint which is still needed: all trigger elements within the same group of 8 elements must be adjusted). Our LUMI/eTAG group is number 14 and we now have also 8 trigger elements instead of 1 as sofar. IMPORTANT: eTAG must still be at position 6 at this group. Others are free for the Igor. (E.Elsen) 2) The reason for the high rates of eTAG * "H1" triggers seems to be understood. In addition to the random coincidences between e- in ET and p-gas in H1 there is another source of non-random background from e-wall scattering. This means, that part of the e-beam got scattered on the collimator(s) (sinchrotron masks) and the leading e- from the shower can be accepted by ET (if scattered angle < 5mr) while the rest of the shower causes different H1 triggers, especi- ally BPC. This never has been simulated (very difficult, almost im- possible). Finally this must be suppressed by DC r-phi trigger which unfortunately is not yet available. Instead, corresponding selections must be done offline. The most clean (and perhaps the only possible) trigger for the sigma-tot estimate is PRESENTLY zvx * eTAG. With the higher luminosity old BPC*eTAG trigger might work as well. Before Dallas I will concentrate on the sigma-tot estimate. At some moment ET-calibration will be essential (at least within 10% level). (S.Levonian) 3) What could help against e-wall (future): - adjustment of the collimators - DC trigger at L1 (expected in September) - additional energy cut for the ETAG: 4 < E(ET) < 19 GeV Last possibility requires rather precise trigger calibration. (S.Levonian) 4) Shut down for the summer break: August 3. Restart of lumi runs: August 31 ! Shifts and responsibles must be available. Trigger upgrade meeting: September 15 (U.Goerlach) 14.07.1992 ===================== H1KFOM === H1LumiOnLine SW decription At Day Of Bastilia Falling: There are the next parts of H1LumiOnline software: 1) H1LumiOnLineFIFO-family of programs for running at FIC#1 (photopro- duction branch) board; 2) H1LumiOnLineRecNew19 - program for running at FIC#2 board (luminosi- ty branch); 3) NewFastLumiMonitor - SuperCard-project which can work at both H1Lumi and H1Lumi2 MacIIs; 4) FullLumiMonitor - SuperCard-project which can work at H1Lumi2 MacII; 5) HVLeCroyControl.07.01.92 - SuperCard-project which can work at H1Lumi2 MacII; 6) TrFile2 - SuperCard-project which ordinary works at H1Lumi2; 7) T_Monitor-application which ordinary operates on H1Lumi2 MacII; 8) Scalers-application which ordinary operates on H1Lumi2 MacII; 9) The family of different desk accessories which can work on both MacIIs and on the HERA Control Room`s MacII; 10)The family of different applications which can operate at both MacII (BeamProfile, VideoMonitor2.6rn, H1RatesMonitor) (1),(2),(5) - were made by A.Fomenko with insertions from I.Sheviakov; (6),(7),(8) - were made by I.Sheviakov; (9),(10) - were made by A.Usik; (3),(4) - was combined from existed earlier different SuperCard projects (H1LumiOnlineMonitor,TriggerMonitor and SlowControl Monitor) with common work of above mentioned people - supported at last time by A.Fomenko; For creating of(1) and (2) it was used so-called RTF-technology. For creating of(3),(4),(5),(6),(7),(8)it was used SuperCard-tecnology. For creating of(9) it was used ThinkC-technology; For creating of(10) it was used MacApp-environment. (1) - H1LumiOnLineFIFO-family of program for FIC#1. -------------------------------------------------- There are three program at this family: H1LumiOnLineFIFOA - for local working (at TriggerMode 3); H1LumiOnLineFIFOB - for working with H1CDAQ and without H1CTRIG and another branches of H1 DAQ (at TriggerMode 0); H1LumiOnLineFIFOC - for working with H1CDAQ, H1CTRIG and another branches of H1 DAQ (at TriggerMode 0). This programs are operated at FIC#1-board and can make the next: - readout of photoproduction branch which is finished with creation of different H1Lumi BOS-banks: LREE,LREF,LRPE,LRPF,LRTE,TSTC, LREC,LRPC,LRTF,LRTS,LRTN and LRTL (some from this banks only retranslated from FIC#2-environment and are put into so-called KEEP-environment of H1CDAQ data flow - LREC,LRPC,LRTL,LRTS); - interrupt handling - this program has the next interrupt handling routines - L2KeepSub, L3KeepSub, L3RejectSub, StopRunSub, AbortRun- Sub and IlevelA(FIFO-ideology) -routines (interface with H1CTRIG); - supporting of VMEtaxi-protocol (interface to H1CDAQ); - creating of StartRunRecord and EndRunRecord; - processing of events at BackGround-area for different aims: a) reconstruction of coordinates and energy at ET and PD; b) calibration of this branch with Bremstrahlung Event trigger; c) histogramming of different values with HHPACK-Manhatten-envi- ronment; d) supporting of different memory regions, counters and addresses for family of Desk Accessories (bunch statistics, energy distribution, different monitoring values etc.) e) providing of needed interface to NewFastLumiMonitor - different memory regions, values for monitoring; f) providing of needed interface with FIC#2 program. (2) - H1LumiOnLineNewRec19 - program for FIC#2. ----------------------------------------------- This program is operated at FIC#2-board and looked for as forever loop. Differents subroutines and packages of subroutines are switched on at this loop on differenr reasons. When no any actions are made at each loop circulation the rate of this loop is near 2.9-3.0Khz. This program can make the next: - readout of luminosity branch which is finished with creation of internally used BOS-banks: LREE,LREF,LRPE,LRPF. - reconstruction of coordinates and energy at ET and PD - main user of CPU at FIC#2 (rate of loop during operation of this procedure is near 9 Hz); - calibration of this branch with Bremstrahlung Event trigger (there are two calibration alghorithms - Usik`s and Soloviev's - which are involved into this procedure - Usik`s alghorithm is operated permanently, Soloviev`s - optionally); - histogramming of different values with HHPACK-Manhatten-envi- ronment (last time - very rare using); - supporting of different memory regions, counters and addresses for family of Desk Accessories (bunch statistics, energy distribution, different monitoring values etc.) - providing of needed interface to NewFastLumiMonitor - different memory regions, values for monitoring; - providing of needed interface with FIC#1 program; - supporting of Luminosity Measurement philosophy - updating of all values which are connected to LumiMeasurement philosophy; - creation of different BOS-bank for KEEP-environment of H1CDAQ and its retranslation into FIC#1-environment (LRTL,LREC,LRPC,LRTS); - supporting of single mechanism of getting information from 32x220 bunch-trigger combination scalers; - supporting of memory regions for drawing of BeamProfile, Energy Correlation Plot, LumiTriggerEfficiency behaivour with time; - supporting of bunch rate monitoring for Lumi-trigger; - providing of power interface for different H1Lumi-trigger facility (interface to TrFile2); - and many other useful work. (3) - NewFastLumiMonitor - SuperCard Project -------------------------------------------- This is the main monitoring tool for H1Lumi-sytem. It can operate on both MacII (with old release of SuperCard - less then 5.1). This project has the set of different windows. Each window has the set of cards. If You want to enter into environment of needed window or card from this project - You can use the selection of different Menu-items at SuperCard-environment. Common quantity of all card at this project is large and in principle it is not needed to know all details of each card (most from this card only for experts). At future it is possible to create ShortLumi Monitor with more often used cards. For today - most often used Card are: 1) LuminosityMeasurement - at this card it is possible to look for all updated values from last luminosity measurement, the values of bunch currents and total current of HERA-beams, the values of different integral luminosity, the value of H1 LiveTimeCoefficient, the value of bunch luminosities (current and integral). It is pos- sible to see the default values of all main constants for lumino- sity measurement and to change its (if it is needed); 2) TriggerSelection - at this card You can test the current trigger setting for both brunches and in principle to change the setting of ETAG-trigger bit (which is now installed as ET&no(PD)&no(WCnt) and trigger for luminosity branch (which is ordinary installed on pure luminosity trigger - ET&PD&no(Wcnt); 3) TriggerThresholds - at this card You can test the default values of thresholds on each trigger element (which are now 20 for ET and PD and 8 for WCnt) and in principle You can change this thresholds (if it is needed); 4) BanksSet - at this card You can see the default set of BOS-banks which are produced with H1Lumi for writting into H1DataFlow. In principle it is possible to change this default set of H1Lumi banks with swithing on or off any bank from used; 5) EnergyPlot - at this card it is possible to look for the Epd-Eet energy plot at any time when e-beam existed at HERA and there are any Lumi-trigger rate at H1lumi-system. It is shown the last 1000 events energy values. 6) CoordinatePlot - at this card it is possible to look for two dimensional distributions of hits on the faces of both ET and PD; It is shown the last 1000 events coordinate values. 7) ShowLumiEvent - at this card it is possible to see the "photo- graphy" of raw event at Luminosity branch. 8) Calibration&Weights - this card is the window into Usik`s calibra- tion algorithm. At any time it is possible to look for the abso- lute values of calibration coefficients for all channels of ET,PD and WCnt and the values of weights for each CC which are connected with frequency of hitting of this channel (cell). 9) In principle there are the set of another windows and cards which are used not so often and mainly by experts - don`t worry. (4) - FullLumiMonitor - SuperCard Project ----------------------------------------- This SuperCard-project are kept only due to "MovingPlattform"-facility which is installed only at this project (historically). This project has another SlowControl Facilities which are not used now (may be at nearest future its will be alive). (5) HVLeCroyControl.07.01.92 - SuperCard Project ------------------------------------------------ This project almost equal the previos release of HVLeCroyControl -project which was outlined at H1-LPI-InternalReport-05-91. Only cosmetics was made (Menu and its items were added). This project can operate only on H1Lumi2 MacII inside old SuperCard environment. This project permanently used at all cases of calibration and recalib- ration at this 1992 year without any problems. Different HV-sets are kept on disc-files. (7)-(10) SW-products will be described by authors - I.P.Sheviakov and A.P.Usik. 14.07.1992 ===================== H1KSHE === Luminosity Run 24.......... Date: 14/7/92 Collision time: 11:44 - 11:50 ! Start and end collision times Currents (mkA): Ie= 970 Ip=980 ! beam currents at start time Ie=1250 Ip=980 - off-line analysis (A.F.) Iepilot= 180 mkA Peak luminosity: 4.4*10**28 ! Max lumi, usually at start time ! Total lumi: 1.35*10**31 ! Integrated lumi H1 gated lumi: 1.16*10**31 ! So called "effective" lumi H1 runs: 25978-25979 ! Which runs were recorded Additional comments: 9 +1 - e.filled bunches, 10 - p.filled bunches i.e. it was additional proton pilot bunch. 14.07.1992 ===================== H1KSHE === Luminosity Run 25.......... Date: 14/7/92 Collision time: 12:53 - 17:45 ! Start and end collision times Currents (mkA): Ie= 1200 Ip=970 ! beam currents at start time Peak luminosity: 3.5*10**28 ! Max lumi, usually at start time ! Total lumi: 1.43*10**32 ! Integrated lumi H1 gated lumi: 1.25*10**32 ! So called "effective" lumi H1 runs: 25981-26019 ! Which runs were recorded Additional comments: 9 +1 - e.filled bunches, 10 - p.filled bunches i.e. it was additional proton pilot bunch. 15.07.1992 ============== H1KSHE,H1KFOM === Luminosity Run 26.......... Date: 14/7/92 - 15/07/92 Collision time: 18:49 - 00:07 ! Start and end collision times Currents (mkA): Ie= 1070 Ip=807 ! beam currents at start time Peak luminosity: 1.9*10**28cm-2s-1 ! Max lumi, usually at start time ! Total lumi: 8.9*10**31cm-2 ! Integrated lumi H1 gated lumi: 6.7*10**31cm-2 ! So called "effective" lumi H1 runs: 26028-26047 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 2 non-collided e-bunches (#19 and #22) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) 23:15 - Ip=570 mkA Ie=430 mkA Lumi = 2.7*10**27 cm-2s-1 HV on H1 trackers was off (preparing to EndOfep-collisions Run) 00:07 -e-beam was killed during Run 26047 Ie = 240 mkA 00:18 -p-beam was killed during Run 26047 Ip = 400 mkA 15.07.1992 ===================== F11LEV === Addentum to mail-discussion Sorry, I forgot to mention one important thing, to which Igor Sheviakov pointed by telephone. This concerns so called low energy peak (or tail from the noise/bgr events). Igor is absolutely right: for all recent ep-data (say, during July at least) there are NO SUCH EVENTS AT ALL. Thus there is no (or very small, <1%) trigger inefficiency of that type I tested this again just 10 min ago. But one has to remember, that ET energy spectrum should be analysed for the subset of H1 events, trigge- red by eTAG trigger. Of course, if you fill your histograms just for all events, there will be many of them containing only noise in ET, but then they should not contain eTAG trigger bit and indeed, they do not! This is evident, but people often forget to make a proper event selection for the particular study. This low-energy inefficiency had appeared before from time to time, but always there were clear resons for that: either this was test data where eTAG threshold adjustment was made, or something was wrong with timing/sinchronization. But for the July data, at least with that respect our eTAG trigger is very stable and reliable. Sorry for the misleading. Presently the only source for the events triggered by eTAG trigger and having E_rec in ET < 3 GeV (in fact exactly zero E_rec) is these bloody overflows... One further recommendation for the data analysers: use only those runs labelled by (*G) in H1EP, which means, that these data are relatively good. You can forget about all data, where in the comment field you will find remarks about some problems with the trigger timing, they are absolutely useless for the physics study... 15.07.1992 ===================== H1KFOM === ep-collisions #27 ......... In principle this case of ep-collisions it would be possible do not labeled with this nice name "ep-collisions" and may be due to this or another reasons my colegues - Youri Soloviev and Sasha Usik deci- ded did not write anything into LLO (or LLC with new mode name) but for collection of different cases it would be useful to underline today attempt to make ep-collisions: Date: 15/07/92 Collision time: 15:04 - 15:20 ! Start and end collision times Currents (mkA): Ie=1200, Ip=1380 ! beam currents at start time Iepilot = 140 mkA Peak luminosity: 3.0*10**27cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 0.2*10**31cm-2 ! Integrated lumi H1 gated lumi: 0.2*10**31cm-2 ! So called "effective" lumi H1 runs: 26069-26070 ! Which runs were recorded Remarks: 14:38 - end of e-ramping (Ie=1900mkA,Ip=1380mkA) 14:38-14:42 - fast decrementing of e-beam current (600 mkA for 4 min.) 14:45 - some manipulation with e-beam (as the result total rate was incremented on 300Hz (from 900 up to 1200 Hz) - as off line pictures show - it was the changing of beam position (before this Xpd=-0.1cm Ypd=3.2cm after - Xpd=-1.5cm Ypd=0.0cm) 15:04 - collimators were moved (as the result - total rate was decremented from 950 Hz to 600 Hz) 15:04 - collimators were moved and ep-collisions with very low luminosity were fixed (but with very large statistical error - near 1.5-2.0*10**27cm-2s-1) 15:20 - p-beam was lost Sasha Usik said that F.Willeke find something that explained possible reason of absence "good"-collisions - something he looked for some screen. 16.07.1992 ============== H1KSHE/H1KFOM === ep-collisions #28 ......... Date: 16/07/92 Collision time: 03:35 - 08:49 ! Start and end collision times Currents (mkA): Ie=1090, Ip=1130 ! beam currents at start time Peak luminosity: 2.3*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 9.6*10**31cm-2 ! Integrated lumi H1 gated lumi: 5.8*10**31cm-2 ! So called "effective" lumi H1 runs: 26100-26120 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) 16.07.1992 ===================== H1KFOM === New Release of OnLine SW... From H1 Run 26139 it was introduced new releases of two programs from H1LumiOnLine SW - H1LumiOnLineFIFOC and H1LumiOnLineRecNew19. Main reason - asking of J.Olsson and A.Campbell to decrement the LRTL-bank and LREC-,LRPC- data flows due to problems with his SW (J.Olsson now simply cuts this banks when its quantity is more then it is possible to keep at his disk data sets with RunStart/KEEP/EndRun events for single Run. Alan Campbell last two days during rare L2Keep- rate at H1Runs which were written during absence of ep-collisions had problems with intermediate keeping of KEEP-banks before retranslating its into H1CDAQ - his program was crashed). At today releases of high mentioned H1LumiOnLine program it was reali- zed temporary decision of this problem (with agreement with J.Olsson, A.Campbell and S.Levonian) - this banks will be switched off automati- cally when Ie<10mkA. Only during presence of HERA e-beam this banks (LRTL,LREC and LRPC) will appeare at H1DataFlow. The next (cosmetics) changing were made too: 1) default switching off of LRTS-bank. At previous release this bank was on with default. 2) default switching on of Mode 1 for calculation luminosity. At previous release it was Mode 3 as default Mode (as You remember with Mode 1 the current luminosity value is got as previous measured value when negative value calculated). 3) default value of deep at GPTP-pipe line for T0 is installed on value 14 (at previous release it was 2) - it seems more reasonable value for creating of contents VETE-bank. Note: today VetoWall-people firstly were interested with VETE-bank contents. During this morning first conclusions about the behaivour of 48 trigger bits of VetoWall which are at H1Lumi readout were made. Tomorrow the next step of investigations must be done by tandem - I.Sheviakov and Konrad Flamm - investigation with p-beam at local mode of H1Lumi (H1Lumi- OnLineA). 16.07.1992 ===================== H1KFOM === Tomorrow 22 x 20 bunches... As just now Evgenio retranslated from HERA Control Room - tomorrow it is planned to fill 20 p-bunches (#0-#9 and #12-#21) with total cur- rent not more then 1.5 mA and (if all will be OK with p-beam ramping keeping) to fill 22 e-bunches (#0-#21) with total current not more then 3.0mA and (if all be OK with ramping and keeping of e-beam) to try collisions firstly at modec 20 x 20+2. We must be ready. 16.07.1992 ===================== H1KFOM === Proposal .................. Today it was born the idea how to find the relation coefficient set without large problems (as seems). The idea was born by Egor. As You remember the relation coefficient set is the set of 74 (or 75) of coefficients which are used for finding of current value of calibration coefficient for individual channel at Photoproduction Branch. The chain of calculation (as was proposed long time ago) must be the next: You can get calibration coefficient for individual channel from Luminosity Branch and multiply on individual relation coefficient for this channel and as a result get the current value of calibration coefficient for thid channel at Photoproduction Branch. It is supposed that H1LumiReconstruction program must use not calibration coefficient set from H1DataBase which are now never changed (and last update was due to last calibration almost one month ago) but current calibra- tion sets from LREC- and LRPC-banks which must be multiplied on relation coefficient set. In principle we hope that this relation coefficient set must be unchangable with time (as long as new timing will be introduced) and in principle it would be good candidate for replacing of existing H1DataBase`s absolute calibration coefficient set Or simply - each calibration coefficient for Photoproduction Branch consists of two part (changable with rate and unchangable with rate). As first analize shows - Usik`s algorithm of permanent calibration at FIC#2 is the good base for tuning of calibration coefficient set for photoproduction branch too (as seems the changing of CC set at photoproduvtion branch is obvious now and it is possible to tune its each 11 sec.). It was preambula. Now about Egor`s idea - how to made relation coeff. set: 1) it is possible to switch on the ETAG-trigger as ET&PD&anti(Water Counter) or ET&PD (may be two steps with different triggers); It must be labeled as special Run(or Runs) for H1Lumi internal tuning; 2) we must to tune (or keep the old) the prescale factor - with value which provides the same rate of data taking of Lumi-events as #FIC2 provides calibration (near 8-9 Hz). It means that we have the same flow of Lumi-events at both branches with equal conditions (rates especially). 3) at the #FIC2 it must be ordinary calibration procedure and ordinary creation and putting into H1LumiDataFlow of LREC- and LRPC-banks (and at off-line we can see the behaivour of each CC with time). 4) all this procedure must get 2-3 hours with good many bunches e-beam (may be the lot of Runs etc. with physics collection for another branches - but H1Lumi - no any physics collection - only data taking for tuning of CC-set for Photoproduction Branch; 5) at offline we must select all LREE and LRPE-banks from all Runs which were written during this period and provide needed calibration step (as we made earlier - 2 times). 6) good output of this procedure will be existance of pictures with behaivour of individual calibration coefficient with time at both branches - last step - calculation of relation coeff.set. 7) Of coarse may be we shall meet unwaitable situation but let`s try to make something for saving of collected data - it is main. And the last - Egor said that in principle it it possible without changing of HV - to tune some attenuator for e21 and to remove crazy situation with overflow. After this step in principle it would be useful to repeat the same procedure else one. But Egor supposes and hopes that may be only recalculation of CC for e21 must be done from simple measuring at on-line (before changing and after changing) of some reper values. 16.07.1992 ===================== H01LNS === Replay to F11LEV .......... Some questions and some info on our processing, in the order of the contribution by S.Levonian, 15.07.1992: 1. You say about "Sheviakov's Low energy peak". What are the energies in this peak? Must be the relevant entry for angle? 2. Our ET energy spectrum was analysed for the subset IF (JLUEL.GT.0) THEN IVEC = JLUEL c h-fillings from ivec ENDIF Note: No other event selection was done. Is that right and sufficient, or not? 3. "these bloody overflows" are not yet known here well enough. 4. Here, only "(*G)"-runs are being used, but many different such runs. 5. The question beyond the topic: Is there any way to pick up Lumi_values in loops of H1PHAN, i.e. for any event. Interesting are (diff.,integr.)*(orig.,eff.). The recommended in H1PHAN Iders, QLRTLU, QLRTBL, return zeroes. May be the cause is in the wrong point in program, but JLRTxx are OK 16.07.1992 ===================== H1KFOM === ep-collisions #29 ......... Date: 16/07/92 Collision time: 17:23 - 23:44 ! Start and end collision times Currents (mkA): Ie=1100, Ip=1440 ! beam currents at start time Peak luminosity: 2.9*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.4*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.2*10**32cm-2 ! So called "effective" lumi H1 runs: 26143-26160 ! Which runs were recorded Additional comments: 10 collided e-bunches (from #0 up to #9) 1 non-collided e-bunches (#19) 10 collided p-bunches (from #0 up to #9) 16.07.1992 ===================== F11LEV === to H1PHANatics ............ First, a general comment: at that level of real data quality and recon- struction performance I personally would not blindly rely on the PHAN. There are still many problems to understand which one should go to the rec.output or even to the raw data. Also at the hot time of data taking offline s/w (including H1PHAN) cannot immediately follow all changes done at the online/trigger/DAQ. During the shut down and after first data analysis it will be improved of course, but presently H1PHAN must be used with care. I personally do not use it at all, but others do use it. Experience shows, that in fact only authors and few experts indeed understand what to do in which case. Simple minded users often got wrong results. For MC it is much more reliable. Now real information. 1) A low-energy tail from noise and low-enegry background ends practi- cally around 5 GeV (rec.energy). This noise has a maximum at E=0, as usual, but due to internal E_min-cut in LREC module (and after- wards in the event classification), it appears at the DST like a maximum at this E_cut value (default LREC cut = 3 GeV, ECLASS cut is presently 4 GeV, but must be 5 in future). Around 5.5-6 GeV starts ET-acceptance for good electrons. Thus, between 5 and 6 GeV it must be something like a minimum in E-distribution for ALL EVENTS, HAVING ETAG bank. If however, one would use only events having ETAG trigger bit=1, this low energy peak disappears, since it is rejected by the trigger lower threshold. 2) Selection "IF (JLUEL.GT.0) THEN" just means that LETR bank is present in the event, which is not entirely equivalent to the eTAG triggered envents. ET-info is readout ALWAYS, for ANY H1 TRIGGER In most cases it just contains this tail from noise which after reconstruction may reach 5 GeV, will be cut at 3 or 4 GeV and give you low-energy entries in the distribution. Many of the H1PHAN users had presented such a distributions. You can live with that and do not ask for the eTAG trigger bit if in addition you will apply further E-cut at the minimum of E-spectrum around 5-6 GeV. 3) There is sufficient information about overflow problem in our LUMI logbook, please find it and read, no time to repeat again. By the way, I am wonder that bosses were at DESY and are still not aware about our most essential problems... 4) Beautiful. 5) This is one of the examples when PHAN might be a bit outdated. I must admit, that I never checked correctness of the LUMI data implementation in H1PHAN. Finally it was agrreed that I will pro- vide corresponding tool to access all relevant data, but this I am going to do only before the next run, on the basis of the pre- sent experience. I have not found QLRTLU, QLRTBL in the current PHAN Manual. JLRTLU, JLRTBL looks correct in the chapter 8.6. But I always access bank LRTN directly to pick up these data. There may be several ep-runs where LRTN bank for some unknown to me reasons was not written (au, Fomenko-o-o...). In these (very rare) cases zero will be returned. 17.07.1992 ===================== H1KFOM === ep-collisions #30 ......... Date: 17/07/92 Collision time: 00:00 - 02:25 ! Start and end collision times Currents (mkA): Ie=1200, Ip=580 ! beam currents at start time Peak luminosity: 8.5*10**27cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 3.4*10**31cm-2 ! Integrated lumi H1 gated lumi: 3.2*10**31cm-2 ! So called "effective" lumi H1 runs: 26162-26171 ! Which runs were recorded Additional comments: 10 collided e-bunches (from #0 up to #9) 1 non-collided e-bunches (#19) 10 collided p-bunches (from #0 up to #9) 17.07.1992 ===================== H1KFOM === ep-collisions #31 ......... Date: 17/07/92 Collision time: 07:20 - 10:30 ! Start and end collision times Currents (mkA): Ie=730 , Ip=1280 ! beam currents at start time Peak luminosity: 1.7*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 8.3*10**31cm-2 ! Integrated lumi H1 gated lumi: 5.5*10**31cm-2 ! So called "effective" lumi H1 runs: 26172-26193 ! Which runs were recorded Additional comments: 10 collided e-bunches (from #0 up to #9) 1 non-collided e-bunches (#19) 10 collided p-bunches (from #0 up to #9) 17.07.1992 ===================== H1KFOM === ep-collisions #32 ......... Date: 17/07/92 Collision time: 11:50 - 20:30 ! Start and end collision times Currents (mkA): Ie=1050, Ip=800 ! beam currents at start time Peak luminosity: 1.4*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.03*10**32cm-2 ! Integrated lumi H1 gated lumi: 8.9*10**31cm-2 ! So called "effective" lumi H1 runs: 26172-26193 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) 18.07.1992 ===================== H1KSOL === Luminosity Run ............ Date: 18/7/92 Collision time: 03.34 - 11:25 ! Start and end collision times Currents (mkA): Ie= ???? Ip=0460 ! beam currents at start time Ie= 1200 ! (A.F. - from off-line) Peak luminosity: 7.0*10**27 ! Max lumi, usually at start time ! Total lumi: 5.05*10**31 ! Integrated lumi H1 gated lumi: 4.43*10**31 ! So called "effective" lumi H1 runs: 26232-26266 ! Which runs were recorded Additional comments: Value of Ie was not supplied by San Palych. Before e-beam dump some manipulations with e beam were done during wich (last 4 minutes) we got a wrong value of Lumi.Probably it was caused by not correct nalues of currents (again!). Consequences of these actions one can observe on ETPD Energy and Coordinates plots in our Logbook N2 in H1CR as well. Additional comments: 9 collided e-bunches (from #0 up to #8) (A.F. - from off-line)1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) 19.07.1992 ===================== H1KSHE === Luminosity Run 20x20....... Date: 19/7/92 Collision time: 06:12 - 09:35 ! Start and end collision times Currents (mkA): Ie= 1170 Ip=1630 ! beam currents at start time Iepilot= 91 mkA Peak luminosity: 2.2*10**28 ! Max lumi, usually at start time ! Total lumi: 5.46*10**31 ! Integrated lumi H1 gated lumi: 4.34*10**31 ! So called "effective" lumi H1 runs: 26274-26303 ! Which runs were recorded Additional comments: 10 (from 0 to 9) filled e-bunches 4 (from 10 to 13) empty e-bunches 9 (from 14 to 22) filled e-bunches 1 (29) e-pilot bunch Total number of e.filled bunches 10 + 9 + 1 = 20 20 - p.filled bunches i.e. 10 (from 0 to 9) p.filled b. 4 (from 10 to 13) empty 10 (from 14 to 23 ) p.filled b. Total number of p.filled bunches 10 + 10 = 20, so it was 1(23) p-pilot bunch. 19.07.1992 ===================== H1KFOM === New H1Lumi Trigger Bits ... Today it were discussed some questions about using of new H1Lumi Trig- ger bits (I.Sheviakov,E.Elsen and U.Goerlach). It was decided to intro- duce 2 new H1Lumi Trigger Bits - so called "Lumi" and "RadCorr". As the result now there are at SubtriggerWord 2 (64-95) two trigger bits with number 20 (84) and 21 (85) which are mean - "Lumi"-20(84) and "RadCorr"-21(85). As I understood this trigger bits now are not active (this posibility must be made with activity of M.Zimmer and J.Coughlan with updating of H1 Supervisor program) but in principle this trigger bits are monitoring from Run26315 or a little more. Trigger bit "Lumi" is ET&PD&anti(WaterCounter). Trigger bit "RadCorr" is anti(ET)&PD&WaterCounter. The act of introducing of this trigger bits into H1CTRIG-environment is labeled with note at "Trigger.Vol.1"-logbook (companion to H1 Log- Book) at page 121 (this day). The prescale factors installed now as "64" for "Lumi" and "65535"-for "RadCorr". This factors must be tuned during making of this trigger bits as active trigger bits. It is needed to discuss some details of passing of events which were born due to hitting of this trigger bits through L4farm with A.Campbell (but this is after "activization" of our trigger bits procedure - now only monitoring is possible - and may random coincidence with another trigger bits of H1). 19.07.1992 ===================== H1KFOM === High e-beam Currents....... As You know from message of I.Sheviakov tonight it was began the activity of HERA-machine with 20 and more bunches. At 03:40 it was finished p-beam ramping and at HERA p-ring it was existed (up to 12:52) - near 9 hours - p-beam with 20 bunches (bunch numbers of p-beam - from #0 up tp #9 and from #14 up to #23). The p-beam current at start time of existing was 1720 mkA. From 06:12 it was made ep-collisions with e-beam which consisted of 20 bunches too (19 bunches had collided and 1 bunch existed as pilot). It was #34th-collisions at history which was started at 29.06.92. e-beam current at the start of 34th-collisions was 1170 mkA. e-beam bunch numbers were the next - from #0 up to #9 and from #14 up to #22 - as collided bunches - and #29 as pilot bunch. p-bunch #23 was as p-pilot bunch. At 09:36 e-beam was lost due to (may be) "some experiments with e-beam" -as was wrote at TV-screen from HERA Control Room. P-beam was kept with current 1510 mkA. After this it were made 4 attempts of e-beam injection (unsuccesfull) 1) At 10:14 - bunch numbers from #0 up to #21 - 22 bunches (it was attempt to use e-bunches #10,#11,#12 and #13 as four pilot e-bunches - we never test this posibility at our system - but as seems this option of work with more the one pilot bunch must work - we must make the "NumberOfPilotBunches" option not "1" as it was earlier but "4" for this case - NPB at "LumiMeasure ments"-card of NewFastLumiMonitor-project). At 10:48 this e-beam was lost ( Ie=1960 mkA); 2) At 10:59 - the same bunch numbers and the same quantity of e-bun- ches - Ie=1890 mkA. At 11:17 this e-beam was killed due to error with extra filling of bunches (it was filled single bunch #4 with large current near 700 mkA). 3) At 11:25 - bunch numbers from #0 up to #12, from #14 up to #22 and #24 - 23 e-bunches (it was attempt to use e-bunches #10,#11,#12 and #24 as e-pilot bunches - at H1Lumi it was possible to use only three from #10 up to #12. P-bunch #23 was prepared for using as p-pilot). At 11:59 e-beam was lost (Ie=3310 mkA). p-beam was kept with Ip=1460 mkA. 4) At 12:25 - bunch numbers from #0 up to #21 - 22 e-bunches. (as at (1) attempt). Before preparing to (4) - attempt of e-beam injection the large part of p-beam was lost (only 690 mkA was kept) due to "Quad-trip" At 12:46 e-beam was lost (Ie=3749 mkA, Ip=650 mkA). At 12:52 p-beam was killed too. Now (at 14:28) it is started the p-injection. 19.07.1992 ===================== F11LEV === LUMI data/New triggers..... 1) Some times online lumi data seem to have systematic discrepancy compared to the data from Run Summaries, which is very strange, since Run Summary uses nothing but our own LRTL bank content. Examples (lumi in mkb-1 units): Date on line data (from this logbook) Run Summaries Total LUMI Effective LUMI Effective LUMI ----------------------------------------------------------- 16/07 236 178 209 17/07 220 176 167 18/07 50 44 44 19/07 55 43 55 ----------------------------------------------------------- As one can see data from 16 and 19 of July disagree with Run Summary Does anybody from online have an idea what could be the reason? 2) As I can understand from A.M. message so called "RadCorr" trigger ("Trigger bit "RadCorr" is anti(ET)&PD&WaterCounter"...) will not be set in case of E(WaterCounter) < threshold, which is not good, since we are going then to loose most clean (but of course rare) rad.corr. events. Why dont just ask for: noET (E_ET < 4 GeV) & PD (E_PD > 3-4 GeV) ? I would rather prefer to go up with PD threshold in case of too high rates, than kill all candidates which pass through filter without interaction(8-10% of full sample, but with the best energy estimate) 19.07.1992 ===================== H1KSHE === New Trigger elements...... Realy were was not 2 but 3 trigger bits added in central trigger they are PD,ET,V/C. They are formed later in two trigger elements TE84 = ET*PD*!V/C and TE85 = !ET*PD*V/C, the last TE so called Rad.correction, was selected espesialy to have addition flexibi- lity without reprograming CT. Coincedence between PD and VC makes the photon arm not sensitive to different kinds of nose. Of course going up the PD threshold the same result will be reached, but during lumi measurements at this moment it is not possible. Now I am in prepearing separate TEmakers for photoproduction and spare (Radcorr for instanse) porpouses. As concern the trigger !ET*PD it can be done at one second by V/C = 1, with the trigger !ET*PD*!VC the same order of problem i.e. V/C = !V/C becouse all bits under lumi system control first of all. Do not forget please that curent central trigger TB set is temporary the final is not yet exist. I ask to keep the current status for TE85 for some time to have not more problems before the background situation becomes clear or at least TE makers will be ready. In case special runs for our system there are no problems at all with any trigger selection for this moment. The question just concern multitrigger mode operation together with CT and compleetly different set of thresholds for PD,ET,VC, and simultenios lumi measurement. Worring: First it was idea to have complietly indetical trigger conditions for lumi and photo branches as concern relevant thresholds. In this case cross sheck trigger efficiencies for both branches can be done with maximum acuracy and in real time. Last investigation of real backgrounds shows that separate energy cuts should be prefer for both branches. Fortunatly it is not hard to do becouse of relevant set of discriminators and following digital logic exist but some reconnection in H/W and additions in online S/W must be done. More complicated task is to do photo- production branch under the same detail control level as possible at present, this is a main problem. 20.07.1992 ===================== H01USA === LUMINOSITY RUN ............ DATE: 19/7/92 COLLISION TIME: 23.00 - 04:33 ! START AND END COLLISION TIMES CURRENTS (MKA): Ie= 1115 Ip=0600 ! BEAM CURRENTS AT START TIME PEAK LUMINOSITY: 1.2*10**28 ! MAX LUMI, USUALLY AT START TIME ! TOTAL LUMI: 4.40*10**31 ! INTEGRATED LUMI H1 GATED LUMI: 3.70*10**31 ! SO CALLED "EFFECTIVE" LUMI H1 RUNS: 26318-26324 ! WHICH RUNS WERE RECORDED Additional comments: Standart e-bunch configuration (9+1(#19)), but wrong additional bunch filling (#219) with current on the level ~ 20% relatively another bunches. High HV on channel #16 of PD - compromat stuffare available in H1 CR logbook. After lumi run from 4:33 up to 5:48 - mashine shift with the same beams. WARNING: Effective lumi from the Run Summary (Runs 26319-26324) = 46.1 mkb-1 = 4.61*10**31 (compared to 37 mkb-1 from online) (S.Levonian) 20.07.1992 ===================== H1KSHE === Luminosity Run 10x(9+1).... Date: 20/7/92 Collision time: 10:36 - 11:48 ! Start and end collision times Currents (mkA): Ie= 1650 Ip=830 ! beam currents at start time Peak luminosity: 3.6*10**28 ! Max lumi, usually at start time ! Total lumi: 6.81*10**31 ! Integrated lumi H1 gated lumi: 6.51*10**31 ! So called "effective" lumi H1 runs: 26326-26327 ! Which runs were recorded Additional comments: 9 (from 0 to 8) filled e-bunches 1 (19) e-pilot bunch 10 - p.filled bunches i.e. 10 (from 0 to 9) p.filled b. 20.07.1992 ===================== H1KFOM === "Calibration" Run.......... Today it was possibility to write Run with our new trigger bits when p-beam was killed and e-beam with 10 bunches was existed during some time. At 12:25:25 Egor after some manipulation with updating of active trigger bits at H1Ctrig-monitor had began the writting of Run 26331 (35 min of data taking). TEMPORARY LOGGING. Electron beam status during Run 26331: Ie total = 1240 mkA at 12:25 Ie total = 1100 mkA at 12:59 (when Run was finished) Bunch e-currents existed at 10 bunches (from #0 up to #8 and at #19). Ie bunch (max) = 150 mkA (bunch #5) at 12:25 Ie bunch (min) = 95 mkA (bunch #19) at 12:25 Ie bunch (max) = 128 mkA (bunch #5) at 12:59 Ie bunch (min) = 89 mkA (bunch #19) at 12:59 Beam position: Xpd near 0.1 cm Ypd near 0.2 cm (with LRTL-bank data) It is pity but before Start of this Run it was existed some manipula- tion with e-beam (which may be connected with disappearence of p-beam) and Egor switched on e-beam synchronization. After contact with HERA- people (they said that now is stable e-beam) Run 26331 was started. But due to this high mentioned manipulation - Luminosity branch (which is calibrated permanently) got very far from true values of calibration coefficients and after switching of normal condition the first jumping of all calibration coefficients were very large (e21 - 15%, e22 - 22%, e23 - 33%, e24 - 42%) - and from this first values calibration coefficients slow incremented due to decrementing of rates (e21 - on 18% level (3% of incrementing), e22 - on 23% (2%), e23 - on 36%(3%), e24 - on 47%(5%). Calibration Coefficients for PD cells during all 35 period had permanent decrementing and did not install on some stable values (p11 - from -5% up to -9%, p12 - from -6% up to 19%, p13 from -1.5% up to -6.5%, p17 from -1% up to -6.5%. All high mentioned cells were mostly hitted during Run. May be due this fact - Trigger Efficiency Coefficient (which at last time was near 0.84) was at the level 0.55-0.60 - it means that calibration of lumi-branch was bad and was not finished after 35 min of Run. It means that the idea to compare both sets of CC at the end Run and to find relation coefficient set did not find its resolving. It was unsuccesful attempt to find very long time waitable the relation coefficient set. It is needed to repeat this procedure with "good" e-beam (which is syncronyzed and tuned for collisions - not standalone e-beam). This beam had another beam position as all e-beam which was used for ep-collisions. Another strange fact: There were relatively low quantity of overflow at e21 and another our famous "overflow hitting" channels. These are the digits: e21 - only near 138 from 40450 events, p16 - only near 897 from 40450 events. This Run is very intersting with another situation: it is possible firstly to look for at TLV1-bank the source for L2Keep-interrupt for H1 with our new trigger bits: "Lumi" and "RadCorr". Prescale factors were choosen as the next: for "etag" (28 bit at Trigger 2 word - default value 8192, for "Lumi" - 7, for "RadCorr"- 300. Really main statistic at this Run is from "Lumi"-trigger. But it is possible to look for "RadCorr"-events, "etag"-events and very little fraction of another trigger bits (which were not switched off). Egor defined (preliminary) future values of prescale factors for our new trigger bits (280 for "lumi" and 1200 for "RadCorr") - with this values of prescale factors this trigger bits (when they are activated) put into H1 the rate not more then 0.5 Hz each (under this type of rates). After this step which was attempt to make connection of LREC- and LRPC-contents with behaivour of CC set at photoproduction branch (unsuccesful attempt due to strange (not ordinary) e-beam) Egor and Evgenio made the changing of HV-set (for removing of "crazy situation with overflow"). Now this HV-set installed but we have not any calibration for this HV-set. The values of new HV-set are kept at the next files: "FileHVETdefault.20.07.92" "FileHVPDdefault.20.07.92" It would be good if at nearest ep-collisions we shall try to get first 10-15 minutes for getting of near 50000 events of pure lumi events (with CTRIG and Lumi - branches only at CDAQ) with low prescale factor for "lumi"-trigger bit for first attempt of calibration with new HV-set (at off-line). As seems it is needed to return temporary to old HV-set and to try making the same which were made today by Egor but with "good" e-beam. It is needed for "saving" of all data which were collected during all previous ep-collisions with "etag"-trigger bit. 21.07.1992 ===================== H1KFOM === New HV-set for ET and PD... Yesterday evening it was changed some HV-setting on some ET and PD cells (Egor and Evgenio): et21 2100 -->2000 pd02 1890 --> 1750 et23 2010 -->1920 pd11 1840 --> 1800 et24 1900 -->1850 pd12 1710 --> 1660 et25 1960 -->1860 pd13 1810 --> 1760 et26 1995 -->1870 pd16 2050 --> 1900 et27 1860 -->1800 et30 2215 -->1950 et32 1835 -->1800 et33 1795 -->1750 et40 2035 -->2000 The values of new HV-set are kept at the next files: "FileHVETdefault.20.07.92" "FileHVPDdefault.20.07.92" 21.07.1992 ===================== H1KFOM === Run 26331 at Cartridge..... Run26331 (for any case) is saved on permanent cartridge with name: H1KFOM.LUMI92.CAA26331 with 40450 events. (Example of JOB at #CARCAR2 data set at library H1KFOM.LUMI92X). It was succesfully selected "Lumi"-trigger bit`s events for attempt of calibration - but something notunderstandable exists at et23 and e24 deposited energy distributions (two maxima) - may be something was not good with e-beam during of Run? It is impossible to remove low energy peak (near 16 GeV) at spectrum ETrec+PDrec. Peak with mean value 26.6 and sigma=1.01 GeV exists and has near 60% events - as You remember the same was at Luminosity branch - Koefficient of LumiTriggerefficiency was near 55-60%. (Example of JOB at #E200792 data set at library H1KFOM.LUMI92X). Attempt to skip the first half of data (20000 events) put the same result - two maxima at et23 and et24 (not understandable). It means that this two peaks existed during 35 min. As seems nothing possible to make with this data (it is pity). In principle it is possible to see the efficiency of new "RadCorr" bit - which are the spectra of PDrec,ETrec and WaterVeto - is any population of statistics at ET spectra at region more then SumET thresholds. 21.07.1992 ===================== H1KFOM === "RadCorr","ETAG" etc. ..... At Run 26331 it is possible to find 35867 events with "Lumi" trigger bit as source, 3255 events with "RadCorr"-trigger bit as source, 490 events with "ETAG"-trigger bit as source and 838 events with another H1 trigger bits as source (they was not switched off). First view on deposited energy histos: ETdep (for "RadCorr") - no any population of statistics with energy more then 5 GeV; PDdep and PDdep+WaterCounterdep (for "ETAG"-trigger bit) - no any population of statistics with energy more then 2 GeV. Examples of jobs for selection and analize of this type of events are kept at #A210792 ("RadCorr") and #B210792 ("ETAG") data sets of H1KFOM.LUMI92X - library. 23.07.1992 ===================== H1KFOM === Calibration Run 26635 ..... At the beginning of 37th ep-collisions (which were started near 21:55) during the tuning of optimal luminosity it was written special Run for first attempt of calibration of Phortoproduction Branch with new High Voltage set which was installed at 20 July 1992. Run 26635 was started at 22:20 and finished at 22:30 (rate of data logging was near 100 Hz). It were collected 54250 events with pure Luminosity Trigger - ET&PD&anti(waterCounter). Run was written as permanent data and is wriiten on two cartridges: HERA04.H1RAWD.C9201508 - first 10767 events HERA04.H1RAWD.C9201509 - last 43483 events. 23.07.1992 ===================== H1KFOM === Problems with LRTL-bank.... It is pity but only at 23:42 it was corrected notunderstandable up to now (firstly appeared) error - it was not written LREC, LRPC and LRTL-bank into H1DataFlow. Due to this error all first Runs at this 37th ep-collisions are not supplyed with Integral Luminosity values (as seems - firstly at this data taking seance). As I found something happened with Flag "LRTLBankBusy" at H1LumiOn- LineFIFOC-program ( it was at status "1" - after writting into this flag of values "2" - with VME-tools "MM B002C314 00000002 -l"- all became OK). In principle the same it would be possible to make with restart or reload of H1LumiOnLineFIFOC-program but it was impossible due to running of Luminosity-branch at H1CDAQ-environment. From Run 26443 Integral Luminosity values was sent with LRTL-bank into H1DataFlow and into RunSummary and into H1 Supervisor too (and into ShowLumi-tools at LOOK- and H1ED-environment too). It is pity but we again have not relation coefficient set due to absence of LREC and LRPC-banks during calibration Run 26635. 24.07.1992 ===================== H1KFOM === ep-collisions #37 ......... Date: 23/07/92 - 24/07/92 Collision time: 21:57 - 01:02 ! Start and end collision times Currents (mkA): Ie=1820, Ip=1330 ! beam currents at start time Peak luminosity: 4.0*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 2.24*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.99*10**32cm-2 ! So called "effective" lumi H1 runs: 26634-26652 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) Peak Luminosity was achieved at 22:30 Luminosity at start time was near 2.5*10**28 LRTL-bank was written into H1DatFlow from 23:42. 24.07.1992 ===================== H01USA === LUMINOSITY RUN ............ DATE: 24/7/92 COLLISION TIME: 21.03 - 21:23 ! START AND END COLLISION TIMES CURRENTS (MKA): Ie= 1990 Ip=0930 ! BEAM CURRENTS AT START TIME PEAK LUMINOSITY: 4.0*10**28 ! MAX LUMI, USUALLY AT START TIME ! TOTAL LUMI: 4.40*10**31 ! INTEGRATED LUMI H1 GATED LUMI: 3.70*10**31 ! SO CALLED "EFFECTIVE" LUMI H1 RUNS: 26724 ! WHICH RUNS WERE RECORDED Additional comments: Run was recorded during tunning phase for relevant calibration of fic1 branch with old HV set: ET: 08.06.92 . PD: 24.05.92 23015 events. Both beams were lost with quench alarm. 25.07.1992 ===================== H1KFOM === ep-collisions #39 ......... Date: 25/07/92 Collision time: 13:20 - 15:40 ! Start and end collision times Currents (mkA): Ie=1180, Ip= 810 ! beam currents at start time Peak luminosity: 7.0*10**27cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 4.02*10**31cm-2 ! Integrated lumi H1 gated lumi: 2.66*10**31cm-2 ! So called "effective" lumi H1 runs: H1CDAQ was dead ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) p-beam had "bad" bunch length (see H1RUN-message) Peak Luminosity was measured at 13:50 when the values of e-bunch currents were inserted into H1Lumi "by hand" (H1CTRIG had the problems with transferring of currents - only at 14:14 experts made posiible to transferring of currents H1CDAQ all this period was non-operated - nothing was collected - effective lumi was collected during Bill's test H1Runs. At 15:40 e-beam was killed and at 15:50 p-beam. It was decided to return to Old values of High Voltage set - the work with new High Voltage set needs the fine tuning of thresholds values (now we had not any rate ET&PD-events at Ee=12 GeV and far from true ratio value of Rate Water Counter to Rate of ET&PD-rate (8500/360 Hz) with Ee=26.7 GeV - with Old HV set (6080/800 Hz - ordinary ratio). First ratio was got from unsuccesful attempt to make ep-collisions today (08:50 - 10:40) with p-beam which was ready from 07:26 (with bad bunch length). The second - from #39th ep-collsions after switching on of the Old HV set (at 13:08) - when ramping was finished (at 13:15). 25.07.1992 ===================== H1KFOM === Calibration Run 26724 ..... At the beginning of 38th ep-collisions (which were started near 21:10 yesterday evening - see message of Sasha Usik - 24.07.92) during the tuning of optimal luminosity it was written special Run for attempt of calibration of Phortoproduction Branch with old High Voltage and simultaneously to write LREC LRPC -banks from Luminosity branch. It was hoped that during this Run we can get information for getting of relation coefficient set for all "old" (written with Old HV set) data. The Old HV set was installed at 21:03. Run 26724 was started at 21:19 and finished at 23:30 (rate of data logging was near 100 Hz). It were collected 23017 events with pure Luminosity Trigger - ET&PD&anti(waterCounter). At 21:30 the new HV set was returned to both detrectors. It is pity but at FIC#2 at this time it were installed the new calibration coefficient set (for new HV set). And I think that nothing it is possible get from this Run too. It was the next unsuccesful attempt to get data for getting of relation coefficient set. The attempt was unsuccesful and due to very short time of Running - only 4 min (only 25 LREC and LRPC-banls were transferred into H1Lumi- DataFlow) It is needed to do this type of attempt else one and prolongate this Run as long as possible during optimization of Luminosity Run of HERA. (better to install the rate of "Lumi"-trigger bit not very high (it is enough 10-20 Hz)). Run was written as permanent data and is wriiten on two cartridges: HERA04.H1RAWD.C9201519 - first 13592 events HERA04.H1RAWD.C9201520 - last near 10000 events. We had three attempts to make data for getting of relation coeff. set - all attempts on different reason were unsuccesful. May be 4th will be more succesful. Run 26331 - "bad" e-beam conditions (old HV) Run 26635 - LREC and LRPC-banks were not written into H1Lumi Data flow (new HV set) Run 26724 - short time for getting info (4 min) - only 25 LREC,LRPC. - CCset at FIC#2 was installed for New HV Set but we worked with old HV set. 26.07.1992 ===================== H1KFOM === Calibration Run 26843 ..... At the beginning of 40th ep-collisions (tonight after midnight) it was written calibration Run26843 (our 4th attempt to make first at our history relation coefficients set). This Run was began at 00:12:29 26 July 1992 and finished at 00:29:29. It was collected a little more then 100000 events with "not-prescaled"-"Lumi"-trigger bit. The rate of data logging was near 100 Hz. We got data during almost 17 min. During of data taking LREC and LRPC-banks were appeared at data flow of H1 96 times. It is (as seems) enough for getting of first release of relation coefficients set. At FIC#2 it was operated release of H1LumiOnLineRecNew19 with tuning of start values of calibration coefficient on so-called "old" HV-set. As seems we can get relation coefficient set from this Run and to make attempt to re-reconstruct data with "etag" (a little peace - not all) - and to see - is any influence of taking into account of changing of CCset with rates. The value of p-beam current at the begin of this Run was 1500 mkA, e-beam-current - near 1900 mkA. Thanks to Sasha Usik for organizing of this data taking. 26.07.1992 ===================== H1KFOM === Relation Coeff. Set........ After processing of Run 26843 it is possible to say that we have now relation coefficient set (only for 12 channels at PD and 7 channels at ET). All relation coefficients were calculated with the next formula: Relation Coefficient(i) = LumiBranchCC(i)/PhotopoductionBranchCC(i) e21=1.152 e22=1.124 e23=1.208 e24=1.182 e25=1.147 e26=1.216 e27=1.174 p05=0.8801 p06=0.8638 p07=0.8356 p08=0.9485 p10=0.8603 p11=0.8166 p12=0.8426 p13=0.8522 p15=0.7956 p16=0.8805 p17=0.9138 p18=0.9004 All another CC for ET and PD had weigths less then 10.0 (and it is not recommended to use by A.Usik). It is proposed to re-reconstruct some piece of data which were tooked with "old" HV-set with procedure of "tuning" of CCset (not simply get from H1DataBase) - get from LREC(not Run Start Record) calibra- tion coefficients set for e21-e27 and divide its on relation coeff.set for this channels - You will get the "real" value of CC at Photopro- duction Branch. All another CC it is possible get from H1DataBase. Asking to S.Levonian - try please (if You have time). May be something will change at ETAG-spectra. 27.07.1992 ===================== H1KFOM === How Was Made Relation Coeff 1)It was made copy of Run26843 on own cartridge H1KFOM.LUMI92.CAA26843. Job is kept at H1KFOM.LUMI92X($CARCAR1). It was used 7 min.54 sec. CPU of IBM3090. 2)It was made calibration with collected data (100868 events). Job is kept at H1KFOM.LUMI92X($A260792). It was used 14 min.43 sec. of CPU of IBM3090. a)For calibration it were choosen only events with zero value of WaterVeto-channel (only 16064 events - near 16% of collected data). b)Start values of calibration coefficients for ET,PD was choosen the next (from last calibration at Run26724 - see page 25 at at H1LumiLogBook N2 (H1ControlRoom)): ET e00=2.830 2.868 2.890 2.877 2.646 2.625 e06=2.865 2.108 2.888 3.097 3.283 2.908 2.504 3.102 2.714 2.683 3.016 2.821 2.912 2.765 2.433 2.526 3.920 3.191 2.999 2.522 2.158 2.559 3.205 3.107 2.779 2.682 2.188 2.341 2.591 2.873 3.370 3.024 2.236 2.519 2.288 2.572 e42=3.058 3.546 3.050 3.131 3.819 3.012 e49=3.111 PD p00=2.009 1.334 1.079 2.007 p04=2.066 1.489 1.365 1.437 1.782 1.901 1.757 2.275 2.463 2.159 2.108 1.220 1.279 2.818 2.276 1.840 p20=1.762 1.800 2.464 2.650 p24=2.129 WCn=7.555 This values was got as the result of Usik's calibration algorithm and was corrected on factor 0.92 (all CC for ET were multiplied on 0.92 and all CC for PD were miltiplied on 1./0.92). 0.92 is the ratio A/B where A-position of maximum at ETrec energy spectrum and B=15 GeV (MonteCarlo-predicted position of this maximum). Note: Start values for calibration at Run26724 was got the same as are kept at H1DataBase for "old" HV-set (and which are present at LREC-,LRPC-banks at RunStartRecords). c) the result of calibration step is the next: ET e00=2.819 2.857 2.873 2.859 2.625 2.609 e06=2.853 2.104 2.872 3.080 3.245 2.905 2.496 3.068 2.710 2.651 3.032 2.782 2.776 2.782 2.443 2.734 4.275 3.141 3.037 2.745 2.222 2.601 3.255 3.094 2.705 2.551 2.159 2.256 2.400 2.869 3.334 2.981 2.171 2.459 2.177 2.559 e42=3.053 3.528 3.047 3.125 3.801 3.008 e48=3.103 PD p00=1.996 1.323 1.066 2.000 p04=2.057 1.443 1.329 1.423 1.670 1.893 1.754 2.170 2.370 1.962 1.968 1.052 1.096 2.957 2.269 1.797 p21=1.717 1.755 2.362 2.647 p24=2.125 WCn=7.555 d) the weigths had the next values (the same ordering as the CCset) ET 0.788 0.822 0.973 0.975 0.981 0.902 0.860 0.727 1.075 0.947 1.896 0.773 0.838 1.262 4.691 4.262 4.229 4.528 3.168 2.623 1.281 1359.317 1277.842 810.655 547.720 390.174 299.877 178.478 4.210 4.204 4.766 5.106 3.404 3.365 4.501 0.806 1.010 0.934 1.161 1.083 1.237 0.870 0.711 0.905 0.668 0.697 0.835 0.703 0.779 PD 0.979 1.213 0.990 0.863 0.923 8.195 25.055 30.396 8.160 0.959 160.363 1061.274 1250.371 264.072 3.478 18.671 69.314 80.321 24.277 1.994 1.320 1.180 1.872 0.956 0.737 0.650 3)It was made finding of the last values of LREC and LRPC-banks which kept the last values (at 17th minute from RunStart). Job is kept at H1KFOM.LUMI92X(#A260792). It was used 5 min.41sec. of CPU IBM3090. a) contents of 90th LREC and LRPC -banks is the next: LREC-bank contents: 90th(the ordering of CCset the same as earlier) ET 25138 25408 25595 25591 24044 23374 25375 18643 25559 27029 28181 25554 22702 28080 26889 26235 32087 25749 29825 26592 22341 31494 48074 37926 35911 31489 27030 30532 32222 29815 29227 31149 28297 27773 24900 24986 34679 30695 22671 25241 22974 28826 27119 29851 27703 27968 37944 27170 27932 LRPC-bank contents: 90th PD 15446 9729 9709 16479 16496 12697 11480 11893 15837 16511 15092 17719 19966 16722 17357 8366 9650 27015 20434 13351 10207 10683 21948 21046 17119 55743 b) only for 7 channels at ET and for 12 channels at PD it was calcu- lated the relation coefficients (at which we had more then 10 or near 10 values of weights). See previous message. c) simultaneously it was made monitoring of very important value - LumiTriggerEfficiencyCoefficient. Its value was near 0.84 - this is the good evidence that all is OK with calibration coefficient set at Lumi-branch - that means that it is possible make conclusion that we had equal conditions for calibration at both branches and ratio between high mentioned values of CC at both branches it is possible to use as the relation coefficient set. 4) But... Question for discussion... or may be it is needed to make re-reconstruction with two different relation coefficient sets. At ETrec-spectrum which was collected during calibration on the data of Run 26843 we have maximum at 16.6 GeV. In principle it means - if You will use the high mentioned relation coefficients set - You will make the same systematic shift at ETAG-spectrum (0.9 factor as 15/16.6). But may be it will be real spectrum - now I am not shure that high mentioned correction on MonteCarlo-predictions were made right. Many days worked Usik's algorithm of calibration at FIC#2 (without correction factor) put with stability the same value for maximum position at ETrec-spectrum - near 17 GeV (never more). May be Usik's algorithm is right? May be we have another acceptance? I think that it will be useful to make re-reconstruction with two relation coefficient set - a)high mentioned (if Usik is right) b) with multiplication on 0.9 (if Monte-Carlo is right). May be Soloviev's algorithm can help us - which are real coeffici- ents? 27.07.1992 ===================== H1KFOM === Else About Overflow........ During calibration it was made analyze of overvlow situation at all cells of our detectors (I remind that we work now with "old" HV-set). The result is the next (from 100868 events it was found the next quantities of events with overflow at each channels): ET e00= 0 0 0 0 0 0 e06= 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1908 17 18 8 6 36 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 e42= 0 0 0 0 0 0 e48= 0 PD p00= 0 6 3 0 p04= 0 29 67 74 0 0 47 118 52 246 0 431 729 0 0 0 p21= 3 14 0 0 p24= 0 The rates during this Run was near 1200-1400 Hz (ET&PD-events). Ie and Ip were enough large (1900mkA and 1500mkA). It must be large overflow situations with this high rates. The maximum overflow is at cell e21 (but near 2% only ). It is not understandable why at "etag"-events the number of overflow so much. 27.07.1992 ===================== H1KFOM === ep-collisions #40 ......... Date: 26/07/92 Collision time: 00:00 - 02:45 ! Start and end collision times Currents (mkA): Ie=2010, Ip=1590 ! beam currents at start time Peak luminosity: 3.8*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 9.62*10**31cm-2 ! Integrated lumi H1 gated lumi: 7.18*10**31cm-2 ! So called "effective" lumi H1 runs: 26840-26861 ! Which runs were recorded Usik nothing write about this ep-collisions into LLO. I rewrote information from H1LumiLogBook. Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) Peak Luminosity was achieved at 00:20 Luminosity at start time was near 2.0*10**28 27.07.1992 ===================== H1KFOM === ep-collisions #41 ......... Date: 26/07/92-27/07/92 Collision time: 20:30 - 03:57 ! Start and end collision times Currents (mkA): Ie=????, Ip= ??? ! beam currents at start time Ie=1280, Ip= 950 ! at 21:23 (after 45 min.) Peak luminosity: 1.5*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.95*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.61*10**32cm-2 ! So called "effective" lumi H1 runs: 26948-26967 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) Peak Luminosity was achieved at 22:14 Luminosity at start time was near 7.0*10**27 Information from E.Malinovskii: IP was shifted on near 30 cm on the direction of p-beam (due to 2ns of e-bunches shifting). At 03:57 e-beam was killed. Ip was kept with value near 740 mkA but during new e-beam filling and ramping the p-beam (at 04:43) was lost. 28.07.1992 ===================== H1KFOM === ep-collisions #42,#43...... Usik again nothing write about this ep-collisions into LLO. I rewrote information from H1LumiLogBook. As seems Mr.A.P.Usik forgot about his shift`s duty - this is not first time - see #40 ep-collisions (shame to Mr.Usik). Date: 27/07/92 Collision time: 13:15 - 18:27 ! Start and end collision times Currents (mkA): Ie=1490, Ip=1020 ! beam currents at 13:19 Peak luminosity: 4.5*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.58*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.33*10**32cm-2 ! So called "effective" lumi H1 runs: ?????-????? ! Which runs were recorded Additional comments: 18:27 - e-beam was killed 19:12 - finish of the next e-beam filling and ramping (Ie=2590 Ip=450) with the same p-beam Nothing is wrote at H1LumiLogBook about collided and non-collided bunches and about H1Runs during this collisions. From off-line analisis: During 42nd ep-collisions it were written H1Runs 26984-27013. Start value of Ie (after full filling) was near 2200 mkA. Near 18:10 the more then half of p-beam was lost (950 mkA->450 mkA). 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) Date: 27/07/92 Collision time: 19:35 - 20:52 ! Start and end collision times Currents (mkA): Ie=1440, Ip= 440 ! beam currents at 19:19 Ie=1100, Ip= 430 ! beam currents at 19:54 Peak luminosity: 0.7*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.75*10**31cm-2 ! Integrated lumi H1 gated lumi: 1.66*10**31cm-2 ! So called "effective" lumi H1 runs: ?????-????? ! Which runs were recorded Additional comments: 20:52 - p-beam was killed 21:03 - e-beam was killed Nothing is wrote at H1LumiLogBook about collided and non-collided bunches and about H1Runs during this collisions. From off-line analisis: During 43rd ep-collisions it were written H1Runs 27016-27020. Start value of Ie (after full filling) was near 2600 mkA. 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) 28.07.1992 ===================== H1KFOM === "Lumi" and "RadCor"........ Yesterday morning at the operation meeting of H1 it was promised that "Lumi" and "RadCor" trigger bits will be involved into default set of the TriggerSetting for H1 with enough large prescale factors - each from its will have rate not more then 0.5 Hz after prescaling. At H1 LogBook I found the comments to Run 26991 - "New Trigger Setting Subtrigger 2 was changed from 03C00000 to 07F00000. As seems this is the involving of our new trigger bits into H1CTRIG-environment as L2Keep-sources. Now it is possible to test - how right are our calibration coeffi- cients for Photoproduction Branch. We have good reper at this branch now. 28.07.1992 ===================== H1KFOM === Large Screen at HCR ....... Today at H1Lumi2 MacII it was replaced additional large screen together with VideoCard on little screen (size of ordinary MacII terminal) with own VideoCard. Large screen (as was proposed by present Run Coordinator Kiessling and was supported by F.Brasse) was delivered on HERA Control Room's MacII and installed. Sasha Usik made the modifications of his SW for coexistance with large screen at HERA Control Room's MacII and with little screen at H1Lumi2 MacII. The second (old) large screen is kaputt now (at H1lumi MacII). Somebody from H1 officials promised to buy large screen for H1Lumi2 at nearest future. 120 MByte Hard Disk now available for H1Lumi2 (or H1Lumi) and it is possible to install it at nearest shut down break. Asking to Sasha be very careful during changing of the hard disk. Keep all H1Lumi OnLine SW as better as possible. 28.07.1992 ===================== H1KFOM === Copies of H1Lumi OnLine SW. It was saved H1LumiOnLine SW which was kept at H1Lumi MacII's hard disc (for both FIC's and NewFastLumiMonitor) on hard disc of H1Lumi2 and on 13 diskettes. Now we have 3 copies of H1LumiSW - let's hope that nothinh happened at future. Now it is possible too to reload and restart both FICs from H1Lumi2 MacII too - the same menu is appeared at MPW:Worksheet-environ- ment ("FICstart"). Both NewFastLumiMonitor (on H1Lumi2 and on H1Lumi MacIIs) are the same now - the same release is installed. Due to bad quality of printing at LaserWriter at H1ControlRoom it was not possible to make full set of listing for 3rd release of H1Lumi- OnLine Software. 28.07.1992 ============== H1KSOL/H1KFOM === ep-collisions #44 ......... Date: 28/07/92 Collision time: 16:03 - 22:20 ! Start and end collision times Currents (mkA): Ie=1990, Ip= 730 ! beam currents at start time Peak luminosity: 3.5*10**28cm-2s-1 ! Max lumi, usually at start time ! (try to average over few min) Total lumi: 1.65*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.45*10**32cm-2 ! So called "effective" lumi H1 runs: 27057-27096 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) Peak Luminosity was achieved at 16:22 Luminosity at start time was near 5.0*10**27 Remark: Today was the last shift of members from our team (H1KMAL,H1KSHE and H1KFOM). The last two month of 1st H1 Data Taking Seance forever will be at our memories. Thanks to all for cooperation and sorry for may be not reasonable not nice words on the somebody's address. Really it was hard time but may be most happy at our lifes. 29.07.1992 ============== H1KSOL/H01USA === ep-collisions #45 ......... Date: 29/07/92 Collision time: 03:53 - 11.20 ! Start and end collision times Currents (mkA): Ie=2620, Ip= 930 ! beam currents at start time Peak luminosity: 4.5*10**28cm-2s-1 ! Max lumi, usually at start time ! Total lumi: 2.12*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.76*10**32cm-2 ! So called "effective" lumi H1 runs: 27098-27120 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) Peak Luminosity was achieved at 04:05 Luminosity at start time was near 1.8*10**28 29.07.1992 ============== H1KSOL/H01USA === ep-collisions #46.......... Date: 29/07/92 Collision time: 16.14 - 22.23 ! Start and end collision times Currents (mkA): Ie=3200, Ip= 540 ! beam currents at start time Peak luminosity: 3.5*10**28cm-2s-1 ! Max lumi, usually at start time ! Total lumi: 1.69*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.49*10**32cm-2 ! So called "effective" lumi H1 runs: 27134-27160 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) 30.07.1992 ============== H1KSOL/H01USA === ep-collisions #47.......... Date: 30/07/92 Collision time: 08.00 - 11.10 ! Start and end collision times Currents (mkA): Ie=1800, Ip=1100 ! beam currents at start time Peak luminosity: 3.4*10**28cm-2s-1 ! Max lumi, usually at start time ! Total lumi: 1.85*10**32cm-2 ! Integrated lumi H1 gated lumi: 1.43*10**32cm-2 ! So called "effective" lumi H1 runs: 27168-27181 ! Which runs were recorded Additional comments: 9 collided e-bunches (from #0 up to #8) 1 non-collided e-bunches (#19) 9 collided p-bunches (from #0 up to #8) 1 non-collided p-bunches (#9) max lumi - at 9:10 31.07.1992 ===================== H01USA === ep-collisions # 48 ........ DATE: 30/7/92 COLLISION TIME: 17.36 - 19:40 ! START AND END COLLISION TIMES CURRENTS (MKA): Ie= 3100 Ip=1480 ! BEAM CURRENTS AT START TIME PEAK LUMINOSITY: 8.0*10**28 ! MAX LUMI, USUALLY AT START TIME ! TOTAL LUMI: 2.65*10**31 ! INTEGRATED LUMI H1 GATED LUMI: 2.17*10**31 ! SO CALLED "EFFECTIVE" LUMI H1 RUNS: 27191-27205 ! WHICH RUNS WERE RECORDED 27190-27203 - from H1DATA (H1KSOL) Additional comments: it could be record run but at 17:43 Ip was lost from 1.48 to .35 mA... but Ie was still high - 2.93 mA. p-pilot bunch current was .15 mA so collided proton current - only 0.2 mA. After some tunning non expected high lumi was got - 1.2*10**28 and Lsp> 2*10**29. First time Belovincev didn't belive our measureme nts. We firstly had some doubts becouse CDAQ had permanantly some problems and was stopped => sometimes currents were not updated. But later we had confirmed this numbers and more later Belovincev has agreed and explained it by perfect conditions of beams. At 19:40 was power break in HERA so may be no protons during some day. At 20:13 the wave reached us: trailers crates were crashed. For our system it seems all is ok. We lost only data of TV pictures and reload fic programs. 31.07.1992 ===================== H01USA === HERA status on the Autumn.. To Members of Operations Meeting: Dear Colleague, after further discussions with the HERA machine people and within H1 the schedule for the machine and therefore also for H1 has become more clear. The weeks 34 and 35, 2. half of August, will be used to bring all preaccelerators and both HERA rings into operations. For a short time (on day perhaps) they will then reproduce present luminosities. The main plan then is to go into machine development for one or two weeks, depending on further discussions. For September/October/November the general agreement is that for the first half of this total period the emphasis will be on machine development to improve luminosity, but to alternate with luminosity runs for experiments on the basis of blocks of 1 to 2 weeks. For second half the emphasis will be on Luminosities, but sometimes the machine may also ask for some further development.The more detailed program will always be discussed at least one week in advance. On the basis of this it was agreed today, that our subdetectors should be brought into full operation only during week 36 and that full shifts should start on Friday September 4 (one week later than originally planned). Only the Lumisystem with CDAQ and CTRIG should be in operation earlier by one week with experts being on call. But CDAQ and CTRIG will most likely also be needed for tests on the new MWPC-DAQ and perhaps other developments as it had been foreseen already in our planning. Best regards, Friedhelm Brasse 01.08.1992 ===================== H01USA === ep-collisions # 49 ........ It was crazy day and night before when again were some main water pump break, after which the temperature went up and switching off the power of our trailer... Nevertheless in the morning Belovincev got both beams but H1 still had some problems and our subdetector also until mask resetting. But after this we had just the same situation as in evening 29 June run: - missed events with high energy electrons in the tagger (et-profile) - high effective thresholds in photon arm - 7 GeV ( energy DA), when 5 GeV thresholds was installed - low level rates: Rvwc=3kHz, Rtot=100Hz,Rbkg=40Hz and as the result low lumi: 3*10**27, Lsp=5*10**28 - high and expected lumi in Zeus ~ 1.2*10**28 - et-trigger rates were very high ~ 1.7 kHz (also zvtx triggers rates were very high, but they had problems with system and waited experts). We checked with Jury all settings and thresholds in first turn. It seemed as early. In besides bad et-profile we looked for approximately homogeneous distribution in all 120 channels (max=10000) of pd analogue sum. Longitudinal proton beam profile was very big -6.2 ns instead of 2 ns. Finally they killed proton beam and (!) situation with et-profile was not changed. As to pd analogue sum - it was changed: high statistic to the right of 55 hiso channels( factor 5-6). I visited HKR and try to find explanation for both cases. In old HKR logbook we find only one remark that it was "bad electron orbit" on 29 June. What does it mean nobody remembers. I promised pojalovat'sja Fomenko if they will write "so much" again. Using stored files on IBM we checked e-beam position in H1 IP for the last bad run. It was the same as in previous good runs. But they say that this last run they used new old lumi file which provided high lumi in Zeus (usually they have problem with Zeus lumi). But this file was overwritten and nobody checked it except this running result. So I think that this problem will disappear (as after 29 June) when new lumi file will be installed if only Egor not say something else. 01.08.1992 ===================== H01USA === 120 Mbytes disk ........... Yesterday new 120 MBytes disk was installed on the left Mac. Old one (80 MBytes) is kept and will be installed on the right Mac later instead of 40 MBytes disk. It took half hour and was done through SCSI port. In besides the position of video card was changed. Now second video card is installed in slot A, and TV videocard - in slot E (controversy to previous situation). Now Update events are not sent to TV screen when you close something - no problems. 01.08.1992 ===================== H01USA === Brasse visit .............. Thursday evening Brasse visited our subdetector to discuss situation about Autumn's shift. He proposed to our group to cover shifts in HKR mainly during tunings times and in H1CR - muon shift person must also be responsible for our subdetector. He also proposed to invite E.Sheviakov on 3 months starting from September for HW modification ( calibration prescaling of e-tag modules, delays tunings and so on) and for shifts improving. 02.08.1992 ===================== H1KSOL === H1 RUN is over ............ Today morning Kiesling (H1 Run Coordinator) announced that due to the big problems in HERA machine there is no sence to keep total shifts up to Monday morning,so July Run is finished. But,H1 CDAQ will be operate untill Monday and everybody who want to log some data with any subdetector can do it. Probably it would be interesting to calibrate our monitor with 26.6 GeV electrons,but I am not shure that it will be usefull due to the fact that single e-beam conditions seems to be different from colliding mode - we can try. On the other hand we can do it not earlier than at this night due to the problems with SC qavities in e-ring. 02.08.1992 ===================== H1KSOL === Lumi archive .............. Here below you can find correspondence of LOOK files and last LUMI RUNs: LOOK file LUMI RUN # H1KSOL.ALOOK.R27057 44 H1KSOL.ALOOK.R27098 45 H1KSOL.ALOOK.R27136 46 H1KSOL.ALOOK.R27168 47 H1KSOL.ALOOK.R27190 48 H1KSOL.ALOOK.R27297 49 04.08.1992 ===================== H01USA === last night ................ The last night HERA produced e-beam, 26 GeV starting from 4:09. The pressure was very bad because f.ex. for Ie=1.42 mA we had: Rtot = 5.81 kHz Rvwc = 50 kHz Rbkg = 5.2 kHz Rbkg_spec = 365 Hz. It was interesting because it simulates future high loadings. ET profile was practically as usual with two different features: - profile was slightly curved in bottom direction (usually - at top) - pure population in #21 ET module because of high HV and high rates, with the decreasing of rates the relative population in this module went to normal. ETPD plot was perfect with more homogeneous population as usual. On-line sum reconstr. spectra was perfect (=26.64 GeV) without low energy events.ET spectra had maximum at 15 GeV. The bunch rates were strange - while bunch currents were approximately equal, the rates of first 7 bunches were on the level of 10% in compare son to the last and pilot bunches. With the decreasing of total rates this level went up. Synchronisation was switched on to electrons. I was the last who leave this sheap suddenly very tired even DAQ person escaped in the beginner of night. The CR room was absolutely empty and looks very strange in comparison with the previous months. Yesterday on presentation meeting some warm words were told to all people who shared the "tjagoti" of this months i would like to put them in this logbook. 04.08.1992 ===================== F11LEV === Results to DALLAS ......... Before leave to the Dallas I would like very briefly summarize results which have been obtained during permanent "76-hours-offline-shift" doing analysis of the eTAG data (last time I tried such a working regime almost 20 years ago in the university, now it is more difficult: getting older...) These data have been reported at DESY (31/07 within H1, 3/08 on the common DESY seminar) and will be presented at DALLAS by F.Eisele. 1) Luminosity measurements: --------------------------- Total integrated lumi delivered by HERA to the H1: 5.0 nb-1 H1 gated luminosity (all recorded data): 3.1 nb-1 Good data used for the physics analysis: 1.5 nb-1 Final error estimate for the integrated luminosity: dL/L = 0.4% (stat) + 7.0% (syst) 2) Total gamma-p cross section: ------------------------------- On the full statistics using only good (*G) data, corresponding to the integrated luminosity 994 mkb-1 the total x-section was estimated for two different "models": a) no QCD jets at all: s_tot = 0.28s_diff + 0.72s_VDM b) 20% jet contribution: s_tot = 0.28s_diff+0.52s_VDM+0.20s_jet (a) 165 +- 28 mkb (b) 150 +- 22 mkb In fact errors obtained were approx on 30% smaller, but for "safety" EC decided to open them a bit. Errors include statistical errors, errors in the luminosity and systematical errors in the efficiency determination. Three different selections --> different event samples were used: ---------------------------------------------------------------- Sample L1 trigger Off-line selection Statistics ---------------------------------------------------------------- CALO bit0 (eTAG*t0) 1 good track in CJC cut y(JB) > 0.2 300 +- 20 BPC bit0 (eTAG*t0) 1 good track in CJC >= 1 hit in BPC 602 +- 61 ToF bit0 (eTAG*t0) 1 good track in CJC ToF-IA TDC info 428 +- 23 ---------------------------------------------------------------- 3) Comparizon with the ZEUS data: --------------------------------- After yesterday's open presentation at DESY, I tried to understand, why ZEUS data for the total cross section and for the gamma-p physics in general are so poor: in spite of they collected 2.5 nb-1 of useful lumi (compared to our 1.5 nb-1) they presented essentially nothing for the jets in gamma-p, and x-section with 30% errors (based on the 97 eTAG events, compared to our 600 events). And I think I have understood this! It seems that they have (at least now) only one branch in their LUMI system (!) such, that they could either measure luminosity and then cannot use e-tagger for the physics triggers, or use e-tagger for the physics, but then do not measure lumi at all Therefore, they used e-tagger for the total cross section only in few dedicated runs (7 hours) and - I am almost sure! - in this runs they did not measure lumi directly. This would explain their 15% error for the lumi compared to our 7% and 17% statistical error comrared to our 6%. Congratulations to all LPI members participated in the data taking and data analysis. 12.08.1992 ===================== H1KSOL === Dosimeters ................ Today 4 dosimeters are installed in tunnel area. They have numbers 1,2,3,4. Number 1 is installed on the face of E-tagger in front of element 21,i.e. near e-beam pipe. Number 2 is installed on the thin (1 mm) plastic strip in front of number 1. Number 3 is installed on the face of P-detector in the plane of e-beam and about 1 cm left from the center,i.e. where we usually observed the center of gamma beam. Number 4 is installed on the thin (1 mm) plastic strip in front of number 3 . So,numbers 1 and 3 will be moved with detectors in parking positions, while numbers 2 and 4 will stay always in the working positions. ________ _______ | | | | |* | | * | |________| |_______| E-tagger P-detector face face By pass,I measured once more time the geometrical position of E-tagger - the distance between e-beam pipe axe and center of E-tagger is 160 mm +- 0.5 mm. 17.08.1992 ================================ What was at Dallas ? ...... Maybe the LPI people that attended the Dallas Conference could say a few words via the Lumi-Log, just about Reaction on H1 and Zeus Reports, The Overall Impression from the Conference, and The Main News in Physics. It is difficult but could be usefull for the others. 17.08.1992 ===================== F11LEV === Dallas news................ For those people staying presently at DESY I can announce, that there will be a special seminar about Dallas conference. I was asked by Wagner to make an overview about all experimental topics (theory will be presented as well by another person), but fortunately enough I go to an official vacation just tomorrow, therefore I found an appropriate substitude: U.Goerlach will present experimental part from Dallas. For the Moscow part, I guess A.Lebedev could tell about his impression. There were also others from LPI at Dallas: S.Nikolsky, A.Komar, may be somebody else.