C 2/06/93 504271443 MEMBER NAME EDITFILE (CLIST) M *********************************************************************** * * * PART 11 PART 11 * * H1 LUMI LOGBOOK * * * * WINTER SHUT DOWN 1994/1995 * * * * * * Enter command LLC under NEWLIB in order to add new information * * Press PF3 button when finish your editting to save the file. * * If you don't yet have LLC command defined, copy it from the * * 'F11LEV.CLIST(LLC)' into your clist member 'userid.CLIST(LLC)' * * * * Use command: F ===== to find all messages, and then select * * those you are interested in * * * * The following commands allow to inspect earlier logbook parts: * * * * LL1 ........ list Part 1 of the Lumi Logbook: Jun'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 * * LL4 ........ list Part 4 of the Lumi Logbook: Jun'92 - Aug'92 * * LL5 ........ list Part 5 of the Lumi Logbook: Aug'92 - Nov'92 * * LL6 ........ list Part 6 of the Lumi Logbook: Nov'92 - Jun'93 * * LL7 ........ list Part 7 of the Lumi Logbook: Jun'93 - Nov'93 * * LL8 ........ list Part 8 of the Lumi Logbook: Nov'93 - May'94 * * LL9 ........ list Part 9 of the Lumi Logbook: May'94 - Jul'94 * * LL10........ list Part10 of the Lumi Logbook: Jul'94 - Nov'94 * * * * S.Levonian Opened: 03/11/94 at 16:40 * * Closed: 27/04/95 at 15:00 * * * *********************************************************************** 03.11.1994 ================= F11LEV === New Chapter of the logbook .. With this message a new part of the LUMI Logbook is openned. You can inspect earlier parts by the commands LL1-LL10, where LL10 = LIST 'F11LEV.H1.LUMI.LOGBOOK.PART10' Please don't forget to describe your activity during the shut down. It will later on allow for a faster problem finding and fixing and in general for somewhat easier life during the next -VERY DIFFICULT- year! The following people are especially asked/expected to report: 1) E.Malinovsky - progress in the preparation of the new e-tagger 2) I.Sheviakov - changes in the online system configuration 3) A.Fomenko - online s/w status 4) A.Usik - improvements in LUMI data distribution/presentation 5) V.Andreev - offline software for the new tagger (SIM/REC) 6) Yu.Soloviev - preparation of the lumi detectors to 1995 running Others are welcome to contribute as well. 04.11.1994 ================= F11LEV === Attendance of the H1 meetings Many LPI people often give the participation in H1 meetings as one of the reasons to stay at DESY. However, an attendance is very poor. At least to the main H1 meetings peolpe should go regularly. One of those is weekly Thursday meeting, specially designed for those who cannot, or don't want to participate in many other working meetings. Here general problems are discussed and summarized, both for online and offline people. Also basic physics topics without too much details are reviewed, such that everybody have a chance at least to know why and for which purpose he/she is working at H1. I bring this point here, because on the yesterday's meeting there were several items discussed directly related to LPI responsibility, and there were no LPI people (except myself) who has to answer many questions, and be aware of the problems, related to their work. For example: a) improvements in lumi data presentation, and better communications with the machine crew (G.Lopez, W.Bartel, others) was discussed without A.Usik b) review of the shutdown plans and some organizational items (no E.Malinovsky) c) summary on the luminosity analysis, comparing online and offline measurements without anybody from LUMI online d) photoproduction physics (no Ya.Vazdik), etc. Who of LPI members, presently at DESY, is interested at all on what is going on in H1 ??? Moreover, people are expected not just to learn, but also to REPORT on the progress in their areas (Sheviakov - online system upgrade, Usik - lumi data distribution and improvements in the online displays, Malinovsky - status of the new e-tagger!) 04.11.1994 ================= H1KMAL === Check of Dosimeters ......... During the access of 1.11 the dosimeters were picked up from the HERA-tunnel. They were irradiated over all Luminosity run. Results of check-up are the following ( Units - 10**2 Gy) for corresponding points (see LL8 from 16.3.94): 1) ->110, 2) ->150, 3) ->140, 4) -> 55, 5) -> 15, 6) -> 19, 7) ->220, 8) -> 40, 9) -> 60, 10) -> 5.5, 11) -> 45, 12) -> 3, 13) -> 11, 14) -> 13, 15) -> 13, 16) -> 4, 17) -> 3.3, 18) -> 8, 19) -> 3, 20) -> 8. Details see at pictures: --------------- For ET - tagger --------------------------------- ----------------------------------------------> e - beam # 2.2*10**4 Gy ______________________________________ |______________________________________| Lead Cover # 1.9*10**3 Gy 1.5*10**4 __________________________________ # # 1.1*10**4 Gy | not moved | | | | | ET - detector | | | 1.4*10**4 #_________________________________| # 5.5*10**3 Gy ______________________________________ |______________________________________|Lead Cover # 1.5*10**3 Gy ---------------------------------------------------------------------- ----------------------------- For PD - detector ------------------ 3.2*10**2 Gy #________________ | | Not moved | | | | ---- Gamma-beam---> # # 8*10**2 Gy |PD - Detector 8*10**2 | | | | #________________| 3.0*10**2 Gy ---------------------------------------------------------------------- ---------------------------- For VETO-counter -------------------- # 4*10**2 Gy _______________________________________ Lead Cover |_______________________________________| . |# 5.5*10**2 1.3*10**3 Gy # . | . | . | . | # 6*10**3 Gy | | | Gamma-beam ----> | |# 4.5*10**3 | | # 4*10**3 Gy | . | . | . | 1.1*10**3 Gy # . | . |# 3.0*10**2 ________________________________________ Lead Cover |_______________________________________| # 1.3*10**3 Gy 04.11.1994 ================= F11LEV === ET working position for 1995 I suggest to realize in 1995 an old proposal of A.Usik and to install e-tagger asymmetrically, in order to have better overall calibration and less loading for the central layer. This will also allow to use if necessary, some channels from the bottom raw for the new e-tagger at 44m. +---------------------------+ | | | | | | | | |---|---|---|---|---|---|---| | | | | | | | | |---|---|---|---|---|---|---| | | | | | | | | + |---|---|---|---|---|---|---| -----> HERA median plane e-beam | | | | | | | | |---|---|---|---|---|---|---| | | | | | | | | |---|---|---|---|---|---|---| | | | | | | | | |---|---|---|---|---|---|---| | | o | o | x | x | x | x | +---------------------------+ Electronics (not crystals of course) from the channels labelled by "x"("o") can be used for the new 4(6)-channel e-tagger. 09.11.1994 ===== dice2 ===== H1KFOM === Selected H1Lumi Monitrig .... Today it were selected calibration data samples from the next data sets which were produced with standard job prepared by S.Levonyan at dice1-environment: HERA03.H01.LUMIMON.C9400130 L02870 78048081 00002 ACS-E-C ...... HERA03.H01.LUMIMON.C9400133 L13004 78048081 00007 ACS-E-C It were selected events with (s92=1 only),with ET&PD&VC=1 and with ET&PD&nVC from these data sets (as ordinary): 1) S92=1 only 14088 events ( 22.2 MBytes) 2) ET&PD&VC 31925 events ( 53.2 MBytes) 3) ET&PD&nVC 22921 events ( 38.2 MBytes) Created data sets were saved at DESY IBM storage at the next data sets H1KFOM.ETPDNVC.M130133.C00 K11216 78048081 00001 ACS-E-C H1KFOM.ETPDVC.M130133.C00 K11372 78048081 00001 ACS-E-C H1KFOM.S92.M130133.C00 K21596 78048081 00001 ACS-E-C These data include events from Lumi RUNs# 652-664 (H1 Runs 89877- 90236). 14.11.1994 ================= H1KFOM === Runs with Lumi Branch Only .. Today I found that at 11 November it were written some H1 Runs (from 90791 up to 90804, from 12:38:18 11/11/94 up to 15:26:23 11/11/94) with Luminosity Branch and H1CTRIG only involved into H1CDAQ. Data were written on permanent cartridge HERA04.H1RAWD.C9405107. Can anybody explain what was the reason of this data collection and which were sources of L2Keep-events (Random or something else). Some LUMIMON-data sets were produced with H1Runs from 90778 up to 90863. Early mentioned H1 Runs (90791-90804) only part of more wide H1Runs set with Lumi Branch (90778-90863). There are 10 new LUMIMON-data sets (138-148) with data from H1Runs 90778-90863. Most of H1 Runs which were written at 11 November were collected on temporary data sets (from 10:19:07 up to 12:38:18 and from 15:26:23 up to 18:32:51) with e-beam 27.555 (Ie from 22.2mA up to 14.9mA and with s95,s94 and s86 sources of L2Keep together with Random source) and with e-beam 12 GeV (Ie from 11.0 up to 13.9 mA). 138th LUMIMON-data set is last data set with "useful" data from H1DataTaking94 (H1Runs 90408-90781) due to Lumi RUN# 671 was finished with H1 Run 90420. 14.11.1994 ===== dice2 ===== H1KFOM === Selected H1Lumi Monitrig .... Today it were selected calibration data samples from the next data sets which were produced with standard job prepared by S.Levonyan at dice1-environment: HERA03.H01.LUMIMON.C9400134 L13004 78048081 00003 ACS-E-C ...... HERA03.H01.LUMIMON.C9400138 K32735 78048081 00001 ACS-E-C It were selected events with (s92=1 only),with ET&PD&VC=1 and with ET&PD&nVC from these data sets (as ordinary): 1) S92=1 only 20945 events ( 33.2 MBytes) 2) ET&PD&VC 60223 events ( 96.7 MBytes) 3) ET&PD&nVC 37473 events ( 62.1 MBytes) Created data sets were saved at DESY IBM storage at the next data sets H1KFOM.ETPDNVC.M134138.C00 K23795 78048081 00001 ACS-E-C H1KFOM.ETPDVC.M134138.C00 K21957 78048081 00001 ACS-E-C H1KFOM.S92.M134138.C00 K27375 78048081 00001 ACS-E-C These data include events from Lumi RUNs# 664-671 etc. (H1 Runs 90236- 90419 etc. up to 90781). 14.11.1994 ================= F11LEV === LUMI in two-FIC mode ?....... Concerning Fomenko's question, I believe, these dedicated lumi data were taken to test new multi(2)-processor scheme. I asked Igor to briefly describe what has been done in the logbook, but as usual - it comes too late. May be it nevertheless will appear soon? 15.11.1994 ================= F11LEV === New LPI note from H1KMAL .... A new LPI note 03-94 was prepared by E.I.Malinovskii. It contains a status of the work on the new ET at z=44m and other activities in the tunnel. There is a postscript file on IBM: H1KMAL.TAG44.PS 16.11.1994 ================= H1KSHE === Some test results ........... I am sorry for delay, but writing takes too much time from me & 1 Main results of new processor cofiguration tests. The problem of two processors Luminosity branch readout now is more less clear. First tests looks rather successfull. The FER response time has reduced by factor two and now it is lies very closely to H1 design value 0.8 ms. The system is running stable, at least no any crashes both for local mode and together with CTRIG/CDAQ running during last days. The banks format seems also to be ok, no difference between event sizes, L4 histos was found for old and new online software versions. The max. data logging rate has been increased on 50% and now it is 150 Hz (100 Hz before). The double factor for data loging still is not yet reached due to not optimal task dividing between two processors, but this is first release only. From the other hand i see now many things in my part of current software that can be considerable improved. And of course very careful check especialy data validity for different running conditions is need. This hard work on optimasing software will be continued or started on some new base by Sahsa Fomenko of course, at Jun.- Mar 95. Finaly i give here something like a current status-info in this field if you are iterested. &2 CURRENT STATUS - INFO. Contents: 1/ VME bus traffic tests 2/ Current two processor Software philosophy. 3/ Tests with CDAQ 4/ Other tasks of the system improving 1/ VME bus traffic tests An optimal arbitery aliement was found for current processor set. Unfortunatly MacVEE(Macintosh interface) seems to me has too simplified arbitration philosophy (it was designed may be 10-15 yeas ago) and sometimes doing wrong response if more priorities masters perform hard VME bus activity. So i was forced to give them as high priority as possible that is not correspond to the importance of them in the system. When it was made the data logging max. rate goes down from 154 Hz to 147 Hz. In contrast to MacVEE the FICs have no any arbitration problem for any VME bus trafic. For finale configuration (five processors in total 2*Mac + 3*FIC) i am especially organize an extremily hard VME traffic and NO ONE bus error for several hours running was detected. I have special asking to all who writes Macintosh applications, please is not use the BlockMove data exchange with VME at all to not produce the bus problems to anybody and itself. 2/ Current two processor Software philosophy. Features: a.Implementation is very easy (is not complicated then the current text) b.If the slave processor is casualy becomes dead then nothing crashed just the processing goes slower. (this is realy working!) Current two processor S/W philosophy is based on master-slave communication protocol. Synchronisation of the event processing are perfomed on the two level base. First level is provided by interruption which master processor are produce for slave processor. The second level synchronisation is based on flags that master and slave are seted to each other in it's own local memories. This solution is enable to avoid any flag monitoring loops in the VME bus that of course is good for total VME bus traffic conditions. Basic communication protocol idea is the following: Before to delegate any processing task to the slave processor the master is asking them: are you alive(ready) or not. For positive answer the task is delegated and waited for it completion for some reasonable time, if not the task is processed by the master itself. Of course for master there is no a simple waiting for competion of the slave task, the processing of master's tasks are not interrupted by waitig loops everywhere is possible. Some monitoring scalers are distributed in the both processor programms and corresponding Macintosh application for visual control of the main time critical routines are applyed. 3/ Tests with CDAQ Some H1 runs together with CTRIG/CDAQ standard operation were recorded, but last(may be not yet last) errors in banks contens were removed since run# 90860. Before this run trigger energy sums had not correct value due to wrong FADC memory ofset setting. Part of these runs were recorded with basic 94 version to be compare with new one. For instance: Run# 90800 - two processor version (wrong LRTF,LRTN) Run# 90801 - basic 94 version Run# 90860 - two processor version Run# 90861 - basic 94 version 4/ Other tasks of the system improving: a. Due to permanent complication of the system the more careful real time control is need. Our status-control display seems to be improved for the DAQ at least. It was often complain from shift person like a "I can't uderstand the reboot of the processors is finished? ..is it ok or not? ..where i can see it?". Another bad feature of this may be just not enouth evident status displaing that the shifter makes the reboot both FICs without any reason. As a sequence we have at least 1/2 min. out of lumi measurements in this case. It seems to me the DAQ control panel should consist of some big size buttons and big size message window with uderstandable text or something like that. Half of this work is doene allready. If such application will be involved we will have additional advantage to not ocupay 2.5 Mbyte memory for MPW shell. b. As show expierence we were never satisfied by the Macintosh hard disc memory size. 40 Mb disc was always full, 80 Mb disc was always full, 120/80 Mb discs now are full such as link pro- cessing is crashed. The new extra 1Gbyte disc is ordered all- ready, but for long time trigger rates (not from our system only) history. I am sure that this "volume" will be full in several days, but several days are also not so bad. As concern rate history there were multiple requests all time to show what was happened with some rates many days or weeks ago. Of cource some infomation is available in offline, but for not all rates and not fast accessible. Probaly the relevant application for handling and storing more then 50 trigg. rates will also overlap the previously mentioned task. 17.11.1994 ================= F11LEV === HV for the new taggers ...... I got an information from Zuerich, that HV supplies for new e-taggers (full system in final configuration) are ordered and will be delivered to DESY in 3-rd week of January. Those who will be at that time at DESY must take care on this equipment. 24.11.1994 ===== dice2 ===== H1KFOM === Relation Coeff.Set 10C....... Today it was made attempt to produce Rel.Coeff.Set for 10C (low p11) data sample (from H1 Run 89877 up to Run 90420).It were selected 56644 ET&PD&nVC events from this H1 Run range from data set (only G- and M- labeled H1 Runs at H1EP): H1KFOM.ETPDNVC.M130133.C00 K11216 78048081 00001 ACS-E-C H1KFOM.ETPDNVC.M134138.C00 K23795 78048081 00001 ACS-E-C After all high mentioned 'cleaning' of 10C(low p11)data samples it were collected: 56644 events with ET&PD&nVC trigger 78138 events with ET&PD&VC trigger 33278 events with S92-trigger (PD&nVC-events). It were got 56644 ET&PD&nVC from these Runs and it were used for calibration 25099 events (after all cuts). Final Relation Coefficient Set is the next: ==> Relation Coeff.Set for ET 0.000 1.017 0.849 0.978 0.818 0.998 0.830 0.950 1.004 0.982 1.160 1.210 1.010 1.044 0.986 0.919 0.917 0.997 1.027 0.952 0.969 1.040 1.035 1.020 1.013 1.026 0.989 0.993 1.096 0.984 0.985 0.958 1.071 1.017 1.027 1.002 0.909 1.058 0.890 0.879 0.957 0.924 0.934 0.867 0.972 0.506 0.864 0.946 0.000 ==> Relation Coeff.Set for PD 1.402 1.024 1.012 1.366 1.331 1.017 1.013 1.019 1.040 0.957 0.955 1.015 1.003 0.996 1.048 1.039 0.992 0.978 0.962 0.982 1.162 0.940 0.960 1.264 0.000 ==> Sig. at Relation Coeff.Set for ET 0.000 0.006 0.011 0.012 0.003 0.021 0.005 0.000 0.027 0.020 0.014 0.010 0.009 0.010 0.052 0.028 0.020 0.017 0.019 0.008 0.037 0.016 0.023 0.015 0.021 0.022 0.017 0.013 0.017 0.018 0.010 0.012 0.013 0.013 0.007 0.002 0.050 0.034 0.018 0.013 0.002 0.005 0.000 0.015 0.005 0.009 0.005 0.000 0.000 ==> Sig. at Relation Coeff.Set for PD 0.027 0.010 0.014 0.002 0.000 0.012 0.014 0.028 0.037 0.006 0.015 0.020 0.017 0.044 0.033 0.018 0.021 0.024 0.022 0.050 0.033 0.016 0.025 0.079 0.000 ==> Ent. at Relation Coeff.Set for ET 0 16 2 4 15 7 4 3 18 33 25 53 14 16 746 281 199 265 171 430 84 6353 10420 8792 7095 5917 4603 1937 2331 2702 2979 2596 2813 2170 1074 18 4 17 13 5 6 6 1 2 2 3 3 1 0 ==> Ent. at Relation Coeff.Set for PD 27 19 12 12 1 352 2571 2944 542 29 6703 19907 15802 3051 102 2724 8680 3940 453 15 23 25 17 7 0 As You can see all sigma values for 'hot' H1Lumi cahnnels RC histos have more ore less reasonable values. Runs 89877-90420 (ET&PD&nVC-sample - near 56.0K events) all events xetcut xetcut&vcdepcut Step Mean Sigma Mean Sigma Mean Sigma 3 27.37 1.05 27.35 1.01 27.41 1.01 Runs 89877-90420 (ET&PD&VC-sample - near 78.0K events) all events xetcut Step Mean Sigma Mean Sigma 3 27.59 1.43 27.79 1.39 As start values of Calibration Coefficients for Photoproduction Branch were got ones after 3rd step of calibration with ET&PD&nVC events from 10B-sample (H1 Runs 89264-89877 - near 53.0 K events). CCvcs value was got from last VCs calibration at 10B-sample of ETPDVC events (H1Runs 89264-89877 - see message from 27.10.94 at LL10). (CCvcs start = 4.167 MeV/FADCcount). Attempt to make fit of PhotonArm Energy spectrum was enough succesful (with enough good statistics). 24.11.1994 ===== dice2 ===== H1KFOM === PDREC-spectra for 10C........ Today it were produced 100th ntuple for S92=1 events from earlier mentioned 10C-sample with events from Runs 89877-90420: H1KFOM.YLOOKQ4.R89877 (27494 entries) FAST08 3010200E 00000 DASD At interactive LOOK-session it was produced 70th histo for this data set and written into the next LOOK-binary data set: H1KFOM.BLOOKQ2.R89877 17414 entries in 70h FAST04 3010200E 00000 DASD First attempt to fit 70th histo at BLOOKQ2-data set put negative sign of Global Energy Shift at Photon Arm (-1.9%) and a little better then at 10B sample resolution digits (16-17%) for (14-20)-35GeV regions. It were prepared 100th tuples with ET&PD&nVC and ET&PD&VC-events for procedure of defining Global Energy Shifts and CCvcs: H1KFOM.YLOOKQ2.R89877 56065 entries FAST01 3010200E 00000 DASD H1KFOM.YLOOKQ3.R89877 72452 entries FAST04 3010200E 00000 DASD 24.11.1994 ================= H1KFOM === Global Shifts,CCvcs 10C...... It was estimated (preliminary) that Global Shifts for both H1Lumi arms are: 1.019 for PD Channels (exept VCs), 0.991 for ET channels. Correction factor for CCvcs is 0.9351.So CCvcs = 4.167*0.9351=3.897Mev FADCcount. These digits are valid for H1Lumi events from Run 89877 up to 90420 Runs 89877- 90420 (ET&PD&nVC-sample - near 56.6K events) xetcut&vcdepcut Step Mean Sigma 0 27.52 1.02 Runs 89877- 90420 (ET&PD&VC-sample - near 78.0K events) xetcut Step Mean Sigma 0 27.54 1.34 P.S. CCp11 became more then 5 MeV/FADCcount. CCe19 came back to less then 10 MeV/FADCcount value gain. CCvcs(averaging) was decremented on 6.5%. For any case - this is the final values of CC at Photoproduction branch after 3rd step of calibration with 10C-data sample (H1 Runs 89877-90420): ==> ET Calibr.Coefficients Final Status e00= 4.139 4.614 4.199 3.408 4.066 2.998 3.335 4.413 3.877 4.112 2.111 5.921 3.991 3.990 5.717 2.683 4.198 5.134 4.349 9.938 4.481 7.343 5.015 5.853 4.900 4.318 4.922 4.236 4.676 5.155 4.648 3.971 5.368 4.985 3.155 4.515 4.674 3.467 3.473 4.566 4.335 4.039 e42= 4.094 3.872 4.318 1.949 3.722 4.147 4.018 ==> PD & VC Calibr.Coefficients Final Status p00= 2.090 1.495 1.362 2.385 2.579 1.303 2.671 3.040 2.336 1.665 2.279 5.058 3.042 3.038 2.157 2.293 2.082 2.735 2.984 2.446 p20= 1.289 1.550 2.042 3.137 2.549 vcs= 3.897 28.11.1994 ================= H1KFOM === New RC Sets in H1DataBase.... As final action of all 24.11.94 calibration steps it was made update of LFRC and LESC banks at H1DataBase with S.Levonyan's tool. All Relation Coefficients values, CCvcs and Global Energy Shift constants were got from the next messages at LLO: 24.11.1994 ----- dice2 -------- H1KFOM --- Relation Coeff.Set 10C 24.11.1994 -------------------- H1KFOM --- Global Shifts,CCvcs 10C Bank-ID Rtyp Dtyp Version 1.Run L.Run Words Date Author Bank LFRC (_501) 49 e-p data 411280738 89877 0 77 941128 H1KFOM Bank-ID Rtyp Dtyp Version 1.Run L.Run Words Date Author Bank LESC (_582) 57 e-p data 411280738 89877 0 3 941128 H1KFOM 28.11.1994 ================= H01GOG === FToF data collection ........ All H1TCL files were reprocesses once again with a short job, which selects FToF data from them. The purpose of this job was to collect all available information on the proton bunch structure, to be used in further corrections of luminosity on the effect of satellite p-bunches. The job finds all BRTQ banks (do: lhb BRTQ to see format of this bank) which contains so called "qvt" histogram from the Forward ToF, and converts them to the corresponding LOOK histograms. For the details on the FToF hardware and functioning during 1994 data taking, I refer to several presentations by P.Biddulph on Thursday's H1 meetengs (copies of his transparencies should be available in the documentation room at DESY: 1b-138) Input: HERA03.H1TCL.C94xxxxx files (BRTQ banks) Output: H01GOG.BLOOK.Cxx (xx = 20...104) (LOOK histograms) LOOK histograms were created with the following parameters: CALL BHSW (10000+IFG,0,500,0.,100.) CALL BHSW (12000+IFG,0,500,0.,100.) CALL BHSW ( IFG,0,250,30.,80.) where IFG = Lumi RUN # (from 399 to 671) This means, that histograms of 10000+IFG and 12000+IFG families contain complete FToF data (100 ns in x-axis), while histograms of IFG family - only a central part around the main bunch (30-80 ns). 28.11.1994 ================= H01GOG === ELAN-94 mdst processing...... On request of S.Levonian, I also processed ELAN mini-dst by a job which selects few interesting for LUMI analysis quantities and stores them in n-tuple of the following format: NAM(1) = 'RUN' ! Run number NAM(2) = 'EVENT' ! Event number NAM(3) = 'BTYPE' ! Bunch type (-1...3, see func. JBUNCH in H1UTIL) NAM(4) = 'TEL1' ! Lumi bits from TEL1 bank (bits 112-119) NAM(5) = 'EP' ! Reconstructed photon energy (from LPDR bank) NAM(6) = 'EE' ! Reconstructed electron energy (from LETR bank) NAM(7) = 'ZV' ! z-vertex position in H1 (from "new" CTKV bank) NAM(8) = 'ZVV' ! z-vertex position in H1 (from "old" KVER bank NAM(9) = 'VTYPE' ! vertex type = 10*KVER(9)+CTKV(9) Purpose of the job: 1) to provide fully unbiased sample for the determination of trigger efficiencies for various LUMI trigger elements 2) to get z-vertex distribution for satellite bunch correction estimate (by the same method, as it was used in 1993) o input: H1KUWE.H1LOWQ2.MDSTxxx o output look-files: H01GOG.XLOOK.ELAN94.Exx -> e-p .Pxx -> e+p .Z00 -> shifted vertex Summary: ------------------------------------------------------------------ Data sample Input files (xxx) LOOK files # of events ------------------------------------------------------------------ e-p 61-131 E01-E02 74244 e+p 132-589,617-664 P01-P09 661172 shifted vertex 604-615 Z00 26614 ------------------------------------------------------------------ Note, that there might be some missing parts in these files! Reasons: a) few input cartridges on IBM were missing b) some of the jobs finished by the time limit and thus part of the last file in such a job was not processed. P.S. (S.Lev): ------------- ELAN mini-dst contains low Q^2 deep inelastic events, triggered by BEMC energy cluster condition (s0 in TLV1 bank notation). Therefore, these events are completely independent of LUMI system. Any LUMI information in these events originates either from random overlap between deep inelastic(DIS) event in H1 and something in LUMI, or from radiative DIS events which have photons hitting our PD. As a result one can use this ELAN event sample to a) determine trigger efficiency of ET, PD and VC bits in absolutely unbiased way (cf. with our standard methods from LUMIMON events, which in some cases may be biased. Say, if we define PD-eff from VC-sample, we have to remember, that E(VC) enters also to E(PD) in the trigger) b) determine a probability of appearing lumi events per one bunch and compare with the expected probability (from the value of luminosity). This even can be used for another cross check of our luminosity measurements (see H1 note 06/94-366 by L.Favart) c) and of course, to estimate fraction of lumi from early satellite p-bunch (these events must give vertex around z=70-75cm). 02.12.1994 ================= F11LEV === Final offline Lumi-94 ....... The analysis of Lumi-94 data is finished. Results were reported on H1 meeting yesterday, Dec. 1st. Copies of my transparencies are available on usual place in H1 doc.room. This is THE FIRST complete analysis of 1994 data in H1 ! -------------------------------------------------------- Such a success (also a high final precision achieved) was only possible because of much better organization of the LUMI data taking and analysis this year. Special thanks goes to: Igor Sheviakov - for excellent job in the online trigger area, Sasha Fomenko - for the calibration of LUMI detectors, Nelly Gogitidze - for complete processing of LUMI monitoring events. Some conclusions are given below. 1) The overall corrections to the online lumi values are significant. (+9.1% for e-p data and -8.1% for e+p data) In total the correction factors for 16 run ranges were calculated and will go to the data base (new bank LOFF is proposed for that). 2) The final precision of LUMI(94) is very high (cf. 92/93 periods): ----------------------------------------------------------------- 1992 1993 1994 e-p e+p shift.IP ----------------------------------------------------------------- Syst.error from lumi system 6.6% 3.4% 2.0% 1.4% 3.8% Satellite bunch correction 2.0% 3.0% 1.3% 1.1% 1.0% Overall sys.err. for physics 7.0% 4.5% 2.4% 1.8% 4.0% ----------------------------------------------------------------- 3) Sufficient statistics of LUMIMON events is vital !! This is a key for the high precision measurements. All LUMI monitor triggers are necessary, but especially important are the following triggers/samples: s91 - basic sample for offline lumi corrections s94,s95 - basic samples for offline calibration A bad example is so called "shifted vertex" data sample, where insufficient amount of s91 events limited Lumi precision to ~4%. 02.12.1994 ================= F11LEV === LOFF - new Lumi bank in DB... A new bank has been created in order to maintain offline luminosity corrections. The bank format is given below. A full set of LOFF banks containing the correction factors for all H1 run ranges was stored in the database (see summary table at the end of the message). Now LUMI tool in H1UTIL must be updated to account for offline correc- tions. This will be done in the next days. ! BANKname BANKtype ! Comments ! TABLE LOFF ! Lumi offline correction factor ! ! ATTributes: ! ----------- !COL ATT-name FMT Min Max ! Comments ! 1 METHOD I 0 +INF ! Method used for the offline correction: ! 1 - e-gamma coincidence ! 2 - gamma-rate ! 3 - Compton events ! 4 - Random coincidence ! ... others? 2 FACTOR F 0. 2. ! Factor to be applied to the online L: ! L_corrected = L(LH1R/LH1T)*FACTOR END TABLE Bank LOFF (_693) Bank-ID Rtyp Dtyp Version 1.Run L.Run Words Date FACTOR ----------------------------------------------------------------------- 2 e-p data 412021613 1 76845 4 941202 1.000 e-p ------------------------------------------------------------------- 20 e-p data 412021625 76846 77991 4 941202 1.007 21 e-p data 412021625 77992 79912 4 941202 1.069 22 e-p data 412021625 79913 81023 4 941202 1.103 23 e-p data 412021625 81024 82005 4 941202 1.144 break------------------------------------------------------------------ 24 e-p data 412021625 82006 82960 4 941202 1.000 e+p ------------------------------------------------------------------- 25 e-p data 412021625 82961 84045 4 941202 0.945 26 e-p data 412021625 84046 85111 4 941202 0.885 27 e-p data 412021625 85112 86096 4 941202 0.908 28 e-p data 412021625 86097 86944 4 941202 0.952 29 e-p data 412021625 86945 87577 4 941202 0.911 30 e-p data 412021625 87578 88215 4 941202 0.919 31 e-p data 412021625 88216 88864 4 941202 0.883 32 e-p data 412021625 88865 89227 4 941202 0.934 33 e-p data 412021625 89228 89928 4 941202 0.927 34 e-p data 412021625 89929 90026 4 941202 0.986 35 e-p data 412021625 90027 90305 4 941202 0.880 36 e-p data 412021625 90306 90419 4 941202 0.965 break------------------------------------------------------------------ 37 e-p data 412021625 90420 0 4 941202 1.000 ----------------------------------------------------------------------- 03.12.1994 ================= F11LEV === LUMI tools in H1UTIL ........ Basic low level LUMI tools in H1UTIL have been updated to account for the offline corrections, explained in the previous messages. For old routines there are NO CHANGES visible to the users. Calling sequences remain the same. One new subroutine was added (RLUMIV). The complete set of subroutines/functions is thus increased to 5: INTEGER FUNCTION IQRH1 (IRUN) INTEGER FUNCTION JBUNCH(IRUN,IBUNCH) SUBROUTINE GETH1L (IRUN,TOTL,H1L,RTIME,REFF,IRET) SUBROUTINE RLUMIV (IRUN,RLUMI,METHOD,NVEC) SUBROUTINE EPBEAM (IRUN,PTC,PPC,ETC,EPC,IBT,IRET) An H1 note describing LUMI data (banks) and offline tools is being prepared. Higher lever LUMI tools (e.g. corrections for HV status, or satellite bunch corrections) still have to be updated/developped. P.S. I updated H1UTIL (cmz and load library) only on IBM. Corresponding corrections in the master library on dice will be done by H1UTIL librarian, whom I sent the correction cradle. 05.12.1994 ================= H1KFOM === s92 is basic sample too ..... I propose to include s92-LUMI monitor trigger as one of basic triggers/samples for off-line calibration (good sample - may be single sample for today - for LESC-bank contents defining). As You remember s92=PD*nVC and it was good sample for PD-Arm energy spectrum global shift defining (if You have not any information about CCvcs). ET-Arm energy spectrum global shift is defined from ET&PD&nVC events ntuple analyze (if You have PD-Arm Global Energy Shift) and CCvcs is defined from ET&PD&VC events ntuple analyze (if You have both PD- and ET-Arm Global Energy Shifts). But we must remember that sample s92 consists of only from near 10% of all PD-Arm events due to excluding of PD-Arm events with VC=1. There are some conclusions from this fact (double photon events are more rare as at all PD-arm events for example). So - I propose to make the next editing of S.Levonian's message from 02.12.94: ".... All LUMI monitor triggers are necessary, but especially important are the following triggers/samples: s91 - basic sample for offline lumi corrections s92,s94,s95 - basic samples for offline calibration ...." Really during selection of ET&PD&nVC and ET&PD&VC events from LUMIMON data sets it were used not only s94 and s95 triggered events. There are ET&PD&nVC events at s92-sample and at s91-sample and at non-LUMI Monitrig events. There are ET&PD&VC-events at s93-sample and at s91-sample and at non-LUMI Monitrig events (see my message at at LL9 from 11.07.94 "Calibration Data Samples" for example). PD&nVC events were got only(!) from s92-triggered events. 05.12.1994 ================= F11LEV === About s92 events ............ I expected, that Fomenko will complain, in spite of I stressed that ALL lumi monitors are important. However, since the question was raised anyway, I want to make another small remark. I must admit, that I don't like s92 sample by one reason: it is very difficult to predict HOW the shape of the photon spectrum may change by the requirement !VC. It WAS observed in 1993 in many cases (also by studies of rad.corr.group), that the shape becomes different from the total gamma-spectrum. And this is also difficult to simulate in all details. It is not a trivial change due to better resolution in case of !VC condition. Sometimes the shape is different even down to 8-12 GeV. So, I agree (as I told to Fomenko), that s92 events are useful at least to study the effect of double photons (in comparison with e.g. s91 sample), but the use of these events for PD-shape fitting might be dangerous. At least, for the final off-line luminosity corrections we used full s91 spectra and re-fitted them to obtain E_gamma scale. I do not propose to remove any of presently existing lumi monitrigs in 1995. But what is needed, is to estimate (and give a quantitative arguments) what is the necessary amount of all LUMIMON events. Especially remembering, that the luminosity will increase by a factor of 2-3. So far I did this only for s91 and s93 samples. 20.12.1994 ================= F11LEV === Anti-magnetic shielding ..... The strength of stray field from the p-quadrupole at the expected position of new e-tagger (44m) was kindly provided by Uwe Schneekloth. The actual values depend somewhat on the optics and vary between 5 and 25 Gauss. A copy of the measurements I will bring to Moscow. This field should be taken into account for the PM shielding. 31.12.1994 ================= H1LUMI === Happy New Year .............. Happy New 1995 Year to all H1Lumi Community. 05.01.1995 ===== OnLine ==== H1KFOM === H1Lumi MacII HD Crash (?!)... Yesterday immediately after my and E.Malinovskii's arrival to DESY it was phone call from Sergey Burov with bad news - our H1Lumi MacII HD is damaged and it is needed to make something for involving of H1Lumi MacII into Standard Operation. I found at H1Lumi MacII paper from E.Wunsch: "Disk is damaged. 29.12.94. E.Wunsch. Tel. 2848". After some attempts to boot System from diskette "System 6.0.5" it was found that HD_LPI at H1Lumi MacII is seen by System. It was possible to look for file catalog. But all attempts to make copy of some files (for keeping as BackUp files for future recovering of HD_LPI) put the same results - only 20-30% of needed useful files were copied on discettes (Read Error at HD_LPI). Only old experience with H1Lumi2 MacII HD_LPI crash at last year helped to boot System from HD_LPI. It was made disconnection of Power Supply from H1Lumi MacII (at Shut Down status of H1Lumi MacII) and made back power connection. After this 'procedure' H1Lumi MacII HD alived and System was booted from HD_LPI after pushing of Switch On Button. It were made BackUp procedure of all needed files (last Usik's applications, Egor's TwinFIC-developments and last releases of Programs for FICs - which were kept at H1Lumi MacII hard disc) on 11 high density discettes. E.Wunsch made BackUp copies of full contents of HD_LPI at both H1Lumi and H1Lumi2 MacIIs with using of DAT Driver on Digital Data Cartridges (DAT - Digital Audio Tape) - SONY product. E.Wunsch promised that soon DAT Drivers will be available for often using and some program at MacII will ask to make BackUp-procedure once per week or month or what You want. Program for BackUp procedure is named Retrospect. There are some 'tracks' of their activity - file with History of BackUp-procedure activity at each hard disc. 4 mm Data Cartridges will be kept by H1Lumi team (at future 2nd copy will be kept anywhere else). Contents of H1Lumi2 MacII HD_LPI is kept at MAXELL Data Cartridge with label "LUMI_01 5.1.95". Contents of H1Lumi MacII HD_LPI is kept at MAXELL Data Cartridge with label "H1Lumi1_01 5.1.95". Let's hope that all is OK now with HD_LPI at H1Lumi MacII and it will be not so large problem to 'recover' HD_LPI-contents at both H1Lumi and H1Lumi2 MacII at case of some problems with hard discs P.S. Information for any case: Price of DAT Driver is 2600 DM. Capacity of HS-4/90s data cartridge 14 GBytes and its price is 20 DM. 05.01.1995 ===== OnLine ==== H1KFOM === Bill Haynes's Proposal ...... Bill Haynes issued proposal to change H1 CDAQ Branches Structure: It was happened 07.10.1994 and now is realized. First steps are made by Sergey Burov. Now structure of H1 DAQ Branches is the next: 1. Central Trigger 2. Calorimeter Trigger 3. Calorimeter ADC 4. Central Tracker 5. Forward Tracker 6. Forward Muon 7. MWPC 8. Muon 9. Lumi 10. Forward Muon Trigger. 11. Subsystems..Electronics Chariots..R-0,z-vtz, etc. 12. Silicon (Haynes) 14. Backward Drift Chamber (Tutas) It was proposed to make next changing: 1. Central Trigger 2. Calorimeter Trigger 3. Calorimeter ADC (inc. SPACAL) 4. Central Tracker 5. Forward Tracker 6. Forward Muon 7. MWPC 8. Muon 9. BDC (Tutas) 10. Subsystems..Room 101..F muon Trigger, FPS(Kotelnikov),Lumi 11. Subsystems..Electronics Chariots..R-0,z-vtz, etc. 12. Silicon (Haynes) As You can see Luminosity branch will be not independent branch as earlier but it will be included into 10th branch together with Forward Muon Trigger and Forward Proton Spectrometer. It means that VMExi2 module will be removed from H1Lumi Master crate and will be changed on VIC. Previous so-called 1 Mbyte Bill's memory will be used by H1Lumi for internal needs. Internal VIC's memory will be used for retranslation Lumi-subbranch data to H1 Event Builder with the same VMExi-protocol. Some absolute addresses will be changed at H1Lumi OnLine SW. Forward Muon Trigger online team made all needed changing at their OnLine SW and now this subbranch is tested inside 10th branch. Sergey Burov asked me to make same steps as soon as possible for working Lumi-subbranch inside 10th H1DAQ branch. 07.01.1995 ===== OnLine ==== H1KFOM === LRTS-bank will be excluded... There are some problems with full compatibility of previously used H1Lumi BOS-banks set with working inside 10th branch of H1CDAQ. When Luminosity branch was as independent branch at H1CDAQ 1Mbyte of DPM (Bill's Memory) was used for keeping up to 20 internal buffers. At future situation we shall have only 1/4 from 512K (internal VIC memory has 512 Kbytes and this memory will be shared between 4 subsys- tems at 10th branch). It means that it will be needed to reduce number of internal buffers and its size. As seems 10 or 12 internal buffers will be enough for Luminosity subbranch (not less then 10). Size of single internal H1Lumi internal buffer was at current release 31056 bytes (as it was counted for max size of H1Lumi part at H1Event when LRTS-bank was used as KEEP-bank). Really this size could be less due to last year LRTS-bank was removed from KEEP-banks and replaced with LUMM-bank (it would possible to use 6400 bytes buffers). But LRTS-bank is kept at RunEndRecord and keeps integral counts of all possible combinations per H1Run from selected H1Lumi Trigger Elements (VC,PD,ET,PDlow,PDhg). For retranslating of this LRTS-bank contents through VMEtaxi-protocol it were used the same internal buffers - so for RunEndRecords it is needed 27484 bytes size of internal buffer. But I do not know of anybody who used contents of LRTS-banks from RunEndRecords for any analize. So I propose exclude (forever) LRTS- -bank from H1Lumi BOS-banks list and replace it with something else at RunEndRecord (may be new bank with more useful integrated information per H1Run). At current situation it would be simpliest decision to exclude LRTS -bank from RunEndRecords and declare size of H1Lumi Internal Buffers as 6400 bytes per buffer. Number of H1Lumi Internal Buffers will be defined from first test experience. For any case (anybody can check my calculations) this is the raw data for calculation of H1Lumi Internal Buffer size: -------------------------------------------------------------------- BOS Bank | Max Length | Const/Var | Shortest | Longest Name | (LW units = 4 bytes)| Length | Event | Event ------------------ H1 event connected banks ------------------------ LREE | 50 | Var | + | + LRPE | 28 | Var | + | + LREP | 26 | Const | + | + LRPP | 14 | Const | + | + LREF a) | 148 | Var | | + LRPF a) | 79 | Var | | + TSTC | 10 | Const | + | + LRTF b) | 19 | Const | | + LRTN b) | 14 | Const | | + VETE | 56 | Const | + | + LRNA | 37 | Const | + | + ------------------- KEEP-environment Non-event banks --------------- LRTL c) | 241 | Const | | + LUMM c) | 731 | Const | | + LREC d) | 51 | Const | | + LRPC d) | 28 | Const | | + KEEP | 4 | Var | | + ------------------- Non-event banks -------------------------------- LUTR | 40 | Const | RunStartRecord LRTS | 6853 | Const | RunEndRecord -------------------------------------------------------------------- a) are used optionally ( at non-standard mode of H1Lumi branch) b) are used with prescale factor 10 now (at each 10th H1 Event) c) are included into H1DataFlow once per 10 sec. now d) are involved into H1DataFlow once per 11 sec. now Numbers at second column are got from BOS-banks headers. Really full length of each from high mentioned banks is more on 4 LongWords (space for BOS-bank header). So - longest event will consist of 16 banks with total space 6400 bytes and shortest event - 7 banks with total length as 996 bytes. 09.01.1995 ===== OnLine ==== H1KFOM === TwinFIC1 Release for 10th Br. As You know Egor prepared and tested new OnLine programs for work of H1Lumi branch inside H1CDAQ-environment (November-December 1994). These OnLine Programs consists of 2 program - TwinFIC1 - for running at FIC#1-environment (Master FIC#1) and TwinFIC1slave - for running at FIC#3-board - new FIC at H1Lumi Master crate (Slave FIC#1). As test show these new OnLine programs allow to decrement H1Lumi dead time (time interval from L2Keep-appearence up to FER-issuing with H1LumiOnLine program) up to project level near 800 mksec and to increment rate of making H1Lumi BOS-banks for including its into H1DataFlow (so called dead line for Luminosity branch was fixed near 150 Hz - at alone FIC#1 running - only 112 Hz - see message at LL10 from 01.07.94). For details see H1KSHE-message from 16.11.1994 at LLO. These 2 programs were got as base for next steps of upgrade H1LumiOn- LineSW for H1Lumi involving into 10th H1CDAQ branch. Today it were prepared new releases of TwinFIC1 and TwinFIC1slave programs for first tests inside 10th Branch. Both programs were tuned on the next changings: 1) MEBBASE was changed from 'D0800000'X on 'D0580000'; 2) Length of H1Lumi Internal Buffers was got as 6500 bytes; 3) Number of H1LumiInternal Buffers was got as 10; 4) LRTS-bank at EndRunRecord was temporary replaced with LUTR-bank. Test can be made together with CentralTrigger Branch after replacing VMExi2-module with VIC-module at H1Lumi Master Crate with Random trigger for example. 10.01.1995 ===== OnLine ==== H1KFOM === 32 Bit Mode at H1Lumi MacIIs. Today it was explained that only (as seems) H1Lumi MacIIs are operated now with 24 Bit Mode. All MacIIs at H1ControlRoom are ope- rated at 32 Bit Mode.As seems the set of problems can appear at future due to new MacIIs which will be bought and future Systems will be operated only at 32 Bit Mode. First attempts to try 32 bit Mode at any from H1Lumi MacII put negative result - reboot of System after switching on 32 Bit Mode is impossible. Both MacII appeare as dead on first stage of reboot before any execution of HD Software. Only without MICRON-card at MacII it is possible to reboot both MacII at 32 and 24-bit Modes. This problem appeared due to posibility of H1Lumi2 MacII memory incrmenting up to 16 Mb. This upgarde is possible only for 32 Bit Mode (now memory appeared at E.Wunsch hands and he is ready to install it if H1Lumi2 MacII will operate with 32 Bit Memory Mode). 12.01.1995 ===== OnLine ==== H1KFOM === OK with 32bit Mode at H1Lumi2 Today it was resolved problem of 32bit-mode at H1Lumi MacIIs. The reason was at very old release of Terminal Video Card (card for main Terminal). This card histirically always was installed at 9th slot of MacII nu-bus. When we put this card into last slot of nu-bus (14th) problems had disappeared. Now configuration of interface cards at NuBus at H1Lumi2 MacII is the next: 9 - ProNitron VideoCard (Formac Color Card 24) 10 - Black/White VideoCard (Macintosh Display Card 8*2...) 11 - MICRON (MICRON Interface to MacVEE) 12 - empty (no card present) 13 - Ethernet Card (MacCon NuBus-A) 14 - Main Terminal Video card (Toby frame buffer card) It was installed 16 Mbytes of new ordered memory at H1Lumi2 MacII (4 plates with 4Mbytes each) and 4 Mbyte of old memory (4 plates with 1 MBytes each). So there are 20 MByte of memory at H1Lumi2 MacII now. It were tested some H1LumiOnLine SW units which are working ordinary at H1Lumi2 MacII board. There are no problems with Egor's T_MonitorNC- -SuperCard application (it means that all old XCMDs and XFCNs which were written very long time ago are working). It were not fixed on first view problems with Movable Platforms application. Problems appeared during attempt to boot CAEN_Demo SuperCard project. At the first stage of its running - an error of type 3 occured. It means that this project cannot operate with 32 Bit Mode. Usik's application 'H1 TV Lumi Monitor' cannot run too due 'an error of type 28 occured'. Else one Usik's application 'Lserver4hera' cannot run too due to 'an error of type 3 occured'. It was tested old release A.Campbell's 'LoadRTF'-tool and H1Lumi MacII was dead. As it was explained there is 'LoadRTF'-tool release for 32 BitMode of MacII. It were not fixed any problems with Bill Haynes's 'VME_TOOLS'-running at 32 Bit Mode. It were not fixed visible problems with running of NewFastLumiMonitor SuperCard Project. It were not fixed visible problems with operation of very old applications which were born as DeskAccessories ('BeamPosition' and 'Energy_Newb09'). P.S. It is possible to operate with 24 Bit Mode at H1Lumi2 MacII but at this case all additional memory is not working - SystemSoftware is getting near 16 MBytes at this case. 12.01.1995 ===== OnLine ==== H1KFOM === LoadRTF-tool for 32 Bit Mode Today it was installed LoadRTF-tool (new release) at H1Lumi2 MacII which is operated without problems at 32 Bit Mode at MacII. Old release was renamed on LoadRTF_24. Both tools are kept at MPW:Tools:-folder. New release LoadRTF last modification date is 08 June 1993 13:17. 15.01.1995 ===== OnLine ==== H1KSHE === around branch10 running Two days of permanent running between first and third floors of Nord Hall where situated our electronics are successfuly finished at 18:10 today. At Friday afternoon was first attemt to incorporate our system in CDAQ branch 10, but complete fault of the interrupt facility were caused. Total changing interrupts philosophy during Satuday was not give a positive result. Finaly one bad slot position in the VME crate was found (zavodskaia soplia po nashemu). Now LUMI system incorporated in Branch 10 also and first tests looks is ok. But nevetheless one very usefull from my point of vew result from mentioned interrupt philosophy play can be taken. It was definitly fixed some additional interrupt sourse is not connected with correct algorithm sequence. This is one more reason to put the bank creation procedure in to background proces- sing so far no principal problems for that in the current multi- processor configuration of the system. 16.01.1995 ===== OnLine ==== H1KFOM === Runs with Lumi at 10th Branch From yesterday evening up to today morning it were written 6 H1 Runs for testing of Luminosity branch behaivour inside 10th HDAQ branch (which is named as "Subsystems 101 room"): 92576 from 15.01.95 18:54:09 up to 19:45:39 with 48650 events 92577 from 15.01.95 19:45:47 up to 20:16:46 with 29122 events 92578 from 15.01.95 20:16:53 up to 20:22:21 with 36205 events 92579 from 15.01.95 20:24:27 up to 20:30:31 with 45413 events 92580 from 15.01.95 20:33:20 up to 20:40:19 with 6500 events 92582 from 15.01.95 20:41:28 up to 08:04:52 with 383978 events All high mentioned H1 Runs were written on Temporary cartridges: HERA04.H1TEMP.G0014V00 - HERA04.H1TEMP.G0017V00. L2Keep-source was random trigger from H1CentarlTrigger. Next H1LumiOnLine program releases operated: TwinFIC1_10...........MPST MPS ....219490 Fri, Jan 13, 04:59 PM 1995 TwinFIC1slave_10.... .MPST MPS .....64920 Fri, Jan 13, 04:59 PM 1995 Runs 92576,92577 are first written on cartridges H1Runs with Luminosity branch operated 'inside' 10th HDAQ Branch (XI=402). Run 92578 is written for test with large LogRate (near 130 Hz). Run 92579 is written for test with large LogRate (near 130 Hz) with Luminosity branch operation as 9th branch (XI=202). It is possible to compare banks set at H1Runs 92578 and 92579 and to be sure that LRTS-bank exists at Run 92579 but absent at Run92578, one LUTR-bank (at RunStartRecord) is presented at Run92579 and two LUTR-banks (at RunStartRecored and at EndRunRecord) are presented at all another Runs VETE-bank was temporary absent at all H1Runs which were recorded with Lumi branch operation inside 10th branch. Operation inside 9th H1DAQ branch was made under next releases of H1LumiProgram releases: TwinFIC1..............MPST MPS ....220304 Fri, Jan 13, 05:00 PM 1995 TwinFIC1slave.........MPST MPS .....64934 Fri, Jan 13, 05:01 PM 1995 Run 92582 was wriiten all night with low log rate for time stability testing. 16.01.1995 ===== OnLine ==== H1KFOM === RTF-tool for 32 Bit Mode Today it was installed RTF-tool (new release) at H1Lumi2 MacII which is operated without problems at 32 Bit Mode at MacII. Old release was renamed on RTF_24bit. Both tools are kept at MPW:Tools:-folder. New release RTF last modification date is 12 May 1993 09:00. 17.01.1995 ================= H1KFOM === IBM is Out from DataTaking... On my question to Uwe Kruener-Marquis about where HERA04.H1TEMP.G0014 V00-HERA04.H1TEMP.G0017V00 data sets are disposed (at DESY IBM only first 3 temporary data sets were written at 95 - ...G0001..-..G0003..) Ralf Gerhards answered with the next messages - as seems this message is interesting for all H1Lumi community : "..... Date: Mon, 16 Jan 1995 17:57:57 +0100 (MET) From: Ralf Gerhards To: "A.M. Fomenko" cc: Uwe Kruener-Marquis Subject: Cartridges with temporary raw data Dear Alexander, Uwe forwarded your message to me because he is in holidays this week. The files are of course available but we decided to not write data to the IBM anymore in 1995. In any case, all analyses will have to be performed on dice2. Therefore, the 1995 data will be only available on tape at dice2. The files are still in the silo but not visible from the IBM anymore. You can find these files on dice2 by looking into the directory /acs/data/95/temp The files are called (please note the small change in the name because the generation data group concept is not used anymore). HERA04.H1TEMP.C9500001 ... If you want to read the files, use the STAGE ACS keyword sequence in the F-pack open statement (or STAGEKEEP of course) with file names data/95/temp/HERA04... Please note that you do not need /acs/ in the file name. Please tell me, if you are by no means able to analyze your data on dice2. In this case we will have to rediscuss our strategy for this year's data taking. As I said before our main goal is to exclude the IBM completely from this business. Cheers, Ralf ..." 18.01.1995 ================= H1KMAL === Status of Tagger-44 ......... There is information from HERA-people (via G.Winter) that the installation of new vacuum pipe with the new window will be finished on February 4th. Today we have the next status with the new tagger activity: - the mechanical construction of detector is ready; - crystals are wraped up alum.maylar; - PM"s with dividers are available, now under check; - necessary components (connectors, light diods, cabels and more other ) are collected set. Assembling and tunning of modules will be done up to end of January. A design of the support for the new tagger is connected with the real space condition at placing area after the new pipe installation and its construction may be done only after this procedure. 18.01.1995 ===== OnLine ==== H1KFOM === New TwinFICs Releases & Tests Yesterday and today it was cleaned both TwinFIC1 and TwinFIC1slave releases from old or not using branches and subroutines (Calibration of Photoproduction branch, using of HHPACK-subroutines anywhere, LRTC-bank subroutines, some monitoring subroutines (TenBunchNew) which are using now at FIC#2, rest of DPMfilling subroutines, Lumibranch- subroutines and H1Lumi Reconstruction package for Photoproduction branch and all Indirect COMMONs). It were produced new releases of TwinFIC1 and TwinFIC1slave programs for working inside 10th branch with very optimistic program sizes: TwinFIC1...............MPST MPS .....92032 Tue, Jan 18, 03:01 PM 1995 M TwinFIC1slave..........MPST MPS .....58302 Tue, Jan 18, 03:01 PM 1995 M Previous releases (especially TwinFIC1) had more program sizes: TwinFIC1_9.............MPST MPS ....220304 Fri, Jan 13, 05:00 PM 1995 TwinFIC1slave_9........MPST MPS .....64934 Fri, Jan 13, 05:01 PM 1995 It means that at nearest releases more wide using of FIC Local DPM at IlevelA.f-subroutines will be made. It would be possible to make LoadRTF-procedure into more last addresses of FIC#1 local DPM memory and to use near 236K of FIC#1 local DPM memory for different buffers which were disposed before at not local DPM. As seems it is waiting for some improvements of H1Lumi Dead Line characteristics. At nearest future I shall try to put IlevelA at TwinFIC1-program on background level too as Egor proposed. May be it will be possible to improve of procedure of final moving of all H1Lumi produced BOS-bank into so-called 'Bill's Memory' with excluding of some steps of data moving inside H1LumiOnLineSW (optimi- zation). Implementation of all MODEs was made at last releases due to origi- nal releases can operate only at 6th MODE. As You remember sometimes we used 1st MODE for FADC Raw data recording. Yesterday evening and today morning some intermediate releases of TwinFIC-programs were tested with Luminosity branch working inside 10th Branch together with Forward Muon Branch and Forward Proton Spectrometer(simulated) Branch. Runs 92718-92728 were recorded on temporary cartridges (after 17.01.95 21:25:08). Tests without logging were continued up to 18.01.95 11:21:33 (up to H1Run 92766). Maximal Logging Rate was achieved near 143 Hz (H1Lumi Dead Line). Last releases of TwinFIC-programs were tested with H1CDAQ too. H1Run 92777 was recorded on temporary cartridge with these programs. Luminosity branch alone operated inside 10th Branch during this Run. 23.01.1995 ===== OnLine ==== H1KFOM === New TwinFIC1-releases & Tests After large "cleaning" of both TwinFIC1 and TwinFIC1slave program it were made moving of all internal buffers used at ReadOut-chains into FIC1s Local DPMs. Internal buffers which were used for reading of data from VME-modules (FADCs,GPTPs,SlowCard and FastCard) were disposed at Local DPM at all previous releases. Now all internal FIFO-buffers which are used for Linearization,Processing and Bank Creation procedures were moved into Local DPM too (near 80K memory). Additionally it were made some steps on decrementing of VME traffic at our Master Crate (VME->VME moving were changed on Local->Local or Local->VME or VME->Local etc.). As result it were produced next TwinFIC1-family releases of program: TwinFIC1...............MPST MPS .....91918 Thu, Jan 22, 07:34 PM 1995 M TwinFIC1slave..........MPST MPS .....43348 Thu, Jan 22, 08:22 PM 1995 M These programs were tested with H1CDAQ (yesterday - Sunday evening) inside 10th branch. On the first view all is OK. It were recorded H1Runs 92908,92909 and 92910 on 25th and 26th temporary data sets. It was fixed H1Lumi Dead Line near 168-170Hz for Mode 6 (which is used at H1Lumi Standard Operation) and near 136Hz for Mode 1. 23.01.1995 ===== OnLine ==== H1KFOM === New TwinFIC1-releases & Tests It were made (as seems) last tuning procedures at TwinFIC1-family programs and last releases were produced with the next creation dates: TwinFIC1...............MPST MPS .....92002 Thu, Jan 23, 04:08 PM 1995 M TwinFIC1slave..........MPST MPS .....43410 Thu, Jan 23, 02:10 PM 1995 M These programs were tested today with H1CDAQ (Runs92982,92983 on temporary cartridges) inside 10th Branch. It was fixed H1Lumi Dead Line near 175 Hz for Mode 6 (which is used at H1Lumi Standard Operation) and near 140 Hz for Mode 1 - a little better then at previous releases. Very old timeout problem and SPUR- -exeption problem are living at our system yet. 24.01.1995 ===== OnLine ==== H1KFOM === New TwinFIC1-releases & Tests The set of not very significant on the first view changing at programs algorithms put good results. Last new releases of TwinFIC1- family programs during today test woth H1CDAQ put the next results: H1Lumi Dead Line is 195 Hz now for Mode 6 (Standard Operation Mode), 151 Hz for Mode 1 and 215 Hz for Mode 7. Test H1Runs with Luminosity branch operation inside 10th branch were recorded today on temporary cartridges: 93062 (Mode 6),93063 (Mode 1) and 93064 (Mode 7). IlevelA.f-subroutine operated at BG-area of FIC#1-Master firstly. Today (as seems forever) Bill removed VMExi2-module from H1Lumi Master Crate. VIC is installed today on its slot (before this - during last tests VIC was installed at another slot and we can operate at both modes - as 9th branch and inside 10th branch). From today H1Lumi will operate only inside 10th branch (9th branch will be property of new BDC-branch at H1CDAQ). These are creation dates and memory size of last releases: TwinFIC1...............MPST MPS .....92058 Thu, Jan 24, 11:37 AM 1995 M TwinFIC1slave..........MPST MPS .....43542 Thu, Jan 23, 07:15 PM 1995 M Test Run 93091 was recorded after VIC new slot installation and it were not fixed any problems (H1Lumi Dead Line was fixed near 198 Hz) Short characteristics of last releases (Mode 6): a) L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 122 mksec at averaging (min=2,max=159,max(*)=690mks) before FrontEndReady(FER) issuing; max=159mksec was measured without operation of 'BunchCurrents'- Usik's application at H1Lumi MacII board; max(*)=690mksec was measured with operation of 'BunchCurrents'- Usik's application at H1Lumi MacII board; As Egor explained this influence exists due to BlockMove opera- tion using at Usik's application - it was not recommended; This is direct influence of Usik's application activity on very important H1Lumi parameter - dead time (delay before FER-issuing) - this situation is enough rare (once per 30 sec) b) IlevelA_Master is waiting for end of IlevelA_Slave activity near 55 mksec at averaging (min=0,max=741mksec) before start of moving of all produced banks into H1CDAQ (through VMtaxiprotocol); c) IlevelA_Slave is waiting for end of IlevelA_Master activity with previous event (mainly OutBanks-subroutine activity) near 1607 mksec at averaging (min=539,max=35488mksec). 25.01.1995 ================= F11LEV === CAEN modules for new taggers. Yesterday I got the following mail from Zuerich: The new CAEN power supply for the extended etagger has been delivered to Zuerich and will arrive at DESY tomorrow together with the vertex detector. It needs still a german power plug, otherwise ready to be installed. Who likes to have it for installation? Greetings Ralph Eichler It means that the modules are at DESY today. Please take care that they are properly used and not disappear! 25.01.1995 ================= H1KMAL === State of KRS ................ Both calorimeters: PD and ET have been removed from HERA-tunnel, delivered in Room101 and taked to pieces for the modification of dividers. The control with naked eyes shows that the state od PD cristals is OK, but in ET-detector the KRS-cristals of 21,22,23 have the small but visible darkening ( may be 5-7 %...). That is interesting - the neihbouring chanels (24 ??) are very transparent. The small darkening has been observed at 45 and 48 chanels too. 25.01.1995 ===== OnLine ==== H1KFOM === New TwinFIC1-releases & Tests Today it were made new releases of subroutines which are making Reading from VME-modules (ReadNC,ReadTrigSum,ReadTrigSum13 and ReadVETEbank). It were made some standard optimisation steps with using of AssemblerMotorola68020-insertions. All these subroutines are working at L2KeepSubSlave-subroutines. If You remember at last releases: ".. L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 122 mksec at averaging (min=2,max=159,max(*)=690mks) before FrontEndReady(FER) issuing..." Now it is possible to proclaim that: a) L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 16 mksec at averaging (min=0,max=49,max(*)=393mks) before FrontEndReady(FER) issuing. b) IlevelA_Master is waiting for end of IlevelA_Slave activity near 55 mksec at averaging (min=0,max=614mksec) before start of moving of all produced banks into H1CDAQ (through VMtaxiprotocol); It means that both processors are working with these programs releases with more optimal manner as at previous releases. There is good status of work sharing between these 2 processors without large waiting loops for synchronisation of their work. Informatiom for any case: a) L2KeepSub-Master makes: ReadTSTC,ReadET,ReadPD,(ReadTriggerBank, ReadTrigSum and ReadTrigSum13)/10 L2KeepSub-Slave makes: ReadNC and ReadVETEbank b) IlevelA-Master makes: DecodET,LinearizationET,ProcessingET, CreateBankLREE,CreateBankTSTC,OutBanks IlevelA-Slave makes: DecodPD,LinearizationPD,ProcessingPD, CreateBankLRPE,(DecodTrigSum,CreateBankLRTF ProcTrigSum,PutTrigSumLRTN)/10,DecodNC and CreateBankLRNA. These are creation dates and memory size of last releases: TwinFIC1...............MPST MPS .....90832 Thu, Jan 25, 06:24 PM 1995 M TwinFIC1slave..........MPST MPS .....43050 Thu, Jan 25, 06:02 PM 1995 M Last new releases of TwinFIC1-family programs during today tests with H1CDAQ put the next results: H1Lumi Dead Line is 205 Hz now for Mode 6 (Standard Operation Mode), 155 Hz for Mode 1 and 225 Hz for Mode 7. Test H1Runs with Luminosity branch operation inside 10th branch were recorded today on temporary cartridges: 93191 (Mode 1),93192 (Mode 6), 93193 (Mode 6 without Usik's application running),93194 (Mode 7 without Usik's application running). Egor's estimation of H1Lumi Dead time status are optimistic too - dead time is a little less then at previous releases (near 100 mksec less as seems). P.S. Usik promised to change BlockMove operations at his application on ordinary loops. 26.01.1995 ===== OnLine ==== H1KFOM === New TwinFIC1-releases & Tests Today it were made new releases of subroutines which are making Reading from VME-modules (ReadET and ReadPD). It were made some standard optimisation steps with using of AssemblerMotorola68020-insertions. All these subroutines are working at L2KeepSubMaster-subroutines. If You remember at last releases: ".. L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 16 mksec at averaging (min=0,max=49,max(*)=393mks) before FrontEndReady(FER) issuing.." Now it is possible to proclaim that: a) L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 50 mksec at averaging (min=0,max=??,max(*)=672mks) before FrontEndReady(FER) issuing. (??)-means that test without Usik's application running was not made Yesterday it was strugle for decrementing of waiting time (due to optimization of subroutines which are working at FIC#1 Slave) - today it was strugle for incrementing of this time (for making of low mentioned window for new data reading). It means that there is near 50 mksec 'window' at L2KeepSub_Master- activity (between end of existing reading chains at L2KeepSub_Master and end of existing reading chains at L2KeepSub_Slave). As seems this window is good 'candidate' for insertion of new data reading - for future H1Lumi Bank with data from ETag44. Now this 'window' is filled with ordinary loop with waiting for end of activity L2KeepSub_Slave-activity. These are creation dates and memory size of last releases: TwinFIC1...............MPST MPS .....88746 Thu, Jan 26, 03:29 PM 1995 M TwinFIC1slave..........MPST MPS .....43050 Thu, Jan 26, 02:02 PM 1995 M As seems all steps for improvements of time characteristics of existing program releases are finished. As the result - H1Lumi Dead Line now 205Hz and H1LumiDeadTime-less then 800 mksec (as less as possible) - near 700 mksec. After insertion of data reading from ETag44 it is waiting that H1Lumi Dead time will be almost the same and H1LumiDeadLine must be less on 10-20 Hz. As seems it will be OK. 27.01.1995 ================= H1KFOM === Power Failure at North Hall Today near 10:05 it was happened powere failure at North Hall. Dark filled H1 Control Room, 101st Room, Trailer and H1 Hall. Alarm lights were switched on after some seconds. At H1Lumi System were switched off MasterCrate, FADC Crate, Trigger Crate,CAMAC crate and both MacIIs. Kubler Counters and CAEN HV were at switched off status before. Aliving of all systems will be made later after switching on of all power nets at North Hall. 27.01.1995 ================= H1KMAL === PD is back in the tunnel .... The Photon detector had been subjected to the repair and the modification: 1) in the channel 11 the PM with a divider have been rep- laced by new one's; 2) the part of resistors (R1 at the beginning and R12 at the end) in the dividers have been changed for stabilit- rons (Zener Diodes). P0: For the corner modules Igor made the exception.. - no technical changes P1: R1--> 100 V, R12--> 200 V P2: R1--> 100 V, R12--> (200 + 24) V P3: R1--> 100 V, R12--> (200 + 24) V P4: R1--> (100 + 24) V, R12--> (100 + 150) V P5: R1--> (100 + 33) V, R12--> (240 + 24) V P6: R1--> 100 V, R12--> 200 V P7: R1--> 100 V, R12--> 200 V P8: R1--> 100 V, R12--> 200 V P9: R1--> (100 + 15) V, R12--> (200 + 24) V P10: R1--> 100 V, R12--> (200 + 15) V P11: R1--> 100 V, R12--> (200 + 18) V, R13--> (240 + 100) V P12: R1--> 100 V, R12--> 200 V P13: R1--> 100 V, R12--> (200 + 18) V P14: R1--> 100 V, R12--> 200 V P15: R1--> (100 + 18) V, R12--> 240 V P16: R1--> (100 + 18) V, R12--> 240 V P17: R1--> 100 V, R12--> (200 + 15) V P18: R1--> 100 V, R12--> 200 V P19: R1--> (100 + 15) V, R12--> (200 + 24) V P20: the corner ---> no technical changes P21: R1--> 120 V, R12--> 240 V P22: R1--> 120 V, R12--> 240 V P23: R1--> 120 V, R12--> (240 + 15) V After that the PD detector was returned back on 102 m from IP. 28.01.1995 ===== OnLine ==== H1KFOM === New H1Lumi banks for ETag44.. It is proposed two new H1Lumi-banks for data from new ETag44-detector They are - LR1E and LR1F. LR1E is analog of existing LREE-bank and LR1F is analog of existing LREF-bank. High mentioned names were accepted by S.Levonyan. ! BANKname BANKtype !Comments ! TABLE LR1E B16 ! Lumi_Response_1st_new_el._tagger_Event ! (digitisation) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NCELL I 0 5 ! cell (channel) number 2 EDEP I 0 65535 ! for real data - FADC count <= 20001: ! EDEP = 20000 in case of overflow ! EDEP = 20001 in case of zero-pedestal ! for MC - energy in MeV END TABLE ! BANKname BANKtype !Comments ! TABLE LR1F B16 ! Lumi_Response_1st_new_el._tagger_Fadc ! (present in a special test mode only) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NCELL I 0 5 ! cell (channel) number 2 A0102 I 0 65535 ! 1-st (high byte) and 2-nd (low byte) ! bins of NCELL FADC window ! packed into B16 word 3 A0304 I 0 65535 ! 3rd and 4th bins of NCELL FADC window 4 A0506 I 0 65535 ! 5th and 6th bins of NCELL FADC window 5 A0708 I 0 65535 ! 7rd and 8th bins of NCELL FADC window 6 A0910 I 0 65535 ! 9th and 10th bins of NCELL FADC window END TABLE As I understood - the next configuration of ETag44 is adopted (view from H1 Interaction Point): --------------------- | | | | et4 | et5 | Crystall sizes are the same | | | as at ET (22mmx22mm). --------------------- e+beam | | | et0-et5 channels of ETag44 + | et2 | et3 | will be connected with first | | | FADC which was used for e0- --------------------- e15 channels of ET. It means | | | that first 6 channels of ET | et0 | et1 | (e00-e05) will be proclaimed | | | as dead channels at ET. --------------------- As seems there are no any reasons to keep e06 as non-dead channel and due to possible using of this channel for ETag44-Trigger Sum for example (if it needed) or for any another needs. Today it were prepared releases of TwinFIC1-family programs which can produce these BOS-banks. These are creation dates and memory size of these releases: TwinFIC1...............MPST MPS .....93842 Sat, Jan 28, 07:06 PM 1995 M TwinFIC1slave..........MPST MPS .....43050 Thu, Jan 26, 02:02 PM 1995 M It were changed load addresses due to appearence of new FIFO-buffers for new data (near 7K of FIC#1 Local DPM). Releases were tested at local mode. Test with H1CDAQ was not made due to problems with H1CentralTrigger at H1CDAQ (after Power Failure). 29.01.1995 ===== OnLine ==== H1KFOM === Tests with H1CDAQ (LR1E,LR1F) Yesterday evening it were made first tests of new releases of TwinFIC1-family program which can produce LR1E- and LR1F-BOS banks. Last new releases of TwinFIC1-family programs during tests with H1CDAQ inside 10th branch put the next results: H1Lumi Dead Line is 185 Hz now for Mode 6 (Standard Operation Mode), 140 Hz for Mode 1 and 224 Hz for Mode 7. As Egor estimated with his tools H1 Lumi Dead time was incremented on value near 70-80 mksec but is inside reasonable (ordinary accepted by H1CTrig experts as normal) time region (near 800mksec). Appearence of LR1E and LR1F at H1DataFlow was checked with BRECORD- command inside H1 Event Display program which operates at H1CDAQ. On the first view no any remarks on its BOS-structure. Short characteristics of last releases (Mode 6): a) L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 23.5 mksec at averaging (min=0,max=64 ,max(*)=650mks) before FrontEndReady(FER) issuing; b) IlevelA_Master is waiting for end of IlevelA_Slave activity near 28.4 mksec at averaging (min=0,max=326mksec) before start of moving of all produced banks into H1CDAQ (through VMtaxiprotocol); c) IlevelA_Slave is waiting for end of IlevelA_Master activity with previous event (mainly OutBanks-subroutine activity) near 2235. mksec at averaging (min=561,max=36929mksec). Data Logging was not operated yesterday evening (after Friday PowerFailure this branch is not operated yet). Jan Olsson is informed about possible appearence of new H1Lumi BOS- banks at H1DataFlow. There is new tuning variable at H1Lumi system now - FADC-Shift for ETag44's FADC. Now it is installed on zero value. Its VME addresse is B00448F4 as You can see from any from H1Lumi MacIIs. Banks LR1E and LR1F appear at H1DataFlow with the same order as LREE and LREF: 1st Mode - LREE,LREF,LRPE,LRPF,LR1E,LR1F 6th Mode - LREE, LRPE, LR1E 7th Mode - LREF, LRPF, LR1F All features which exist at LREE-bank are presented at LR1E-bank contents (var. lenght (from 1 to 7), zero suppresed, negative values, same pedestals substraction procedure, same overflow sign). Only zero-pedestal sign is not used. ROERROR's which connected with LR1E and LR1F banks are the same as for LREE and LREF-banks. There is no flag for switching off of these banks from H1Lumi Data Flow. These banks are always ON and only MODE-changing can delete its from H1DataFlow. There are some plans to change all chain of LREE and LREF-banks making (without e00-e06). After this changing we shall look never e00-e06 responses at LREE,LREF-banks. It will be possible to decrement H1Lumi Dead time (little spare time for future LR2E and LR2F(??)) and increment H1Lumi Dead Line. L4 and L5(?) monitoring histos could be changed more significantly if e00-e06 were presented etc. 30.01.1995 ===== OnLine ==== H1KFOM === e00-e06 Removing at LREE,LREF Yesterday evening it were prepared and tested with H1CDAQ new releases of TwinFIC1-family program. Main update was connected with removing of e00-e06 responses at LREE and LREF-banks (changing at ReadET,DecodET,LinearizationET,ProcessingET,ProcessingETA(zero pedest), CreateBanksLREE_LREF,CreateBankLREE and CreateBankLREF-subroutines). These are creation dates and memory size of these releases: TwinFIC1...............MPST MPS .....93576 Sun, Jan 29, 09:14 PM 1995 M TwinFIC1slave..........MPST MPS .....43050 Thu, Jan 26, 02:02 PM 1995 M Last new releases of TwinFIC1-family programs during tests with H1CDAQ put the next results: H1Lumi Dead Line is 208 Hz now for Mode 6 (Standard Operation Mode), 155 Hz for Mode 1 and 241 Hz for Mode 7. Now it is possible to proclaim that: a) L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 31 mksec at averaging (min=0,max=??,max(*)=??mks) before FrontEndReady(FER) issuing. H1Lumi Dead time was decremented and estimated (preliminary) with Egor's tools as time near 700 mksec (at averaging). Data Logging was not operated yesterday evening (after Friday PowerFailure this branch is not operated yet). 30.01.1995 ================= F11LEV === new and old e-taggers ....... As I see, the bottom layer was effectively removed from the old electron tagger. Qusetion: forever, or temorarily until the additional FADC units will be available in the online LUMI system? If forever, them why to keep crystals and electronics of e00-e06? Another point: don't forget to install an old e-tagger ASYMMETRICALLY (z=0 plane between 4-th and 5-th layers). As we decided, it will be useful for the calibration, and now also because of 6 layers left in the vertical direction. P.S. I hope, that the channel numbering is not changed in the old ET (i.e. the first connected channel has number e07, not e00). Or is it changed? One has to know that for the reconstruction. 30.01.1995 ===== OnLine ==== H1KFOM === e00-e06 Removing at LREE,LREF Channel numbering is not changed in the old ET (i.e. the first connec- ted channel has number e07, not e00). 30.01.1995 ===== OnLine ==== H1KFOM === Cleaning of FIC#2 Program ... Today it was made cleaning of H1LumiOnLineFIC2-program. It were removed not used at last time subroutines and branches (HHPACK, FUMILI and V.Andreev's fit of ET-spectrum, Soloviev's algorithm of calibration, LRTS-bank accessories, rest of DPM filling routines for old Usik's Desk Acessories, different debug branches etc.). It was produced new release of H1LumiOnLineFIC2-program with next creation date and program size: H1LumiOnLineFIC2.......MPST MPS ....192138 Mon, Jan 30, 07:31 PM 1995 M Previous release was made at October 94 with the next date and size: H1LumiOnLineFIC2.......MPST MPS ....251438 Sat, Oct 08, 05:40 PM 1994 M Almost 60K of memory is free for future devlopments connected with new ETag44-reconstruction, calibration and monitoring subroutines. It was changed background loop rate at FIC#2 without presence of any flags - it became near 5.2 kHz (before cleaning this rate was near 3 kHz). 31.01.1995 ===== OnLine ==== H1KFOM === H1LumiOnLineFIC2-development. Today it was prepared new release of H1LumiOnLineFIC2-program with inserting of some branches for ETag44's subroutines. It was prepared some preliminary release for ETag44 Reconstruction (with using of ET-Reconstruction as base - attempt to use 'Dead Channel option). It was prepared ReadOut chain for ETag44-events. It was inserted the using of 4th Trigger Bit at Luminosity subbranch for permanent ETag44-calibration (ETag44*PD*nVC). As You remember before this it were used 3 Trigger Bits at Luminosity subbranch: ET*PD*nVC (for permanent ET- and PD-channel calibration); ET*PD*VC (for permanent VCs-calibration); VCv1 (with analyze of presence PD1 (PDlow) - for LUMM-bank histos making). It will be involved new (4th) Trigger bit at Luminosity subbranch: ETag44*PD*nVC (for permanent ETag44-channels calibration). As seems it would be good the using of old method calibration coefficients introducing into H1 Data Flow (may be new bank with 6 CCet44s, may be to use temporary first 6 places at LREP-bank etc.). Calibration of ETag44-channels will be made with CCpd and CCvcs 'fixing' method (as for VCs-calibration when we 'fixed' CCet and CCpd). It were introduced into ET-reconstruction 7 Dead Channels (e00-e06). e48-dead channel exists up to now. I am not sure that it is time to 'alive' it. Release without calibration subroutines was prepared yesterday evening but not tested yet. 02.02.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development Today it was preapred new release of H1LumiOnLineFIC2-program with inserting of calibration subroutines for et0-et5 (new ETag44). During high mentioned preparing it were found and removed two bugs. First bug was fixed at last year running H1LumiOnLineFIC2-program and was connected with putting of CCvcs into LRPP-bank (at half LRPP-banks this value was put as multiplicated on factor 3.89 and and another half - without this multiplication). For those who want to use permanent calibration of VCs-channel at last year data this factor must be put in mind. Second bug was fixed at new DecodETag44-subroutine (assembler). Last release of TwinFIC1-family program was created and successfully tested with this bug and put wrong test result connected with H1 Lumi Dead Line measurements- 208 Hz). These are creation dates and memory size of last releases: TwinFIC1...............MPST MPS .....93574 Wed, Feb 01, 03:46 PM 1995 M TwinFIC1slave..........MPST MPS .....43050 Thu, Jan 26, 02:02 PM 1995 M H1LumiOnLineFIC2.......MPST MPS ....221568 Thu, Feb 02, 01:10 PM 1995 M Last new releases of TwinFIC1-family programs during tests with H1CDAQ put the next result: H1Lumi Dead Line is 201 Hz now for Mode 6 (Standard Operation Mode). Test on time stability was unsuccesful.SPUR exeption(?) after 5 hours of work with H1CDAQ with hugo L2Keep Rates broke program. There is proposal to introduce new H1Lumi BOS-bank into H1DataFlow with current values of calibration coefficients for et0-et5 channels (ETag44). This bank will be the same as LREP,LRPP-family banks. Its description could be as the next (for example): ! BANKname BANKtype ! Comments ! TABLE LR1P B16 ! Lumi_Response_1st_el._tagger_calibra- ! tion_coefficients_set_from_Permanent_ ! calibration_procedure ! ATTributes: ! ----------- !COL ATT-name FMT Min Max ! Comments ! 1 CC I 0 32767 ! Calibration Coeff (1.0 keV/FADC count) ! Channel # = row # - 1 (0...5) END TABLE 02.02.1995 ===== OnLine ==== H1KFOM === LR1P BOS bank is involved Today it was prepared new release of TwinFIC1-program with only one changing - it was added LR1P BOS-bank making into OutBanks- subroutine. Its length is fixed - 4 LongWords and this bank will be presented at each H1Event. Its format is B16. These are creation date and memory size of last release: TwinFIC1...............MPST MPS .....93898 Thu, Feb 02, 05:45 PM 1995 M Test with H1CDAQ was not made due to problems with H1Ctrigger. 04.02.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development During last 2 days it were made new releases of H1LumiOnLineFIC2 and TwinFIC1 programs. All changing were connected with inserting of different ETag44 events monitoring facilities into these programs. These are creation dates and memory sizes of last releases: TwinFIC1...............MPST MPS .....93800 Sat, Feb 04, 08:18 PM 1995 M TwinFIC1slave..........MPST MPS .....43050 Thu, Jan 26, 02:02 PM 1995 M H1LumiOnLineFIC2.......MPST MPS ....225374 Fri, Feb 03, 02:08 PM 1995 M Last new releases of TwinFIC1-family programs during tests with H1CDAQ put the next results: H1Lumi Dead Line is 200 Hz now for Mode 6 (Standard Operation Mode), 152 Hz for Mode 1 and 236 Hz for Mode 7. Now it is possible to proclaim that for Mode 6 (Stand.Operation Mode) a) L2KeepSub_Master is waiting for end of L2KeepSub_Slave activity near 30 mksec at averaging (min=0,max=72,max(*)=??mks) before FrontEndReady(FER) issuing. b) IlevelA_Master is waiting for end of IlevelA_Slave activity near 52 mksec at averaging (min=0,max=583mksec) before start of moving of all produced banks into H1CDAQ (through VMtaxiprotocol); c) IlevelA_Slave is waiting for end of IlevelA_Master activity with previous event (mainly OutBanks-subroutine activity) near 2208 mksec at averaging. It were recorded H1Runs with last TwinFIC1-family programs (10th br.): Run 93886,93887 (Mode 6), Run 93888 (Mode 1) and Run 93889 (Mode 7). Run 93891 was recorded at Mode 6 as time stability test. All these H1Runs are recorded on temporary cartridge (36th of this year). At these H1Runs LR1E,LR1F and LR1P banks firstly are presented at H1DataFlow. Anybody can check its structure and contents and welcome any remarks. Run 93895 was recorded after correction very old bug at LREP-bank structure (miniheader was corrected for events with presence non-zero value at VCv-channel) - see messages 27.04.94(LL8),27.07.94(LL9) and 29.07.94(LL10). 05.02.1995 ===== OnLine ==== H1KFOM === Dead Channel Option Investig. It was made attempt to investigate early mentioned Dead Channel Option at H1Lumi Reconstruction package with data from e+p Lumi Runs 94 (10C-data sample - from Run 89877 up to 90420). It was proclaimed that all channels at ET exept e14,e15,e21,e22,e28 and e29 are dead. It was made recalibration of six ET-channels with 'fixing' of calibration coefficients for PD-channels. After 15(!) iteration steps it were obtained the next values for Relation Coefficients (for ET-channels): e28 = 1.602(+47.4%) e29 = 1.147(+14.0%) e21 = 0.996(- 3.9%) e22 = 1.038(- 2.3%) e14 = 1.742(+72.0%) e15 = 1.047(+13.9%) Start values of CCet were got as its were produced after 2nd step of calibration with 10C-th ET&PD&nVC-data sample at Nov.94. Final Calibration Coefficients values are the next: e28 = 6.817(+50.6%) e29 = 6.008(+14.9%) e21 = 7.048(- 4.2%) e22 = 5.011(- 0.1%) e14 =10.214(+76.2%) e15 = 3.038(+15.7%) As seems incrementing of CCe28,CCe29,CCe14 and CCe15 is connected with attempt 'to compensate' non-visible shower at neigbour cells. For calibration it were selected only events with -6.3cm ETrec+PDrec > 24.53GeV) & (Evcs<0.2 GeV) - from ET*PD*nVC sample b) ET*PD*VC - (30.53GeV > ETrec+PDrec > 24.53GeV) - from ET*PD*VC sample c) VCv - (IFP.GT.O after LREC) - from S93-sample (EMIN(2)=0.5 GeV) d) ETag44*PD*nVC - (30.53GeV > ETrec+PDrec > 24.53GeV) & (Evcs<0.2GeV)& & (42 dead channels at ET - exept e14,e15,e21,e22, e28,e29) - from ET*PD*nVC-sample As You can see all samples include 25 responses from PD-cells and VCs-response. ET*PD*nVC and ET*PD*VC samples include 48 responses of ET-cells (e00-e47) - e48 was dead channel as You remember. VCv-sample includes 1 integer*2 with PDlow Trigger Element value (0/1) ETag44*PD*nVC-sample includes 6 responses from e14,e15,e21,e22,e28 and e29 ("simulated" e00-e05 responses of ETag44). This release helped to be shure that all 'event-dependent' branches are working (reconstructions, calibrations, histomakers for LUMM-banks) Really it was possible to look for that all channels had been calibra- ted (e00-e47,p00-p24,vcs and et00-et05). It is waiting that something as this situation will be observed with e+beam presence at HERA. It will be needed to tune some prescale factors for each from this events at Lumi-subbranch. There are some tools for making it when it will be possible at Egor's new 'DAQ-status'-application. Information for any case (locations for data samples at DPM): a) ET*PD*nVC - from $B0828700 2300 156 bytes structures; b) ET*PD*VC - from $B0880100 2300 156 bytes structures; c) VCv - from $B08D7B00 2300 62 bytes structures; d) ETag44*PD*nVC - from $B0800000 2300 72 bytes structures. Filling of this areas are made with Bill's VME-tools: MEM_LOAD HD_LPI:ETag44&PD&nVC B0800000 MEM_LOAD HD_LPI:ETPDnVC B0828700 MEM_LOAD HD_LPI:ETPDVC B0880100 MEM_LOAD HD_LPI:VCv B08D7B00 All binary data sets were retranslated into H1Lumi HD_LPI with FTP-protocol from dice2-environment. Best energy resolutions which were looked at OnLine energy histos were fixed as the next: for ET*PD*nVC events 1.02 GeV, for ETag44*PD* *nVC events - 1.28 GeV. ET*PD*VC events energy histos are not making. So - there are some hopes that 'old' calibration technology will be used for new ETag44-channels. But may be better to test and tune this procedure with simulated ETag44*PD*nVC events. If somebody can produce digi-LR1E-banks from updated H1LumiSim - it will be better sample for tuning of OnLine calibration procedure. Nearest plans are connected with involving of S.Levonyan's proposed little upgrade of reconstruction for ETag44-events (may be for old reconstruction too) - without LREC3.f calls and with 7 Dead Channels option. 09.02.1995 ===== OnLine ==== H1KFOM === Phone Call from Jan Olsson.. Yesterday it was phone call from Jan Olsson with warning about some problems at BOS-structure of H1Lumi BOS-banks at H1Run 94017. This Run was recorded 07.02.95 near 20:21 with near 1800 events. Recording was cancelled due to problems with SGI-logging. May be Olsson's warning was connected with these problems. Problem is under investigation. 11.02.1995 ===== OnLine ==== H1KFOM === Proposal to OffLine People.. During last large upgrade of H1Lumi ReadOut chains I found some incorrectly made procedure. Motivation for recognition of this 'incorrectly made procedure' was surprize due to presence of 3 multiplication (!?) (integer multiplication) at LRTN-bank making procedure. If You remember we have 3 Trigger Sums at LRTN-bank which are made at ReadOut chains at GeV(!?) units. I think that it would be enough to put into LRTN-bank not GeV-Response but only FADC-counts (as it is made for all ET-,PD- and ETag44-channels). And 'calibration' of Trigger Sums is Off-line task and after this 'calibration' with (as seems) enough simple procedure it must appear some new version of some new bank at H1DataBase with 3 calibration Coefficients for existed Trigger Sums (at future - may be 4 or 5 Calibration Coefficients). So - I propose to change LRTN-bank format with (for example) next manner: ! BANKname BANKtype !Comments ! TABLE LRTN B32 ! Lumi_Response_Trigger_moNitoring ! ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 LCTOT I 0 +INF ! Total Luminosity Counter 2 LCBUNCH I 0 +INF ! Current Bunch Luminosity Counter 3 LTIME I -INF +INF ! Local Time Scaler (units = 1/2950 sec) 4 LTEFF I 0 1000 ! Luminosity Trigger Efficiency(in 0.1%) 5 TLUMI I 0 +INF ! Current Total Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 6 BLUMI I 0 +INF ! Selected Bunch Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 7 TBP I 0 +INF ! Trigger Bits status at Previous BC 8 TBC I 0 +INF ! Trigger Bits status at Current BC 9 TBN I 0 +INF ! Trigger Bits status at Next BC 10 EPD I 0 44001 ! L1 trigger Energy in PD (FADC counts) ! EPD = 44000 in case of overflow ! EPD = 44001 in case of zero-pedestal 11 EET I 0 44001 ! L1 trigger energy in ET (FADC counts) ! EET = 44000 in case of overflow ! EET = 44001 in case of zero-pedestal 12 EPDET I 0 44001 ! L1 trigger Energy sum ET+PD (FADC cnts ! EPDET = 44000 in case of overflow ! EPDET = 44001 in case of zero-pedestal 13 EET1 I 0 44001 ! L1 trigger Energy sum ET1 (FADC counts ! EET1 = 44000 in case of overflow ! EET1 = 44001 in case of zero-pedestal 14 EET2 I 0 44001 ! L1 trigger Energy sum ET2 (FADC counts ! EET2 = 44000 in case of overflow ! EET2 = 44001 in case of zero-pedestal And the next question - are any needs to make update of LRTF-bank due to appearence of new TriggerSums at future - for example: ! BANKname BANKtype !Comments ! TABLE LRTF B16 ! Lumi_Response_Trigger_sums_FADCs ! (present in a special test mode only) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NSUMM I 0 4 ! Sum number: 0,1,2,3,4 for PD,ET, ! PD+ET,ET1,ET2 2 PULS12 I 0 65535 ! 1st and 2nd bins of NSUM FADC window ! packed into B16; high byte - 1st, low ! byte - 2nd; 3 PULS34 I 0 65535 ! 3rd and 4th bins of NSUM FADC window 4 PULS56 I 0 65535 ! 5th and 6th bins of NSUM FADC window 5 PULS78 I 0 65535 ! 7rd and 8th bins of NSUM FADC window 6 PULS910 I 0 65535 ! 9th and 10th bins of NSUM FADC window 7 PULS1112 I 0 65535 !11th and 12th bins of NSUM FADC window 8 PULS1314 I 0 65535 !13th and 14th bins of NSUM FADC window 9 PULS1516 I 0 65535 !15th and 16th bins of NSUM FADC window 10 PULS1718 I 0 65535 !17th and 18th bins of NSUM FADC window 11 PULS1920 I 0 65535 !19th and 20th bins of NSUM FADC window 12 PULS2122 I 0 65535 !21th and 22th bins of NSUM FADC window END TABLE It is needed to remark that these banks are prescaled now - only at each 10th H1-events are presented. Including of new Trigger Sums will get some additional time at both chains (H1Lumi Dead Time and H1Lumi Dead Line). I can make involving of high mentioned Trigger Sums into existing LRTN- and LRTF-banks (or only into LRTN(?)) if anybody from OffLine people will say - yes it is really needed and check of this data will be made at L4 or at L5 or at some Monitoring Tools etc. But involving of new bank into H1DataBase with Calibration Coefficients for Trigger Sums at any case is needed (multiplication at ReadOut chains must be excluded). 11.02.1995 ================= H1KFOM === Deposited Energies at ET,PD Yesterday it was found that deposited energy at ET (if this energy is calculated as sum of all ET-cells responses) at ET*PD*nVC sample and ET*PD*VC-samples is more then ErecET and deposited anergy at PD (if this energy is calculated as sum of all PD-cells resp.) is less then ErecPD. If to use EdepET and EdepPD from H1Lumi Reconstruction package - situation is more reasonable - always ETdep less then ETrec at all samples. The same situation is seen at s93-sample for EdepPD. If EdepPD is got from H1LumiReconstruction package - all is understandable - EdepPD less then ErecPD. If You calculate EdepPD as sum of all PD-cells response and VCs-response - EdepPD (at averaging) more then ErecPD. It means that at most of events there are some 'additional' signals at ET (for ET*PD*nVC and ET*PD*VC-samples) and some 'additional' signals at PD (for s93-sample). May be it is superposition with some off-momentum electrons at ET and some background photons at PD. As seems these 'additional' signals are not summarized noice from all cells channels (see message at LL8 from 04.03.94 - random trigger with HV ON): ".... Mean,Sigma(GeV) and Entries Values for ETdep -0.426 0.865 108850 Mean,Sigma(GeV) and Entries Values for PDdep -0.013 0.491 109377 ..." It were got for high mentioned analyze ET&PD&nVC, ET&PD&VC and S93- samples of so called 10C-sample of e+p94 data (Runs 89877-90420). 11.02.1995 ================= H1KFOM === LFRC and LESC Format Update As seems it is time to think about possible updating of LFRC and LESC-banks formats (if it is possible for H1DataBase banks). For example the next structure of these banks would be reasonable for H1 Data Taking'95: ! BANKname BANKtype !Comments ! TABLE LFRC ! Lumi_FADC_Relation_Coefficients ! between lumi and photo branches ! Used for the photoproduction branch ! calibration with lumi events ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 RC F 0.0 10.0 ! Relation coefficient (dimensionless) ! Channel # = row # - 1 ! 0...48 - ET, 49...73 - PD, 74 - VC, ! 75...80 - ET1) END TABLE ! BANKname BANKtype ! BANK LESC ! Lumi detector's Energy SCale ! ! ! COL Att-name FMT MIN MAX ! Comments 1 CORRET F 0.0 10.0 ! global correction for ET 2 CORRPD F 0.0 10.0 ! global correction for PD 3 CORRVC F 0.0 10.0 ! global correction for VC 4 CORRET1 F 0.0 10.0 ! global correction for ET1 ! END BANK I am not sure that the same 'technology' of calibration will be used for ET2 at the next year - so there are no lines for future ET2-channels 12.02.1995 ===== OnLine ==== H1KFOM === Tests with H1CDAQ ....... Today it were recorded set of H1Runs on 48th temporary cartridge to be sure that really at our system there are some problems with making of bad BOS-banks etc. Runs were recorded today from 13:16 up to 13:47. Some problems existed with Farm program (it was crashed 4 times) But up to now I can not find 48th temporary cartridge at dice2-environ- ment. It were recorded H1Runs from 94230 up to 94238 with Modes 6,1 and 7. At this period at FIC#2-environment it were operated 4 branches with ET*PD*nVC, ET*PD*VC, VCv and ETag44*PD*nVC 'back up' events and I hope that contents of LREP,LRPP,LR1P,LUMM-bank histos must be reaso- nable due to calibrations of all ET,PD,VCs and ETag44 channels were ON. The next rates of different branches at FIC#2 program were fixed during data logging (Random Trigger rate near 160 Hz) - all SW pescale factors were zeroed: ET*PD*nVC-branch 4.6-5.0 Hz (H1Lumi Random Trigger) ET*PD*VC-branch 0.5-0.7 Hz (H1Lumi PDlow Trigger - light pulses) VCv-branch 4.7-5.2 Hz (H1Lumi Random Trigger) ETag44*PD*nVC-branch 1.3-2.2 Hz (H1Lumi PDlow Trigger - light pulses) Before recording of these Runs it were fixed the next aver.rates of different branches at FIC#2 program during data logging -if all another 3 branches are Off (with 201Hz rate of L2Keep-events at TwinFIC1s): ET*PD*nVC-branch 6.7- 7.8 Hz (H1Lumi PDlow Trigger) ET*PD*VC-branch 6.2- 7.3 Hz (H1Lumi PDlow Trigger) VCv-branch not measured ETag44*PD*nVC-branch 9.1-10.3 Hz (H1Lumi PDlow Trigger) Old H1LumiRec-program operated for ETag44*PD*nVC-branch (with call LREC3.f and internal FUMILI-calls). 12.02.1995 ===== OnLine ==== H1KFOM === New LREC for ETag44-events... Today it was tested new release of OnLine H1Lumi Reconstruction package for ETag44-events which was proposed and tested by S.Levonian. CALL LREC3 with internal CALL FUMILI was changed with CALL LREC2 for ETag44-events. As the result we have little profit at time characte- ristic (average rate of Reconstruction was incremented from 11.27- 12.13 Hz to 11.71-12.52 Hz or on factor 1.035 (on 3.5 %)). But excluding of LREC3 with FUMILI from program decremented size of program on 10Kbyte (!). It was found that Calibration procedure made different calibration coefficients with these two different packages (CCe21=CCet02=1.55 MeV/ FADC count for LREC3-release and CCe21=CCet02=2.40 MeV/FADC count for LREC2-release). Coordinate distribution at ET44tag is better (as seems) with new (LREC2.f) variant of reconstruction. At old (LREC3.f) release it was seen some slope (as seems not real) at Xet vs Yet distribution. At new release slope disappeared and distribution became more reasona- ble. 12.02.1995 ================= H1KFOM === Remark on p26-response(VCv) After correction of BOS-structure at LREP-bank (miniheader) - see my message from 04.02.95 - today during tests with H1CDAQ it was found that really at OnLine H1ED this response is seen as 2nd point above PD (before it was only one point above PD - VCs). But sometimes this 2nd point is seen as gigant square (this gigant squares appeared after involving of negative values into LREE and LREP-banks - but soon all became OK). As seems for VCv at OnLine H1ED there is no similar procedure of strugle with gigant squares (IFR16 or something else). P.S. (S.Lev) No, the reason is that the Event Display does not expect more than 26 channels in the photon arm. Thus there is no calibration coeff. for the last 27-th channel (or 26-th, if count from 0). This must be corrected in ESCAL routine of the Event Display. 13.02.1995 ===== OnLine ==== H1KFOM === Time Stability Test ......... Now is 13.02.95 08:40 and CDAQ-command at DSYIBM shows: * Run Number : 94258 * * Run Status : RUNNING * * Run Start Time : 0:50:48 * * Event Number : 3033055 * It means that time stability test with H1Lumi inside 10th branch is OK. Almost 8 hours of operation without SPURs. 13.02.1995 ===== OnLine ==== H1KFOM === Yesterday Test Runs at dice2 Yesterday test Runs it is possible to find at dice2 at ACS. First Runs (94230-94237 and first part of 94238) at permanent cartridge (48th of this year) and last part of 94238 at temporary cartridge (42nd of this year). RUN 94230 EVS 21524 ( 0-4FFFFFFF) XI 402 B= 0 H1RAWD.C9500048 RUN 94231 EVS 10913 ( 0-4FFFFFFF) XI 402 B= 0 H1RAWD.C9500048 RUN 94232 EVS 10284 ( 0-4FFFFFFF) XI 402 B= 0 H1RAWD.C9500048 RUN 94233 EVS 18750 ( 0- 11041) XI 402 B= 0 H1RAWD.C9500048 RUN 94234 EVS 84465 ( 0- 84417) XI 402 B= 0 H1RAWD.C9500048 RUN 94235 EVS 1391 ( 0- 1387) XI 402 B= 0 H1RAWD.C9500048 RUN 94236 EVS 175 ( 0- 175) XI 402 B= 0 H1RAWD.C9500048 RUN 94237 EVS 10752 ( 0- 10748) XI 402 B= 0 H1RAWD.C9500048 RUN 94238 EVS 3482 ( 0- 3481) XI 402 B= 0 H1RAWD.C9500048 RUN 94238 EVS 49080 ( 3482- 52531) H1TEMP.C9500042 As example You can see next Run Summary to be sure that something is changed at H1Lumi Data Flow: >>> Start RUN Summary --------------------- <<<<< NRUN NrofEvts Ev.Fst Ev.Lst DATE TIME <---> DATE TIME 94238 49080 3482 52531 950212 134142 950212 134545 4C524545:LREE 49039 39 30 43 <-- Max.Length 4C523145:LR1E 49039 6 3 7 <- New Bank 4C523150:LR1P 49039 4 4 4 <- New Bank Output Data Set Name HERA04.H1TEMP.C9500042 Temporary >>> End RUN Summary -------------------- <<<<< High mentioned cartridge data sets it is possible to find at dice2 at next directories: [dice2] /acs/data/95/rawd $ -rw-rw-r-- 1 kruener h1 176 Feb 12 13:49 HERA04.H1RAWD.C9500048 [dice2] /acs/data/95/temp $ -rw-rw-r-- 1 kruener h1 176 Feb 13 00:45 HERA04.H1TEMP.C9500042 13.02.1995 ================= H1KMAL === ET back in HERA tunnel ...... The ET-Tagger(old) had been taken from tunnel for the repairing and the modification: 1) for the channel 19 the PM with a divider have been rep- laced by new one's; 2) the part of resistors (R1 at the beginning and R12, R11 at the end) in the dividers have been changed for stabilit- rons (Zener Diodes). For 6-th layer the Z.Diodes have been implemented in exchange for R13 too: E14: R1-> 120, R11-> 200, R12-> 240 E15: R1-> 120, R11-> 200, R12-> 240 E16: R1-> 100+11, R12-> 200+24 E17: R1-> 120, R11-> 200, R12-> 240 E18: R1-> 100+11, R12-> 200+24 new---> E19: R1-> 100+6, R12-> 200+15, R13->150+150 E20: R1-> 100+6, R12-> 200+11 E21: R1-> 120+15, R12-> 270 E22: R1-> 100+15, R11-> 200, R12-> 240 E23: R1-> 120, R11-> 200+6, R12-> 240+11 E24: R1-> 100+18, R11-> 200, R12-> 240 E25: R1-> 120, R11-> 200+6, R12-> 240+11 E26: R1-> 100+15, R11-> 200, R12-> 120+100 E27: R1-> 100+15, R12-> 200+6, E28: R1-> 120, R11-> 200, R12-> 240 E29: R1-> 120+9,, R11-> 200+15, R12-> 240+18 E30: R1-> 120+15, R11-> 200+24, R12-> 270 E31: R1-> 120+15, R11-> 200+11, R12-> 240+11 E32: R1-> 100+11, R12-> 200+24 E33: R1-> 100+9, R12-> 100+120 E34: R1-> 120, R11-> 200, R12-> 240 E35: R1-> 120+9, R11-> 200+15, R12-> 240+15, R13-> 270+100 E36: R1-> 120+15, R12-> 270, R13-> 200+200 E37: R1-> 120, R11-> 200, R12-> 240, R13-> 240+120 E38: R1-> 100+18, R12-> 240, R13-> 200+150 E39: R1-> 120, R12-> 240+6, R13-> 270+100 E40: R1-> 120, R11-> 200, R12-> 240, R13-> 200+120 E41: R1-> 100+24, R12-> 240+6, R13-> 270+100 The detector was returned back into the tunnel. The communication cabels from the lower layer ( HV and HF) have been connected off in order to use its for the Tagger44. HV was switched on without any troubles. 13.02.1995 ================= H1KFOM === Proposal to OffLine People... As seems it is time to change more radically ReadOut and Bank Crea- tion for H1Lumi L1 Trigger Sums. As You remember from very old times we read Trigger Sums from 22(!?) neigbour FADC-bins - it means that we always(!) got L1 Analog Sums from 2 neighbour bunch crossings and made FADC-counts from all these pulses. I almost sure that Trigger Sums for part of events of last (may be at previous too) Data Taking is more then Deposited Energy - due to possible 'superposition' with neigbour bunch-crossing H1Lumi L1 Trigger. It is proposed to decrement number of FADC-bins to 10 (as for ET- and PD-channels) and to change LRTF-bank format: ! BANKname BANKtype !Comments ! TABLE LRTF B16 ! Lumi_Response_Trigger_sums_FADCs ! (present in a special test mode only) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NSUMM I 0 3 ! Sum number: 0,1,2,3 for PD,ET, ! PD+ET,ET1 2 PULS12 I 0 65535 ! 1st and 2nd bins of NSUM FADC window ! packed into B16; high byte - 1st, low ! byte - 2nd; 3 PULS34 I 0 65535 ! 3rd and 4th bins of NSUM FADC window 4 PULS56 I 0 65535 ! 5th and 6th bins of NSUM FADC window 5 PULS78 I 0 65535 ! 7rd and 8th bins of NSUM FADC window 6 PULS910 I 0 65535 ! 9th and 10th bins of NSUM FADC window LRTN-bank (a little) must be changed too: ! BANKname BANKtype !Comments ! TABLE LRTN B32 ! Lumi_Response_Trigger_moNitoring ! ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 LCTOT I 0 +INF ! Total Luminosity Counter 2 LCBUNCH I 0 +INF ! Current Bunch Luminosity Counter 3 LTIME I -INF +INF ! Local Time Scaler (units = 1/2950 sec) 4 LTEFF I 0 1000 ! Luminosity Trigger Efficiency(in 0.1%) 5 TLUMI I 0 +INF ! Current Total Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 6 BLUMI I 0 +INF ! Selected Bunch Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 7 TBP I 0 +INF ! Trigger Bits status at Previous BC 8 TBC I 0 +INF ! Trigger Bits status at Current BC 9 TBN I 0 +INF ! Trigger Bits status at Next BC 10 EPD I 0 20001 ! L1 trigger Energy in PD (FADC counts) ! EPD = 20000 in case of overflow ! EPD = 20001 in case of zero-pedestal 11 EET I 0 20001 ! L1 trigger energy in ET (FADC counts) ! EET = 20000 in case of overflow ! EET = 20001 in case of zero-pedestal 12 EPDET I 0 20001 ! L1 trigger Energy sum ET+PD (FADC cnts ! EPDET = 20000 in case of overflow ! EPDET = 20001 in case of zero-pedestal 13 EET1 I 0 20001 ! L1 trigger Energy sum ET1 (FADC counts ! EET1 = 20000 in case of overflow ! EET1 = 20001 in case of zero-pedestal 14 EET2 I 0 20001 ! L1 trigger Energy sum ET2 (FADC counts ! EET2 = 20000 in case of overflow ! EET2 = 20001 in case of zero-pedestal 15.02.1995 ================= H1KMAL === Present ET position ......... The present position of the ET-calorimeter is similar the Lumi Run94 geometry (see LL8 from 15.03). It means that between the e-beam axis and the ET-tagger centre we have a distance of 117.5 mm. The beam pipe D=63.8 mm: ///| ///| 207 mm ///|<..................................................>| ///| || | || | : ///| || : || | | ///| || | || | 117.5 mm : ///| || : ||<.................................>| ///| || | || | : ///| || :<........................................>| X= 149.5 ///| || | || | : ///| || :<-- e-beam axis | ///| || | || centre of ET ----------->: ///|<---- side of QS34 element | 15.02.1995 ===== OnLine ==== H1KFOM === New Structures of LRTN,LRTF Yesterday and today it were prepared and tested (locally) new rele- ses of TwinFIC1 and TwinFIC1slave programs. Main changings are connected with early promised 'radically changings' at making of L1 Trigger Sums due to absence of any contradictions from OffLinePeople a) removing of multiplications from ReadOut - GeV units at LRTN-banks became FADC-counts (some details were changed - 20000 and 20001 as overflow and zero pedestals signs, negative values were introduced); b) incrementing of LRTN-bank size on 2 B32-words (places for ET1 and ET2 L1 Trigger Sums (at FADC-counts).ET2 Trigger Sum is always zero at current LRTN-contents; c) introducing of one bunch crossing data reading for L1 Trigger Sums (from 22 FADC bins to 10 FADC-bins). For this step it were observed real data LRTF-banks from Runs 90419 (last H1Run at e+p94 data taking) and from Run 81610 (one from last H1Lumi Dedicated Runs at e-p94 data taking). L1 PD-trigger Sum and L1 ET+PD-trigger Sum will be read on 40nsec later as earlier and on 80 nsec earlier finished, L1 ET-Trigger Sum will be read on 160(!)nsec later as earlier and on 40 nsec later(!) finished. These digits were got from real data (its are not understandable yet). "Window" for ETag44-Trigger Sum is made similar as for ET-Trigger Sum (exept native FADC-shift variable - new option of H1Lumi OnLine SW). d) introducing of new structure for LRTF-bank: there are 10 (not 22 as earlier) FADC bins for each from 4 (not 3 as earlier) Trigger Sums. There are no any data for ET2-trigger sum at LRTF. So - both miniheader values were changed. e) for all high mentioned changings it were updated 14 subroutines at both programs and it was changed load addresses for both programs into FIC's Local DPM - now its became B0044E00 and B0244E00. These are creation dates and memory sizes of last releases: TwinFIC1...............MPST MPS .....93448 Wed, Feb 15, 01:54 PM 1995 M TwinFIC1slave..........MPST MPS .....42698 Wed, Feb 15, 01:55 PM 1995 M A little earlier it were realized long time ago promised to Egor the reactions of TwinFIC1slave program on L3Reject-appearence (at this case program must finish all reading and as soon as possible to help at TwinFIC1-program at issuing of FER-signal to H1CTrigger. This (some intermediate release) yesterday evening was succesfully tested with H1CDAQ. H1Lumi Dead Line decremented from 202 to 197 Hz and H1Lumi Dead Time became a little more (but inside reasonable - near 800 mksec - time interval). At this releases it were inserted additinal analyze (after each 6 long words reading from pipe lines) of L3Reject-appearence flag at ReadVETEbank.f and ReadNC.f subroutines Due to this additional analyze average H1Lumi time characteristics were changed into 'bad' side. These are creation dates and memory sizes of intermediate releases: TwinFIC1_prev..........MPST MPS .....93522 Mon, Feb 13, 05:51 PM 1995 M TwinFIC1slave_prev.....MPST MPS .....43108 Mon, Feb 13, 05:51 PM 1995 M L3Reject-reaction at TwimFIC1slave program are presented at more late releases too (naturally). 15.02.1995 ================= H1KFOM === Some Details of Bank Descrip. As seems it is needed to correct some H1Lumi Banks Descriptions due to possible presence negative values as contents of some lines. Little correction must be made at LRPE-bank description - max cell number must be 26 - for VCv. ! BANKname BANKtype !Comments ! TABLE LREE B16 ! Lumi_Response_Electron_tagger_Event ! (digitisation) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NCELL I 0 48 ! cell (channel) number 2 EDEP I -INF +INF ! for real data - FADC count <= 20001: ! EDEP = 20000 in case of overflow ! EDEP = 20001 in case of zero-pedestal ! for MC - energy in MeV END TABLE TABLE LRPE B16 ! Lumi_Response_Photon_detector_Event ! (digitisation) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NCELL I 0 26 ! cell number; 0...24 - PD, 25 - VCs, ! 26 - VCv 2 EDEP I -INF +INF ! for real data - FADC count <= 20001: ! EDEP = 20000 in case of overflow ! EDEP = 20001 in case of zero-pedestal ! for MC - energy in MeV END TABLE TABLE LR1E B16 ! Lumi_Response_1st_new_el._tagger_Event ! (digitisation) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NCELL I 0 5 ! cell (channel) number 2 EDEP I -INF +INF ! for real data - FADC count <= 20001: ! EDEP = 20000 in case of overflow ! EDEP = 20001 in case of zero-pedestal ! for MC - energy in MeV END TABLE TABLE LRTN B32 ! Lumi_Response_Trigger_moNitoring ! ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 LCTOT I 0 +INF ! Total Luminosity Counter 2 LCBUNCH I 0 +INF ! Current Bunch Luminosity Counter 3 LTIME I -INF +INF ! Local Time Scaler (units = 1/2950 sec) 4 LTEFF I 0 1000 ! Luminosity Trigger Efficiency(in 0.1%) 5 TLUMI I 0 +INF ! Current Total Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 6 BLUMI I 0 +INF ! Selected Bunch Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 7 TBP I 0 +INF ! Trigger Bits status at Previous BC 8 TBC I 0 +INF ! Trigger Bits status at Current BC 9 TBN I 0 +INF ! Trigger Bits status at Next BC 10 EPD I -INF 20001 ! L1 trigger Energy in PD (FADC counts) ! EPD = 20000 in case of overflow ! EPD = 20001 in case of zero-pedestal 11 EET I -INF 20001 ! L1 trigger energy in ET (FADC counts) ! EET = 20000 in case of overflow ! EET = 20001 in case of zero-pedestal 12 EPDET I -INF 20001 ! L1 trigger Energy sum ET+PD (FADC cnts ! EPDET = 20000 in case of overflow ! EPDET = 20001 in case of zero-pedestal 13 EET1 I -INF 20001 ! L1 trigger Energy sum ET1 (FADC counts ! EET1 = 20000 in case of overflow ! EET1 = 20001 in case of zero-pedestal 14 EET2 I -INF 20001 ! L1 trigger Energy sum ET2 (FADC counts ! EET2 = 20000 in case of overflow ! EET2 = 20001 in case of zero-pedestal P.S. If I am understanding right -INF and +INF are different for B16 and for B32 formats: a) -INF for B16 is hexadecimal number &8000 = -32768 decimal +INF for B16 is hexadecimal number &7FFF = +32767 decimal b) -INF for B32 is hexadecimal number &80000000 = -2147483648 dec +INF for B32 is hexadecimal number &7FFFFFFF = +2147483647 dec 16.02.1995 ===== OnLine ==== H1KFOM === TwinFIC1-programs Development Yesterday it were made new releases of TwinFIC1-program family. Set of subroutines which are connected with L1 Trigger Sums making were optimized with Motorola68020 Assembler insertions into RTF-codes. Optimization was made with changings of Memory/Memory and Memory/Regi- ster operations with Register/Register, with excluding of some opera- tions due to using of more optimal adresses mode (.L --> .L*4), with decrementing of stack sizes etc. The next subroitines were optimized: ReadTrigSum.f - reading of 10 LongWords - ET Trig.sum ReadTrigSum44.f - reading of 10 LongWords - ETag44 Trig.sum ReadTrigSum13.f - reading of 10 LongWords - PD and ET+PD Trig.sums DecodTrigSum.f - maker of dimension (0:3,0:9) CreateBankLRTF.f - LRTF-bank creator ProcTrigSumA.f and ProcTrigSum.f - linearization and FADCcounts makers As result - it were produced the next releases of program: TwinFIC1...............MPST MPS .....92554 Wed, Feb 15, 09:42 PM 1995 M TwinFIC1slave..........MPST MPS .....42416 Wed, Feb 15, 09:42 PM 1995 M These releases were tested with H1CDAQ yesterday and set of H1Lumi Test Runs were recorded on cartridges (at temporary mode) but its are disposed at 52th permanent cartridge of this year. At these H1Runs You can firstly look for new LRTF- and LRTN-structure which are described earlier: Run 94439 - Mode 6, near 20K events, near 204 Hz H1Lumi DeadLine Run 94440 - Mode 1, near 20K events, near 145 Hz H1Lumi DeadLine Run 94441 - Mode 7, near 20K events, near 207 Hz H1Lumi DeadLine Run 94442 - Mode 6, near 90K events, near 204 Hz H1Lumi DeadLine During recording of first 3 H1 Runs it were ON light diods - it means that with Random trigger You can find large negative or large positive signals at each channels. These light pulses were switched Off during recording of Run 94442 - for comparing. Yesterday evening (at 22:27) it was started time stability Run 94445 with last releases simultaneously with SiliconTracker amd Muon branches (Random Trigger rate is near 160 Hz, Logging Rate is near 110 Hz). Now 09:04 - Run at progress all branches are living. Only TimeOut errors filled all message Log screen. TimeOut problem is not resolved yet (as seems not only at our branch). Up to now it were recorded near 4176K events. 16.02.1995 ===== dice2 ===== H1KFOM === Problems with cartl at dice2 Date: Thu, 16 Feb 1995 13:29:23 +0100 (MET) From: Uwe Kruener-Marquis To: Alexander Fomenko Subject: Re: Problems with cartl at dice2 Hi Alexander, I'm sorry, that cartl is not working, but we have expected Rybicki to be here already in january, to make cartl up-to- . -date. I hope, he will come soon, because we had up to now not the time to do this. But nevertheless, you can find the information in the following files in the directory /h1/log: HERA05.H1RS95A HERA05.H1RT95A HERA05.H1RUS95A HERA05.H1TRIGGER HERA05.H1RSTEMP HERA05.H1RTTEMP which are normal text files. Since the files for the temporary data have no "95" in the name, cartl is working for these files. Hope to help you with these info. 16.02.1995 ===== OnLine ==== H1KFOM === Summary Remarks on BOS-banks This is fragment of RunSummary of H1Run 94440 (Mode 1). I put some comments into each line as signs of any changing at H1Lumi BOS-banks contents between H1 Data Taking 94 and H1 Data Taking 95: 4C524545:LREE 21492 37 13 43 <- new Max.Length 4C525045:LRPE 21492 24 6 28 <- new miniheader 4C524546:LREF 21492 109 37 127 <- new Max.Length 4C525446:LRTF 2150 13 13 13 <- new structure 4C525046:LRPF 21492 70 16 79 4C52544E:LRTN 2150 16 16 16 <- new structure 4C525050:LRPP 21492 14 14 14 4C524550:LREP 21492 26 26 26 4C555452:LUTR 2 40 40 40 <- twice per H1Run 56455445:VETE 21492 56 56 56 4C524E41:LRNA 21492 37 37 37 4C554D4D:LUMM 16 731 731 731 4C523145:LR1E 21492 6 3 7 <- new Bank 4C523146:LR1F 21492 17 7 19 <- new Bank 4C523150:LR1P 21492 4 4 4 <- new Bank 16.02.1995 ===== OnLine ==== H1KFOM === TwinFIC1-programs Development I found bug at my OffLine program and now all became understandable with L1 Trigger Sums shifts. After analyze of data from H1Run 90419 it was made 'right' shift for one bunch-crossing reading for new structure of LRTF and LRTN-banks. This 'right' shift became 40 nsec for L1 ET Trigger Sum (as for L1 PD and L1 ET+PD). Corrections were made at ReadOutTrigSum.f and ReadOutTrigSum44.f subroutines and it were produced new releases of TwinFIC1-program family: TwinFIC1...............MPST MPS .....92474 Wed, Feb 16, 05:12 PM 1995 M TwinFIC1slave..........MPST MPS .....42416 Wed, Feb 16, 05:12 PM 1995 M 17.02.1995 ================= H1KMAL === Tagger-44 in the tunnel ..... The modified beam pipe near 44 m from IP had been recently installed. The new tagger was mounted in the tunnel at the point z = -43.12 m. For details see H1KMAL.SUMM(TAG44POS). P.S. (S.Lev) A corresponding entry was made to LPI internal report's list (try: LPI to get a comlete list): 59. 17/02/95 Author: E.I.Malinovski, Yu.V.Soloviev Title: Position of Tagger44 in HERA tunnel - this is a TeX file (!) list 'H1KMAL.SUMM(TAG44POS)' Ref. No: 01-95 P.S. (Yu.S.) Due to nesessity to correct some misstaping bugs in H1KMAL.SUMM(TAGG44POS),one can get this report by processing under GTEX following Tex file: 'H1KSOL.LUMI94.S(TAG44POS)' 22.02.95 20.02.1995 ===== OnLine ==== H1KFOM === TwinFIC1-programs Development During OffLine analisis of H1Lumi Test Runs - 94440-94442 it was found some bug at L1TriggerSum 'making' for ETag44 (at all H1 Runs it were found only zeros at LRTF and LRTN-banks at L1 Trigger Sums for ETag44). Today it was fixed bug at DecodTrigSum.f-subroutine and it were produced new releases of TwinFIC1-program family without this bug: TwinFIC1...............MPST MPS .....92470 Mon, Feb 20, 12:57 AM 1995 M TwinFIC1slave..........MPST MPS .....42412 Mon, Feb 20, 12:57 PM 1995 M There is 2 days pause at possibility to work with H1CDAQ (due to water cooling changing at HERA and switch off Power Supply at trailor). Tests with new releases will be recorded later. 20.02.1995 ================= F11LEV === Limitations in CT/CDAQ....... As I was told today by Felix Sefkow, there will be severe limitations in use of the Central Trigger and CDAQ during the coming Cosmic run period. This is related with some missing hardware at CT and may last until mid-end of April. During that time LUMI branch will be most likely taken out of the system, and thus no data transfer to the offline analysis will be possible. In case of urgent request by either HERA machine or our experts, LUMI system can be connected to CT/CDAQ. However, it will require a lot of manual operations (reconnecting cables and reshuffling CT-cards. Please, be ready for this situation and keep in close contact with CT experts. P.S. There will be a presentation of this topic TOMORROW, on the regular H1 trigger meeting. All interested people are invited to attend: on Tuesday, Feb. 21st 1995 10:00 - 13:00 Lab 1d, Room 292 21.02.1995 ================= H1KBEL === Lumi group meeting .......... My proposal : to collect the group meeting for discussion all our problems and plans for future after H1 collaboration meeting 4 march (saturday) 18.00 in sem. 3. If there will be another variant, let me know. A.Belousov. 22.02.1995 ===== OnLine ==== H1KFOM === Test Runs with H1CDAQ ....... Today it were recorded the set of H1Lumi Test Runs with last release of TwinFIC1-family programs (see 20.02.94 message). It were recorded next H1Runs: 94596 (Mode7)- 243 Hz, 94597 (Mode6) - 203 Hz, 94598 (Mode 1) - 146 Hz, 94599 (Mode6) - 203 Hz is in progress now as time stability test Run. It is possible to check that all is OK now with ETag44-trigger sums now at LRTF and LRTN-banks. Monitoring of different counters was made and it is possible to pro- claim that last releases have next time synchronisation characteristics a) L2KeepMaster is waiting for end of L2KeepSlave-activity with current event near 58 mksec (min =0, max = 640 mksec (with Usik's applica- tion running)).Usik did not made promised long time ago upgarde of his "BeamCurrents"-application for removing of BlockMove operations); b) IlevelAMaster is not waiting for end of IlevelASlave-activity with current event (IlevelA slave is always ready when IlevelAMaster is finishing its activity with current event); c) IlevelASlave is waiting for next events from IlevelAMaster near 1500 mksec at averaging (mainly due to OutBanks-activity) - min=703 max = 29168 mksec. At this period at FIC#2-environment it were operated 4 branches with ET*PD*nVC, ET*PD*VC, VCv and ETag44*PD*nVC 'back up' events and I hope that contents of LREP,LRPP,LR1P,LUMM-bank histos must be reaso- nable due to calibrations of all ET,PD,VCs and ETag44 channels were ON. 26.02.1995 ===== dice2 ===== H1KFOM === New LOOK COMMON Default Size Today I had problems with NtupelMaking at dice2-environment and Ralf Gerhards explained some news from latest Thursday meeting about new LOOK COMMON default size at dice2: "... Date: Sun, 26 Feb 1995 15:53:06 +0100 (MET) From: Ralf Gerhards To: Alexandre Fomenko Subject: Re: LOOK needs more space and stop with little ntupels Dear Alexander, as was announced at one of the latest Thursday meetings, the default size of the LOOK common has been changed about two weeks ago and been set to 1MB. If you now start to write more than that 1MB, you will get exactly your problem. Please use a larger version of the LOOK common by linking e.g. the LOOK library -llook20502_04mb or -llook20502_16mb This should solve your problem Cheers, Ralf ..." As seems this info is useful for those people which were not at this meeting on different reasons. 27.02.1995 ================= F11LEV === CT/CDAQ availability schedule Until end of April only 13 out of 15 subsystem STC crates can be simultaneously connected to CT driver cards. The swap of cable connections will be done on Mondays by S.Bourov. According to present schedule, LUMI system will be disconnected from Central Trigger: March,27 -- April,9 (information from F.Sefkow, CT group) 27.02.1995 ================= H1KFOM === CT/CDAQ availability schedule Date: MON, 27 FEB 95 12:53:17 +0100 From: Alexander Fomenko Subject: re: re: central trigger availability... To: Felix Sefkow > > It is important that during HERA tests with positron beam > > LUMI would be involved into H1CTRIG (first tests possible, > > new ETag probing etc.). > So we will do the swap exactly when cosmic tests stop and > HERA tests start. Would that be ok? OK. Thanks. > > Next week (during proton studies) it is possible to disconnect LUMII > > from H1CTRIG. > This would give us some felexibility, great! > > Sorry for troubles but last shedule of HERA machine was available > > only at last Friday). > No problem. Thanks for your fast reply! > Felix Sincerely, Alexander Fomenko 28.02.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development Today it were prepared new releases of H1LumiOnLineFIC2-program and TwinFIC1-program. Next changings were made at both programs: 1) it were installed (as seems) right FADC-shift for ETag44-data - for Photoproducrion branch 153 - for Luminosity branch 101 For any case: ET FADCs have shifts 143 (Ph.Br.) and 91 (Lumi Br.) PD FADCs have shifts 199 (Ph.Br.) and 147 (Lumi Br.) NC FADC has shift 140 (Ph.Br.) 2) procedure of reset of 220*32 HW Bunch Trigger Elements Combinations counters which was made all previous years at FIC#1-environment (during RunPrepare-operations) was moved into FIC#2-environment. It is possible that after this moving NAN-problem with Total Integ- rated Luminosity value per each e-filling will disappear or become more rare. 02.03.1995 ================= H01USA === photon arm modification ..... See on the dice2: ~usik/lumi/pharm_up.ps 03.03.1995 ================= H1KFOM === Let's Think About Tr.El.&Bits As You know during H1DataTaking'94 H1Lumi Trigger System had partici- pated at producing of next H1 Trigger Elements and Trigger Bits: a) H1 Trigger Elements: /* ------ TG o -------- Lumi/eTag -- TE 112-119 ---*/ H1Lumi Internal Setting #DEF Lumi_Internal = o t0 PD2 -> PD_high #DEF PD_low = o t1 PD1 -> PD_low #DEF L_Cal = o t2 PD&n(VETOs2) -> PhotDet && !WatVet #DEF ElDet = o t3 ET -> ElDet #DEF PhotDet = o t4 PD -> PhotDet #DEF WatVet = o t5 VETOs2 -> WatVet #DEF eTAG = o t6 ET&n(PD)&n(VETOs2) -> eTAG #DEF n_cntr = o t7 Remark: At Sept.94 WatVet was installed on VETOs2 (front sensitive element) before September 94 WatVet was installed on VETO (sensitive on presence of some signal more then threshold inside bunch X-ing period - amplitu- de sensitive element). b) H1 Trigger Bits: eTAG-triggers s80 eTAG v:0 f:0 t:0 P[0] C[4] s81 eTAG && ToF_IA && LAr_IF v:0 f:0 P[0] C[4] s83 eTAG && DCRPh_TNeg v:0 f:0 t:0 P[0] C[3] s84 eTAG && DCRPh_TNeg && (zVtx_mul>5) v:0 f:0 t:0 P[0] C[3] s85 eTAG && ToF_IA && LAr_EPlug v:0 f:0 P[0] C[4] s87 eTAG && DCRPh_Ta && Mu_Any v:1 f:0 t:0 P[0] C[3] s88 eTAG && DCRPh_T0_VETO_nextbc v:0 f:0 P[0] C[3] s89 eTAG && n_cntr && DCRPh_Ta v:0 f:0 P[0] C[3] s90 eTAG && ToF_IA v:0 f:0 P[0] C[4] H1Lumi Monitoring Trigger Bits: s86 eTAG P[1] C[4] s91 PD_low P[1] C[4] s92 L_Cal P[1] C[4] s93 WatVet P[1] C[4] s94 ElDet && PhotDet && !WatVet P[1] C[4] s95 ElDet && PhotDet && WatVet P[1] C[4] At H1DataTaking95 it would be reasonable 'to add' ElDet1 into trigger elements list and 'to add' one H1LumiMonitoring trigger with ElDet1 && && PDdet && !WatVet setting (s94 analog for ET1-channels calibration) and 'to change' eTAG trigger element as eTAG = (old_eTAG).OR.(new_eTAG) where old_eTAG = ElDet && !PhotDet && !WatVet new_eTAG = ElDet1 && !PhotDet && !WatVet It is proposed to make next update of H1Trigger Elements setting for H1DataTaking'95: a) H1 Trigger Elements (2 changings - Lumi_Internal and eTAG - both changings are made 'inside' H1Lumi Trigger System - without any requests to H1CTrig-team): /* ------ TG o -------- Lumi/eTag -- TE 112-119 ---*/ #DEF Lumi_Internal = o t0 ET1(?) -> ElDet1 #DEF PD_low = o t1 PD1 #DEF L_Cal = o t2 PD&n(VETOs2) -> PhotDet && !WatVet #DEF ElDet = o t3 ET #DEF PhotDet = o t4 PD #DEF WatVet = o t5 VETOs2 #DEF eTAG = o t6 (ET&n(PD)&n(VETOs2)) .or. (ET1&n(PD)&n(VETOs2)) #DEF n_cntr = o t7 b) H1Lumi Trigger Bits: no any changing - ElDet1 && PhotDet && !WatVet -sample will be got from s92-triggered events. Remarks on this proposal: a) PD_high (PD2) will be excluded from H1Lumi Trigger elements list - may be it is bad due to some off-line methods of Luminosity calculations checks (as seems) need of this bit presence (V.A.); b) as seems it is dangerous to produce eTAG as .OR. of 'old' and 'new' eTAGs - may be 'new' eTAG will be 'more' frequent and 'less' useful for eTAG-physics. May be it will be needed to install 'internal' prescale on 'new' eTAG inside eTAG-trigger element etc.. May be it is better to produce 'additional' trigger element - new eTAG - but at this case - there is no place for new eTAG among 8 H1Lumi Trigger wires. May be it is possible to make new eTAG at H1CTRIG-logic - from ElDet1,PhotDet and WatVet trigger elements but at this case it is needed some 'additional' Trigger Bits (s???) - for monitoring and (may be) physics subtriggers. As seems at this period it is not simply. All places among 128 subtriggers are busy now. As seems all existing H1Lumi MONITRIG are needed and for future data taking (s95,s94,s92 - for calibration, s91,s93 - for Luminosity calculation off-line check, s86 - for eTAG-sample monitoring). It is pity to remove any from 6 existing LUMIMONITRIGs. As seems it is time to change VETO on VETOs2 at 0th input of so- called histogramming memory (LUMM bank contents will show at this case 'real' VC-rate - number of pulses - but not number of bunch X-ings with amplitude at VCs more then threshold as it was fixed at last H1DataTaking). LUMM-bank's VC-rate was more on factor 1.4-2.1 then VC-rate calculated from TTL-counter of VC-pulses at H1DataTaking'94. 04.03.1995 ================= H1KFOM === Additional Dep.Energy ....... It were looked for ETrec-ETdep and PDrec-PDdep distributions for different samples of H1Lumi Monitoring events for so-called 10C-sample: H1Runs 89877-90419. EMIN(1)=EMIN(2)=0.5GeV at H1LumiRec. It were produced next digits: ETPDnVC ETPDVC S86 S91 S92 S93 ---------------------------------------------------------------------- ETrec>Received: by niihua.desy.de id AA02270 >>(5.67a/IDA-1.5); Mon, 6 Mar 1995 15:26:52 +0100 >>From: Ueli Straumann >>Message-Id: <199503061426.AA02270@niihua.desy.de> >>Subject: Experts on Shift? >>To: Bill.Haynes@rl.ac.uk (Bill Haynes), >> H1KECK@dsyibm.desy.de (Guenter Eckerlin), >> elsen@dice2.desy.de (Eckhard ELsen), >> F14CAM@dsyibm.desy.de (Allan Campbell), >> H1KGER@dsyibm.desy.de (Ralf Gerharts), >> H1KUWE@dsyibm.desy.de (Uwe Kruener), >> h1kksp@dsyibm.desy.de (Samuel Kazarian), >> H1KALE@dsyibm.desy.de (Alexej Babaev), >> H1KSHE@dsyibm.desy.de (I. Sheviakov), >> H1KHBD@Dsyibm.desy.de (Hans-Bernd Dreis), struczinski@niihua.desy.de, >> elsen@dice2.desy.de (Eckhard ELsen), >> h01fle@dsyibm.desy.de (Manfred Fleischer), >> h1knie@dsyibm.desy.de (Carsten Niehbur), >> F22KLE@DSYIBM.DESY.DE (Claus Kleinwort), >> F11PIT@DSYIBM.DESY.DE (Daniel Pitzl), >> F34TUT@DSYIBM.DESY.DE (Joerg Tutas), >> H1KGOE@DSYIBM.DESY.DE (Uli Goerlach) >> Mon, 6 Mar 1995 15:26:52 +0100 (MET) >>X-Mailer: ELM [version 2.4 PL23] >>Content-Type: text >>Content-Length: 424 >> >>Dear Colleagues >>There is a apparently not so official rule, that havily loaded >>experts do not need to take usual shifts. Can I ask you, whether >>you think, that either you are other colleagues you know of, belong >> this category? People, you have to be on call during the whole >>datataking are the standard example of this. >>I take applications for non-shift-duty-experts >>until end of this week, March 10. >>Cheers Ueli P.S. (by S.L.) I would definitely support the idea to make this -------------- inofficial rule an H1 standard. I already proposed this in 1994, but it was not fully accepted at that time. So: yes, I believe, I.Sheviakov must be unloaded from the usual shifts in NH (unless he feels strongly in favour to participate in them). The reliability of the system he permanently supports is much more important for us and H1. 08.03.1995 ========= H01LNS === a response to S.L.'s 06.03.95 ======= Below is my partially response to the S.Levonian's LLO 06.03.95. 1. A single Proposal: In S.L.'s proposals for the "Experts", I propose to change the item "Off-line monitoring and lumi cross", in order TO NOMINATE THE RESPONSIBLE PERSON EITHER S.LEVONIAN, OR A.FOMENKO. 2. Motivations of the Proposal, and Comments: 1) * Presently, the Lumi On-line, Detectors, H/W, S/W are working well, and they are well covered by four of highly experienced experts. * The Lumi Off-line is more dangerous as a potential source of errors in the main product of LPI - the Value of Luminosity(!). * In the referenced topic the word "monitoring" is not the main, the main contents are in the words "off-line" and "lumi cross". * That is why, the topic "Off-line Monitoring, etc." is at present THE MOST IMPORTANT FOR THE H1 AND FOR THE LPI REPUTATION ITSELF. 2) * Certainly, the better name for the above topic would be "The Luminosity Data Quality Control", like it is used by H1. * In this field of the LPI activity, the two persons - S.L. and A.F. - are now the highly experienced experts of LPI. * That is why, S.L. or/and A.F. TO BE NOMINATED RESPONSIBLE FOR THE ABOVE REFERENCED TOPIC "OFF-LINE MONITORING, ETC.". 3) * In the case of approving of this proposal, THE ABOVE TOPIC SHOULD INCLUDE THE MAIN PRODUCT OF THE LPI ACTIVITY - THE FINAL(!) (OFF-LINE) VALUES OF LUMINOSITY. * May be better to speak of "the Lumi Off-line manager", as it was proposed by S.L. for the case of Lumi On-line. * DON'T BE SPOILED BY THE THOUGHT, THAT "WE DISCUSS NOW THE WWW". Sorry for being a little long, but the subject is too important, L.Shtarkov, at DESY, 08.03.95. 08.03.1995 ================= F11LEV === Additional explanations ..... To L.N.S.'s "Proposal". 1) N.Gogitidze was nominated to be a responsible for the LUMIMON data analysis (Lumi Monitoring events) and at least partial offline L cross check by U.Straumann, after her successful work in 1994. 2) No need to "nominate S.L." for anything; as long as I feel a personal responsibility lor Lumi in the Collaboration, I will certainly support this area as much as I can. But I no longer can perform a regular important work daily, and I am happy, that Nelly can unload me from this, and I definitely can rely on her work. 3) A.Fomenko HAS his own clear responsibility, and I would be happy to see no problems there. Unfortunately, I cannot so easily agree (although I want to!) that "Presently, the Lumi On-line, Detectors, H/W, S/W are working well" Those, who are closer to the system may remember how many various problems we had in 1994 and earlier. Also the amount of night calls to our experts still remained very impressive, pointing, that the online side is still far from be perfect. This does not mean, that our experts work badly. Simply the task is very difficult. 4) As I mentioned seleral times before, I am glad, that A.Fomenko in addition to his direct responsibility took a hard job related with the calibration items. I am afraid, in 1995 with fully new online s/w he may have difficulties to do it in time. Also the corresponding offline s/w for the calibration is a bit outdated and not really a good tool now. Therefore, I would propose, that other people get familiar with this crucial for us business, to help A.F and may be even unload him fully from this task. I see at least 2 obvious candidates for that: V.Andreev and Yu.Soloviev. Of course A.F. is free to continue and to study other problems offline (like rec. quality etc), if there is no problems in the online s/w. Note also, that this year we have to incorporate new tagger to the system, and here the calibration is even more difficult (at least in the beginning). 5) Finally, what has been originally proposed for the discussion is NOT to reconsider the present responsibilities, but to give a clear and correct information for the people in H1 and outside about who is really doing what, such that they can get a useful help from the experts. So, please, first DO A REAL WORK, show that you have a useful knowledge and expertise, which others do not have, and THEN only complain, if this is ignored or forgotten. 08.03.1995 ================= H1KFOM === ET Coord.Rec. at Boundaries. At last some days it was made attempt to improve coordinate reconst- ruction for ET at boundaries (especially at column near to e+beam). Motivations are clear - new ETag44 will operate with Xet near this boundaries. Some discussions with V.Andreev provocated on this attempt. Result now is ready at some intermediate form. As seems there is little improvement of X-coordinate reconstruction - but it is needed to discuss it and to look for from different point of view Main idea was at making of different possible parametrization at Xet-producing for events with maximal hits at e21 (e14,e28,etc.) with using of H1Lumi Monitrig events of last year H1DataTaking. It were got samples of ETPDnVC and s86-events from 10C-sample (Runs 89877-90419). As samples for parametrization making it were got events with maximal hits at e23-cell. It were observed 9 cells (e23 included) around e23. These cells were combined into 3 columns (left column - e15,e22,e29, center column - e16,e23,e30 and right column e17,e24,e31). It were built 100th Ntupels with early mentioned structure but it were added variables with deposited energies per columns: NAM(19)='RROW' - deposited energy (GeV) at left column NAM(20)='LROW' - deposited energy (GeV) at right column NAM(21)='CROW' - deposited energy (GeV) at center column Ntupels are kept at next binary data sets: H1KFOM.LOOKa.R89877 - for ETPDnVC events H1KFOM.LOOK.R89877.S86.INV - for s86 events First attempt of parametrization was not enough for upgrade but at next attempts these results were used too: With ET&PD&nVC-events Ntupels it were made next parametrizations: 1) xet=f(Edep(rightRow)/Edep(centerRow)) for left boundary where Edep(rightCol) = sum of 3cell deposited energies (e15+e22+e29 or e22+ +e29+e36 or e08+e15+e22 etc.) Edep(centerCol) = sum of 3 cells deposited energies (e14+e21+e28 or e21+e28+e35 or e07+e14+e21 etc.) and it was produced next parametrization formula x = Edep(rightCol)/Edep(centerCol) if (x.gt.0.3) then xet = -6.12197 + 1.72439*x - 1.83854*x**2 + 0.743936*x**3 else xet = -7.7 + 17.3138*x -35.7703*x**2 - 130.362*x**3 xet = xet + 370.325*x**4 +1212.09*x**5 - 3365.96*x**6 endif 2) xet=f(Edep(leftCol)/Edep(centerCol)) for right boundary where Edep(leftCol) = sum of 3 cells deposited energies (e19+e26+e33 or e26+ +e33+e40 or e12+e19+e26 etc.) Edep(centerCol) = sum of 3 cells deposited energies (e20+e27+e34 or +e27+e34+e41 or e13+e20+e27 etc.) and it was produced next parametrization formula x = Edep(leftCol)/Edep(centerCol) if (x.gt.0.3) then xet = 6.17971 -2.01718*x +2.30782*x**2 -0.983424*x**3 else xet = 7.7 -20.6180*x +108.719*x**2 - 367.343*x**3 xet = xet + 534.022*x**4 + 764.081*x**5 - 2494.38*x**6 endif Second attempt to improve cordinate reconstruction at boundaries: - firstly it is defined energy at 'not existing' column from parametrization (lcol=rcol*(f(rcol/ccol)) or rcol=lcol*(f(lcol/ccol))) for case if rcol<0.09*ccol and lcol<0.09ccol it means that cordinates will be defined between -7.7 and -6.6 and between 6.6 and 7.7 with accounting of calculated deposited energy at 'non-existing' column - parametrization was made with events s86 from 10C-sample (Runs89877-90419) with selection 3x3 cells around e23(e23 cell is max hitted cell): a) rcol/lcol = f(lcol/ccol) - for using at +6.6 +7.7cm region: x = lcol/ccol rcol = lcol * (16.4694-168.150*x-3403.66*x**2+48169.0*x**3- -65490.7*x**4-483873.0*x**5-15.6975*x**6) b) lcol/rcol = f(rcol/ccol) - for using at -6.6 -7.7cm region: x = rcol/ccol lcol = rcol * (38.6524-1427.40*x+20779.2*x**2-121406.0*x**3+ +59736.0*x**1278200.0*x**5-16.9050*x**6) c) Xet = f(rcol/ccol) - for using at +6.6 +7.7cm region: rcol = lcol*f((lcol/ccol) - calculated from (a)-parametrization x = rcol/ccol Xet = 7.07716 + 1.72854*x -1.83456*x**2+0.732208*x**3-for x>0.3 or for x<0.3 Xet = 5.5 + 20.3417*x -79.2521*x**2+10.4579*x**3+ +912.062*x**4-2659.29*x**5+2395.26*x**6 d) Xet = f(lcol/ccol) - for using at -6.6 -7.7cm region: lcol = rcol*f(rcol/ccol) - calculated from (b)-parametrization x = lcol/ccol Xet = -7.10539 - 1.55368*x +1.51367*x**2-0.550842*x**3-for x>0.3 or for x<0.3 Xet = -5.5 - 20.8454*x +96.9054*x**2 - 288.954*x**3+ +1056.90*x**4-3630.86*x**5+5034.49*x**6 - for details You can see MYFIT2.LTX and MYFIT3.LTX and FIT2.MACRO andi FIT3.MACRO (fit boundaries,fixed parameters,used LOOK-binary set etc.) Last step - making of so-called tuning - there are 2 tuning constants for this method -- at LREC1.f-source (0.5 or 0.45, 0.08 or 0.075). I am not shure that last step is correct. Results You can see at 100th Ntuple which is kept at H1KFOM.LOOK.R89877.S86.NEWREC FAST08 3010200E 00000 DASD You can compare with results of old reconstruction: H1KFOM.LOOK.R89877.S86.OLDREC FAST01 3010200E 00000 DASD Source for 'new' LREC1.f (not optimized, rough) is kept at H1KFOM.LREC1-data set. 10.03.1995 ================= F11LEV === LUMI trigger setting-95 ..... This information summarizes our decision on the minimal necessary modifications in the Lumi system trigger setting for the beginning of 1995. The experience with real data should be carefully studied for further optimisation. Trigger Elements TEL1(112-119) ------------------------------ 1994 --> 1995 Comments ----------------------------------------------------------------------- #DEF Lumi_Internal = o t0 PD_high (stays as in 1994) #DEF PD_low = o t1 PD_low #DEF L_Cal = o t2 ET1 (new) #DEF ElDet = o t3 ET #DEF PhotDet = o t4 PD #DEF WatVet = o t5 WatVet ("front" type) #DEF eTAG = o t6 ET && !PD_low (modified!) ----------------------------------------------------------------------- #DEF n_cntr = o t7 n_cntr ----------------------------------------------------------------------- H1Lumi Monitoring Subtriggers ----------------------------- 1994 --> 1995 Comments ----------------------------------------------------------------------- s86 eTAG eTAG (modified, see t6) s91 PD_low same as in 1994 s92 L_Cal PD && !WatVet (same as in 1994) s93 WatVet ET1 (new, see t2 above) s94 ElDet && PhotDet && !WatVet same as in 1994 s95 ElDet && PhotDet && WatVet same as in 1994 ET1 && !PD_low && !WatVet ----------------------------------------------------------------------- The last subtrigger (eTAG-1) is new and we have to ask additional slot for it in the H1 subtrigger's list. If new tagger will work properly, it may be in future included in the standard eTAG trigger bit (as an exclusive OR) to provide a unique eTAG-bit for the photoproduction physics in a wider energy range. P.S. (S.L.,11/03) Something we did not realized on Friday: The main purpose of new s93(ET1) was a sample for the low trigger thresholds control in PD-elements. However, the full E-acceptance of ET-1 is ~2-2.5 GeV. This is not sufficient (too narrow region). May be it worth while to replace it by OR of the two taggers (ET.OR.ET1)? I guess, such a trigger will still provide a reasonable sample also for ET-1 calibration. Another request (to V.A.) - study NOW a sensitivity of ET1-acceptance to the variation of beam conditions Say, compare tilt_x=-0.15mrad (perhaps expected standard conditions for e+ mode in 1995 too) with tilt_x=0 and x-off=+1mm (another extreme, as in fig.3 of our H1 raco paper). 19.03.1995 ========= H1KAND + H1KFOM === Proposal for ET1-calibration Last 2 weeks it were made different attempts to find more or less reasonable ways to produce calibration coefficients for ET1-detector channels and now it is time to proclaim first preliminary results of this work: a) it is proposed possible scenario of future calibration; b) scenario is tested with real data from ET-detector (not ET1) response for energy regions acceptable for this detector. Scenario of calibration is the next: a) it is possible to get for calibration subsample from ET1- triggered events at which 'non-zero' Photon Arm energy is presented. 'Non-zero' energy means energy more then A+n*B where (as example) A=0.09 n=2 and B=0.53 GeV - Mean + 2*sigma - see message at LL8 from 03.03.94 - "Pedestal Distributions" - it means that events with PhotonArm Deposited energy more then 1.1 Gev in principle acceptable for calibration sample; b) CCet2 is most important (as start value for calibration procedure) so it is needed to find its preliminary value from FADCcounts spectra characteristics from et2-channel and predictions of MonteCarlo calculations. As seems start values of all another CCeti it is possible to install on this value too if no any problems with HV-tuning at these 5 ET1-channels; c) it must be found some threshold value for ET1-deposited energy - - ThrA - and only events with ET1 deposited energy more then ThrA will be got for calibration. ThrA is tuning variable for calibration procedure and must be changable or from experts interventions or from some SW Tool; d) for selected with ThrA cut events it is proposed to make very simple way of producing reconstruction energy values as: ET1rec = A*ET1dep + B e) each selected and 'reconstructed' event is using for calibration (energy of Photon Arm is reconstructing with ordinary standard H1REC-package with ETMIN(2)=1.0Gev). Calibration procedure is the same as for ET and PD cells but CCpd and CCvcs are fixed at case of CCet1-cells calibration. For calibration procedure it must be prepared ER(1),ER(2) as values of reconstructed energies at ET1-arm and Photon Arm and ES(1) as value of deposited energy at ET1-cells (sum of GeV-responses of all 6 cells with current CCeti-values); f) current values of calibration coefficients (for Luminosity subbranch) will be presented at each H1-event at LR1P-bank; g) at H1DataFlow it must be presented H1LumiMonitoring events triggered with ET1-trigger element; h) at OffLine Calibration step it is made the same procedure as at OnLine but for events from Photoproduction Subbranch (data will be got from LRE1 and LREP+LRPP BOS-banks); OffLine Step Off calibration is producing Relation Coefficients Set for ET1-cells. These Relation Coefficients set is put into LFRC-bank of H1DataBase and together with possible Global Shift coefficient will be used at new standard H1REC-package for off-line energy reconstruction. High mentioned scenario was tested with some real data with another (less then at ET1) energy region: a) it were selected 2 data samples from ET&PD&VC-full sample of so-called 10C-sample of H1LumiMonitrigs (H1Runs 89877 - 90419). From 89K ET&PD&VC-events it were selected 8558 events with max hitted e22-cell and -5.5cm CCe20 = 5.185 CCe23 = 5.902 CCe29 = 5.180 CCe30 = 4.563 CCe29 = 5.347 CCe30 = 4.563 It were used for calibration 3430 events (from 4248); d) it were built 100th Ntupels with these 'new' CC-values for both A and B-samples. They are kept at next LOOK-binary data sets: H1KFOM.LOOK.R89877.E22.LR.DCH.A FAST02 3010200E 00000 DASD H1KFOM.LOOK.R89877.E22.LR.DCH.B FAST14 3010200E 00000 DASD LR-means Levonian's Reconstruction; DCH - Dead CHannels option,A|B-smp e) it was made calibration step with A-sample events with using of new simple ET1-"reconstruction" and with using of so-called 'weighted' selection of events from A-sample for calibration: ....... * ordinary Lumi event reconstruction CALL LREC * event selection with weight at left side of Edep-spectra IF(ES(1).GT.14.8) THEN CALL SHS(55,0,ES(1)) GOTO 4545 ELSE RRR = H1RN() PXX = exp(-(ES(1)-14.8)**2/3.25) IF (RRR.GT.PXX) GOTO 10 --> goto read next event CALL SHS(56,0,ES(1)) ENDIF 4545 CONTINUE * ET1- energy reconstruction ER(1) = ES(1)*1.05935 + 1.96227 * calibration step which is using ER(1),ER(2) and ES(1) CALL CALIBRA .... As start values it were got values from step (c): CCe15 = 2.675 CCe16 = 4.189 CCe15 = 2.784 CCe16 = 4.187 CCe22 = 5.185 CCe23 = 5.902 ==> CCe20 = 5.145 CCe23 = 5.821 CCe29 = 5.347 CCe30 = 4.563 CCe29 = 5.494 CCe30 = 4.563 It were used for calibration 4053 events (from 8558); f) it was built 100th Ntupel with these 'new' CC-values using for A-sample events. It is kept at next LOOK-binary data set: H1KFOM.LOOK.R89877.E22.BR.DCH.A FAST02 3010200E 00000 DASD BR - means both recontruction are used (standard and new): Standard reconstruction worked with all 'non-dead' channels (exept e48 ETREC keeps value of ETrec from standard package and ETRN keeps value from new (simple) reconstruction or 999. if event was not selected with 'weighted' selection procedure, EDEP keeps deposited energy calculated with new CC for e15,e16,e22,e23,e29,e30 cells). For events with Xet>-5.0 and with ETRN>999. results of calibration are at good agreements: ETrec - mean 17.57 sigma 1.12 (3290 entries) ETRN - mean 17.69 sigma 0.99 (3290 entries) ETrec+PDrec - mean 27.54 Sigma 1.29 (3246+44 entries) ETRN +PDrec - mean 27.55 Sigma 1.36 (3244+46 entries) It is possible to built histo etrec-etrn which keeps values of new reconstruction quality: ETrec-ETRN - mean=-0.367 GeV sigma 0.489 GeV g) it was made attempt to use 'non-weighted' selection of events for calibration (sharp SW threshold) - 14.2 at our case. It were repeated calibration and ntupel-maker steps and results are the next: H1KFOM.LOOK.R89877.E22.BR1.DCH.A FAST02 3010200E 00000 DASD ETrec - mean 17.93 sigma 0.94 (2480 entries) ETRN - mean 17.37 sigma 0.77 (2480 entries) ETrec+PDrec - mean 27.82 Sigma 1.23 (2445+38 entries) ETRN +PDrec - mean 27.45 Sigma 1.21 (2448+35 entries) ETrec-ETRN - mean=-0.005 GeV sigma 0.453 GeV At last step it was used another 'reconstruction' formula: ET1rec= 1.042*ET1dep + 2.087 which was produced from etrec=f(etdep) fit - see H1KFOM.ET22FIT.MACRO - data set. So - for test data 'tuning' variable ThrA was used as 14.8 or as 14.2 for last case. Reconstruction formula (as seems) will be with another coefficients but the same type for real ET1-data. For calibration of ET1-cells it will be used ET1-triggered events with PhotonArm Reconstructed energy >1.0 GeV and with Xet1>-1.7cm (last cut will be defined with ThrA-cut (sharp or weighted) without coordinate reconstruction). May be it will be needed to use additional cut on absolute value of Deposited energy at Right Column(et1+et3+et5)- more then ThrB. At our (test) case e16+e23+e30 - more then 0.85 GeV. 20.03.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development Today it were made new releases of H1LumiOnLineFIC2- and TwinFIC1- program: TwinFIC1...............MPST MPS .....92466 Mon, Mar 20, 10:58 1995 M H1LumiOnLineFIC2.......MPST MPS ....232734 Mon, Mar 20, 18:38 1995 M It was made release of H1LumiOnLineFIC2-program for work with so-called 'back-up' events (for test and debug): H1LumiOnLineFIC2_sim...MPST MPS ....235378 Mon, Mar 20, 18:40 1995 M TwinFIC1slave-program is unchangable during last month: TwinFIC1slave..........MPST MPS .....42412 Mon, Feb 20, 12:57 1995 M Main changings were made at H1LumiOnLineFIC2-program: a) it were realized OnLine part of ET1-cells calibration scenario (see yesterday message at LLC); b) it were removed previous release of ET1-cells calibration; c) it were fixed and removed little bugs at monitoring subroutines; e) it were linked new releases of Egor's subroutines (Monitor.f- family). At TwinFIC1-program it were removed little bugs at initialization step which were the reason of switching-off ET1-calibration at previous releases. At dice2-environment it was prepared data sample with 2300 events from 10C-sample(Runs89877-90419) which were used at ET1-cells calibration tuning. These events were moved through ftp-protocol and are kept at H1Lumi MacII hard disc. All these events were booted into DPM and were used for debugging of OnLine Part ET1-cells calibration scenario. As seems all is OK. Calibration is making permanently and putting into monitoring tools reasonable results. I looked for ETrec+PDrec spectrum with mean 27.43 and sigma=1.34 GeV. It were used both tuning parameters (ThrA=14.2 GeV and ThrB=0.85GeV). As seems sample for calibration is enough clean. For ET1-energy reconstruction (after both cuts) it was used parametrization formula: ET1rec = 1.042*ET1dep + 2.087. Some remark can be made on VCdep-spectrum. This spectrum is finishing at near 8GeV energy (at all last data we looked for 12 GeV as end of more or less significant statistics at VCdep spectrum). OnLine calibration of VCs-channels very stable puts CCvcs into near 3.2Mev/FADCcount value (at OffLine calibration it was fixed CCvcs near 3.9 MeV/FADCcount). May be OnLine calibration of VCs must be corrected or tuned at future. 21.03.1995 ===== OnLine ==== H1KFOM === H1Lumi OnLineSW Tools Status Today it was made attempt to collect into one list all OnLine SW products which are ready on today for working inside H1Lumi OnLine System. Its are working or inside H1Lumi/H1Lumi2 MacIIs or inside some from 3 FICs or inside HERA's MacII or inside ZEUS's MacII: a) ReadOut SW Tools: -------------------- 1) TwinFIC1..............20.03.95 10:55 92466 application (MPW RTF) 2) TwinFIC1slave.........20.02.95 12:57 42412 application (MPW RTF) b) OnLine Luminosity Measurement,OnLine Calibrations, Monitoring and Control Tool: --------------------------------------------------------------------- 3) H1LumiOnLineFIC2......20.03.95 18:38 232734 application (MPW RTF) c) H1Lumi System Monitoring and Control Tools: ---------------------------------------------- 4) sample2...............21.03.95 00:33 92615 application (MPW Pasc 5) T_MonitorNC...........30.04.93 19:52 1399558 SuperCard application 6) BeamProfile...........09.08.94 20:41 157968 application (MacApp) 7) BeamPosition..........03.09.93 17:11 26726 appl.(former DA) 8) Energy_fic1...........15.04.93 13:10 19776 appl.(former DA) 9) Energy_Newb09.........03.09.93 17:12 19570 appl.(former DA) 10) Intensity_b09.........03.09.93 17:13 26103 appl.(former DA) 11) Bunches_hw............03.09.93 17:11 18475 appl.(former DA) 12) NewFastLumiMonitor95..11.11.91 15:17 853632 SuperCard project SharedFile............12.06.90 00:00 505706 SuperCard project 13) beamcurSam (beams currents monitoring) d) Tool for supporting of OnLine Luminosity Measurements: ---------------------------------------------------------- 13) beamcurSam............07.03.95 19:59 50776 application (ThinkC) BeamC.Rsrc............23.04.94 17:53 52909 resource file e) OnLine Luminosity Measurements Presentation and Distribution Tools: ---------------------------------------------------------------------- 14) H1TVLumiMonitor.......01.11.94 22:42 102618 application (ThinkC) LTVmon.Rsrc...........04.07.94 15:25 101304 resource file 15) Lserver4hera..........13.10.94 18:24 46810 application (ThinkC) Lserv.Rsrc............24.05.94 19:39 16140 resource file 16) Lserver4unix..........09.10.94 21:57 46090 application (ThinkC) Lserv.Rsrc............05.10.94 16:24 16073 resource file 17) Lserver4zeus..........27.09.94 02:59 45962 application (ThinkC) Lserv.Rsrc............06.10.94 15:51 16150 resource file 18) HERA_client...........12.03.95 16:00 66822 application (ThinkC) Lclient.Rsrc..........15.03.95 10:36 93836 resource file 19) ZEUS_client...........26.09.94 15:32 66744 application (ThinkC) Lclient.Rsrc..........26.09.94 15:43 95584 resource file f) SlowControl Tools: --------------------- 5) T_MonitorNC (connected with Central SlowControl System - BBL3 alrms 13) beamcurSam (connected with Central SlowControl System - SlowEvent) 20) CAEN..................02.05.94 08:40 126652 SuperCard Project 21) MovablePlatforms......03.02.91 19:10 257344 SuperCard Project P.S. For all SuperCard Project - creation dates are written into list, for all other - last modification dates are written into list. 21.03.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development I decided to involve correction factor on OnLine CCvcs value for using EVETO-energy at ET1-cells calibration. Simultaneously same factor was involved for PDdep and PDrec histos making at LUMM-bank. Value of correction factor is 1.1845 = CCvcs(offline)/CCvcs(online) = = 3.897/3.290. All monitoring tools were corrected too on using corrected EVETO-energy. It was found bug at PDrec-histo making for LUMM-banks (as seems EVETO energy was not involved into PDrec-making).Bug is removed. These are creation dates and program sizes of last releases: H1LumiOnLineFIC2.......MPST MPS ....232940 Tue, Mar 21, 18:57 1995 M H1LumiOnLineFIC2_sim...MPST MPS ....235578 Tue, Mar 21, 19:00 1995 M 21.03.1995 ===== OnLine ==== H1KFOM === LRTN- and LRTF-banks contents After discussion with Igor Sheviakov it became clear that current release of LRTF-bank and LRTN-bank must be described as next: ! BANKname BANKtype !Comments ! TABLE LRTF B16 ! Lumi_Response_Trigger_sums_FADCs ! (presented at each 10th H1 event) ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 NSUMM I 0 3 ! Sum number: 0,1,2,3 for PD,ET, ! ET1 and ET2 2 PULS12 I 0 65535 ! 1st and 2nd bins of NSUM FADC window ! packed into B16; high byte - 1st, low ! byte - 2nd; 3 PULS34 I 0 65535 ! 3rd and 4th bins of NSUM FADC window 4 PULS56 I 0 65535 ! 5th and 6th bins of NSUM FADC window 5 PULS78 I 0 65535 ! 7rd and 8th bins of NSUM FADC window 6 PULS910 I 0 65535 ! 9th and 10th bins of NSUM FADC window LRTN-bank (a little) must be changed too: ! BANKname BANKtype !Comments ! TABLE LRTN B32 ! Lumi_Response_Trigger_moNitoring ! (presented at each 10th H1 event) ! ! ATTributes: ! ----------- !COL ATT-name FMT Min Max !Comments ! 1 LCTOT I 0 +INF ! Total Luminosity Counter 2 LCBUNCH I 0 +INF ! Current Bunch Luminosity Counter 3 LTIME I -INF +INF ! Local Time Scaler (units = 1/2950 sec) 4 LTEFF I 0 1000 ! Luminosity Trigger Efficiency(in 0.1%) 5 TLUMI I 0 +INF ! Current Total Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 6 BLUMI I 0 +INF ! Selected Bunch Luminosity Value ! (averaged over the last 5 sec., in ! units of 10**25 cm-2s-1) 7 TBP I 0 +INF ! Trigger Bits status at Previous BC 8 TBC I 0 +INF ! Trigger Bits status at Current BC 9 TBN I 0 +INF ! Trigger Bits status at Next BC 10 EPD I 0 20001 ! L1 trigger Energy in PD (FADC counts) ! EPD = 20000 in case of overflow ! EPD = 20001 in case of zero-pedestal 11 EET I 0 20001 ! L1 trigger energy in ET (FADC counts) ! EET = 20000 in case of overflow ! EET = 20001 in case of zero-pedestal 12 EET1 I 0 20001 ! L1 trigger Energy sum ET1 (FADC counts ! EET1 = 20000 in case of overflow ! EET1 = 20001 in case of zero-pedestal 13 EET2 I 0 20001 ! L1 trigger Energy sum ET2 (FADC counts ! EET2 = 20000 in case of overflow ! EET2 = 20001 in case of zero-pedestal 14 Spare I -INF +INF ! Spare word ET+PD Trigger Sum disappeared forever (as seems) and on its place at FADC-channel ET1-trigger sum is placed. FADC-channel which was supposed for using ET1-trigger sum can be used for ET2-trigger sum at future. 14th word at LRTN-bank is free now. 24.03.1995 ================= H01LNS === "tool(s)" for L4 LUMI "ALARM" The "tool" for L4 LUMI "ALARM": The subroutine "lhalar.f" was written, debugged and tested at dice2. It is designed for a *minimal automatization* of the L4 Lumi Control. It is using the L4 system for sending "ALARM" messages to H1 console. It should now be incorporated into the L4 software, at the MIPS firm. A short description of this "tool" see at the bottom of this LLO. At the bottom there are also the examples of the ALARM messages. The full fortran text see at the dice2: ~shtarkov/L45/lhalar.f See also the modified S.L.'s S/R at dice2: ~shtarkov/L45/lummon.f Some comments, in addition to the short description: * This job was started following some old proposals of S.Levonian, but to-day, probably, it is out-of-date or not useful at all. * It is no more, but an attempt to realize some *minimal facilities* for L4 LUMI control automatization, to gain some first experience. * The "lhalar" is using, as the basis, the S.L.'s L4 tool "lummon", it is called from "lummon", and is using histos made in "lummon". * The original "lummon" is added with some commons and two calls. Presently, the S.L.'s packet of L4 Histos has not been changed. * The chain dice2+Unix+MIPS_firm does not make anybody to be happy: L4 specific means at dice2 were used for debugging of "the tool", the means of L4 MIPS firm were imitated at dice2 with L4 software. The MIPS histograming packet was used, for a real work at L4 firm. * There are some evident points where "lhalar" *is to be improoved*. It is time to ask S.Levonian *to take decision of the next steps* and if it is decided positive, *to help* in the possible next steps: * By checking "the proposed tools" by eyes, for any kind of errors. * In incorporating(CMZ) "the new tools" into L4 LUMI at the L4 firm. * In checking performance of ALARM at MIPS firm at real Lumi Runs. For the next steps *beyond* the made "minimal version" of ALARM: * There has been made some other "tool" for L4 LUMI ALARM, that was also written, debugged and tested - S/R "lbalar". * It is designed for the ALARM messages in a different situation, when some % of LUMI *banks* is lost, comparing to LUMI triggers. * It does not make use of the ready made histos from the "lummon", but, at present, it is highly overlaied with "lummon" in code, and it is not yet cosmetically combed. * It is well working with "lummon" and "lhalar", see Example print. Nevertheless, it's better *firstly* to check the above "lhalar". * The not yet done task is adding of the new ET-44-tagger, which is better to realize *inside* the S.L.'s "lummon". * As for me, I would change the "lummon" a little more, as practically is done inside the "lbalar", and etc. Unfortunately or fortunately, all this tricky ALARM busyness is not important comparing to everyday making of Luminosity values. L.Shtarkov, DESY, 23.03.95. 24.03.1995 ================= H01LNS === short descr. of ALARM S/R .. A short description of S/R lhalar.f, taken from the full text of S/R. *********************************************************************** * SUBROUTINE Lumi_*Histos*_ALARm * Purpose: L4 LUMI monitoring and testing Histos for ALARM. * In cases of ALARM, message is sent to the H1 display consol. * * S/R is called from L4_lummon (S.Lev.), at init and events. * Some commons, and are added to the lummon. * Testing for ALARM is done for the Histos, made in lummon. * Not all of the L4_Lumi_Histos are tested, only significant. * S/R is working (inside) *not* for all the events, but only * after accomulating of the_Number_of_events_in_Run.GE.NEVMIN * The large value of NEVMIN makes negligible spending of CPU. * * ALARM is tested presently for two Lumi detectors, ET & PD, * and for three types of Histos - distributions on Channnels, * Energies, and Overflows, for each detector correspondently. * For testing, the parameters of accomulated Histos are used. * The main criterium of sending ALARM is a dangerous value of * "deviation of Mean calculated in units of accuracy of Mean" * i.e., [(Mean - Const.1) / (St.dev./sqrt(Nev))] > (Const.2). * * The best way of getting Const.1 would be *on-line* reading * from Reference_Histos, but this is not accessible at the L4. * The *used values of Const.1* are taken from histos by hand: * For the sum of Energies, (ET+PD), it is well known e_beam_E, * for splitted cases, ET and PD, it depends on the background. * * Only the cases of "heavy alarms" are selected via constants: * the minimal value of NEVMIN is proposed to be = 1000 events, * the alarm value of Const.2 is proposed = 10 st.deviations(!) * For ET or PD this correspondes to St.dev./sqrt(NEV) ~0.3GeV * and the ALARM is to be sent at delta(E) ~(0.3GeV *10)~3.GeV. * For (ET+PD) the ALARM is to be at delta(E) ~1/6 *Peak_Width. * In most cases, such a big delta(E) is really "a heavy alarm" * * Multiple Zero-values for ET/PD/VC Energies are well ALARMed. * Single "holes" in channel distribution are not well spotted. * * The used constants and their meaning are printed at the init. * The change is possible 1000->10000 events and 10->5 st.dev's. * There is a Debug variant for the constants (chousen by hand). * * For ALARM, CALL YELL(NNN,'LUMI_message_of_ALARM') is used, * for NNN, the ID_values of the alarmed L4 Histos are used. * The deck is entitled with +SELF,IF=MIPS., for it uses MIPS. * * This S/R was debugged in the frames of the L4's h1filter, * and checked on the files HERA03.H01.LUMIMON.C9400109, etc. * At selection of > 3 st.dev's, for Runs of > 100 events, * from ~20 random LUMIMON event cartriges, there were ALARMed * a few "defective" files, having correlated ALARMes per file. * *:L.Shtarkov, LPI: 01.03.1995 started * xx.03.1995 ... ********************************************************************** 24.03.1995 ================= H01LNS === example print of ALARM S/R . Example print of the significant CONSTANTS of the ALARM S/R lhalar. ********************************************************************** lHalar: INIT of CONSTANTS to control ALARM lHalar: INIT was done for DEBUG values of Cs and "~ok" below not valid NEVMIN = 120 ~ok MIN_Lumi_Nev_in_RUN to TEST the_RUN for ALARM ALALB = 1.00 ~ok LOSS_of_BANK/Lumi_Nev (%) to make alarm: lHalar OVERMAX = 0.01 ~ok OVERflow_MAX (%) to make alarm for ET_OVERflow OVERMAX = 0.01 ~ok OVERflow_MAX (%) to make alarm for PD_OVERflow AVCETCH = 23.00 ??? Average(Mean)_Energy to make alarm for ET_CHann SDMETCH = 3.00 ~ok N_of_Standard_Dev. to make alarm for ET_mean_CH AVCPDCH = 14.50 ??? Average(Mean)_Energy to make alarm for PD_CHann SDMPDCH = 3.00 ~ok N_of_Standard_Dev. to make alarm for PD_mean_CH EEBLUMI = 27.00 ~ok ? Average(Mean)_Energy to make alarm for ET+PD_E SDMLUMI = 3.00 ~ok N_of_Standard_Dev. to make alarm for ET+PD_E EAVETAG = 18.50 ??? Average(Mean)_Energy to make alarm for ETAG_E SDMETAG = 3.00 ~ok N_of_Standard_Dev. to make alarm for ETAG_E lHalar: INIT of CONSTANTS is ENDED===================================== Example print of the ALARM massages(short'd), ALARM S/R lbalar+lhalar. ********************************************************************** Here messages were a little shortened, from 80 to ~72, for the LLO. BOSINPUT [h1stage.h1]HERA03.H01.LUMIMON.C9400109 LUMI_BANK_ALARM ET R=88357 N=313 ET____BANK_loss: 2.% > 1.% LUMI_BANK_ALARM PD R=88357 N=313 ___PD_BANK_loss: 3.% > 1.% LUMI_BANK_ALARM VC R=88357 N=313 VC____BANK_loss: 3.% > 1.% LUMI_hist_ALARM PD R=88357 N=313 PD____overflow: 0.27%>0.01% H=18521 LUMI_hist_ALARM ET R=88357 N=313 ET____meanCH_err: -6.sd > 3.sd H=18515 LUMI_hist_ALARM PD R=88357 N=313 PD____meanCH_err: -4.sd > 3.sd H=18525 LUMI_hist_ALARM Et R=88357 N=313 ETAG__mean_E_err: -7.sd > 3.sd H=18535 LUMI_BANK_ALARM ET R=88364 N=126 ET____BANK_loss: 4.% > 1.% LUMI_BANK_ALARM VC R=88364 N=126 VC____BANK_loss: 13.% > 1.% LUMI_hist_ALARM PD R=88364 N=126 PD____overflow: 0.15%>0.01% H=18521 LUMI_hist_ALARM ET R=88364 N=126 ET____meanCH_err: -6.sd > 3.sd H=18515 LUMI_hist_ALARM PD R=88364 N=126 PD____meanCH_err: -5.sd > 3.sd H=18525 LUMI_hist_ALARM Et R=88364 N=126 ETAG__mean_E_err:-11.sd > 3.sd H=18535 LUMI_BANK_ALARM ET R=88435 N=351 ET____BANK_loss: 10.% > 1.% LUMI_BANK_ALARM PD R=88435 N=351 ___PD_BANK_loss: 42.% > 1.% LUMI_BANK_ALARM VC R=88435 N=351 VC____BANK_loss: 51.% > 1.% LUMI_BANK_ALARM EP R=88435 N=351 ET*PD_BANK_loss: 53.% > 1.% LUMI_hist_ALARM PD R=88435 N=351 PD____overflow: 0.10%>0.01% H=18521 LUMI_hist_ALARM PD R=88435 N=351 PD____meanCH_err:-12.sd > 3.sd H=18525 LUMI_hist_ALARM EP R=88435 N=351 ET+PD_mean_E_err: -9.sd > 3.sd H=18534 LUMI_hist_ALARM Et R=88435 N=351 ETAG__mean_E_err:-13.sd > 3.sd H=18535 24.03.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development It were made little changing at default values of ThrA and ThrB for ET1-cells calibration procedure: ThrA = 19.1416 GeV (before today 14.2 GeV) ThrB = 1.1458 GeV (before today 0.85 GeV). These are creation dates and program sizes of last releases: H1LumiOnLineFIC2.......MPST MPS ....232960 Fri, Mar 24, 18:04 1995 M H1LumiOnLineFIC2_sim...MPST MPS ....235698 Wed, Mar 22, 10:50 1995 M Last (sim_labeled) program was tested with 2300 events from ETPDVC- 10C-sample with tuned scaling factors for ET1-and PD-deposited energies (1.348 for ET1-arm and 0.3585 for PD-arm) and it were produced next values at OnLine Monitoring histos for "quasi"-ET1&PD&VC-events: ET1dep (mean=21.04, sigma = 0.94 GeV)-assimetrical distribution (due to ThrA); PDdep (mean= 2.10, sigma = 0.53 GeV) VCdep (mean= 1.20, sigma = 0.64 GeV)-3 GeV energy last statist. ET1"rec" (mean=24.02, sigma = 1.00 GeV)-assimetrical distribution (due to ThrA); PDrec (mean= 3.40, sigma = 0.45 GeV) (VCdep included); ETdep+PDdep+VCdep (mean=24.36, sigma = 1.03 GeV); ET1rec+PDrec (mean=27.43 GeV, sigma = 1.06 GeV) (VCdep included). For compare these are digits for ET&PD&nVC-events (10C-sample): ETdep (mean=15.82, sigma = 3.24 GeV) PDdep (mean=12.17, sigma = 2.94 GeV) VCdep (mean= 0.12, sigma = 0.00 GeV) (nVC-triigered events); ETrec (mean=14.59, sigma = 3.07 GeV) PDrec (mean=12.87, sigma = 3.05 GeV) ETdep+PDdep (mean=27.99, sigma = 1.32 GeV) ET1rec+PDrec (mean=27.46 GeV, sigma = 1.03 GeV). Put Your attention again on mean(ETdep+PDdep)>mean(ETrec+PDrec) (!) mainly due to mean(ETdep)>mean(ETrec). 01.04.1995 ================= H1KFOM === Summary of e+p94 Calibrations It were made H1Lumi 15 calibrations for e+p94 data at last year (for data from 1531 G+M H1Runs).Motivations for making of any samples for calibration were different: a) mainly OnLine CCp11 'jumps': 5A -> 5B due to CCp11 was changed from 4.2 to 2.0 MeV/FADCcount; during Run 84025 - near 08:45 at 09.08.94; 5B -> 6A due to CCp11 was changed from 2.0 to 4.4 MeV/FADCcount; between LumiRuns - from 10:45 up to 12:16 at 12.08.94; 6B -> 7A due to CCp11 was changed from 4.5 to 2.1 MeV/FADCcount; between LumiRuns - from 09:04 up to 19:22 at 04.09.94 7D -> 8A due to CCp11 was changed from 2.2 to 4.2 MeV/FADCcount; during Run 87301 - from 13:44 up to 14:20 at 19.09.94; 8A -> 8B due to CCp11 was changed from 4.2 to 2.2 MeV/FADCcount; during Run 87458 - near 15:00 at 21.09.94; 8B -> 8C due to CCp11 was changed from 2.2 to 3.8 MeV/FADCcount; during Run 87526 - near 11:30 at 22.09.94; 8C -> 8D due to CCp11 was changed from 3.8 to 4.3 MeV/FADCcount; between LumiRuns - from 16:12 (22.09) up to 06:48 at 23.09.94; 8D -> 8E due to CCp11 was changed from 4.3 to 4.0 MeV/FADCcount; between LumiRuns - from 14:48 (23.09) up to 01:27 at 25.09.94; 8E -> 9A due to CCp11 was changed from 3.9 to 2.2 MeV/FADCcount; between LumiRuns - from 08:20 up to 19:35 at 29.09.94 9A -> 9B due to CCp11 was changed from 2.2 to 4.5 MeV/FADCcount; between LumiRuns - from 11:43 (03.10) up to 05:31 at 04.10.94; 9B -> 9C due to CCp11 was changed from 4.5 to 4.7 MeV/FADCcount; between LumiRuns - from 05:02 (05.10) up to 20:59 at 06.10.94; b) all another samples were fixed due to collection of enough statistics 6A,7A,7B,7C,9C,10A,10B or with end of data taking - 10C; Short characteristics of each sample is seen from next table: 1 2 3 4 5 6 7 8 9 10 11 ---------------------------------------------------------------------- 1. 5A 31.07-09.08 83230-84024 145 27177 27.51 0.93 0.06 0.15 -0.54 ----- at this time was changed from 0. to -2.0cm ------------- 2. 5B 09.08-12.08 84026-84295 37 11252 27.55 0.95 0.08 0.16 -1.36 3. 6A 12.08-29.08 84300-85671 201 50581 27.54 0.95 0.08 0.19 -1.60 4. 6B 29.08-04.09 85699-86160 82 30169 27.50 0.93 0.11 0.21 -1.64 5. 7A 04.09-08.09 86207-86607 70 31515 27.53 1.01 0.13 0.25 -1.56 6. 7B 08.09-11.09 86607-86799 66 35843 27.54 1.01 0.10 0.22 -1.66 ----- at this time VC-setting was changed on VC-front sensetive ---- 7. 7C 11.09-15.09 86799-87054 57 25039 27.51 1.05 0.22 0.60 -1.67 8. 7D 15.09-19.09 87054-87249 87 66560 27.50 1.04 0.32 0.67 -1.55 9. 8A 19.09-21.09 87314-87457 37 25224 27.51 1.04 0.29 0.75 -1.50 8B 21.09-22.09 87459-87526 22 14438 27.55 1.06 0.29 0.50 -1.64 8C 22.09-22.09 87533-87556 9 3872 27.57 0.98 0.27 0.52 -1.49 8D 23.09-23.09 87586-87610 20 3392 27.55 1.10 0.29 0.54 -1.52 10. 8E 25.09-29.09 87697-88022 102 56014 27.56 1.03 0.30 0.68 -1.67 11. 9A 29.09-03.10 88082-88320 52 23645 27.48 1.07 0.33 0.84 -1.55 9B 04.10-05.10 88358-88473 12. 9C 06.10-10.10 88669-88877 117 70532 27.56 1.04 0.30 0.81 -1.56 13. 10A 10.10-16.10 88877-89264 118 105646 27.53 1.05 0.30 0.71 -1.53 14. 10B 16.10-24.10 89264-89877 110 52568 27.36 1.00 0.31 0.97 -1.57 15. 10C 24.10-01.11 89877-90419 195 56876 27.45 1.01 0.29 0.99 -1.48 ---------------------------------------------------------------------- total 31.08-01.11 83230-90419 1531 690397 27.50 1.01 0.24 0.68 -1.53 ---------------------------------------------------------------------- where 2 - sample 'name'; 3 - time period of data collection dd.mm(start)-dd.mm(finish); 4 - G+M H1Run range (data from these Runs were got for calibration); 5 - Number of G+M Runs at Data Sample; 6 - Number of ET&PD&nVC-events at G+M H1Runs at Data Sample; 7 - ETrec+PDrec spectrum mean value(LOOK peak finder, bins 200 22 32, abs(Xet)<6.0cm&EVeto<0.2GeV) - for ET&PD&nVC-sample; 8 - ETrec+PDrec spectrum sigma value(LOOK peak finder, bins 200 22 32, abs(Xet)<6.0cm&EVeto<0.2GeV) - for ET&PD&nVC-sample; 9 - Eveto spectrum mean value (STATPARM, standard 30th histo at LREC) for ET&PD&nVC-sample; 10 - Eveto spectrum sigma value (STATPARM, standard 30th histo at LREC) for ET&PD&nVC-sample; 11 - Xpd spectrum mean value (STATPARM, X-projection of 23rd standard histo at LREC) for ET&PD&nVC-sample. P.S. All digits were produced with using of latest official release of LREC-package (it was got from H1REC 06.00/15 cmz-file). Relation Coefficients, CCvcs and Global Shifts were got from H1 Data Base as it is ordinary making at official LREC-package. 01.04.1995 ================= H1KFOM === Cells Response Degradation... It were produced set of vectors with dependence of OnLine produced Calibration Coefficients values from time for all 93 day period of e+p94 data taking (from 31.08.94 up to 01.11.94). From looking for on this vectors it is possible to make next preliminary conclusions: 1) all ET hot cells Calibration Coefficients permanently incremented with different factors - it means that decrementions of its responses are seen; 2) all PD hot cells Calibration Coefficients were more or less stable (exept p06,p11 and p13) during 93 days period; CCp06,CCp11 and CCp13 permanently incremented its average values with different factors; 3) CCp11 had greatest factor of incrementing from all looked for cells. Up to this moment next factors were produced (at percents from start values for 93 days period): e28=13.8% e29=10.2% e30= 7.4% e21=12.2% e22= 4.6% e23=12.3% e24= 7.9% e25= 4.5% e26= 6.9% e27= 8.3% e14= e15= e19= p16= 0.0% p17= 0.0% p10= 0.0% p11=16.9% p12= 0.0% p13= 7.1% p06=12.2% p07= 0.0% These response degradation factors can include darkness of crystalls or photomultiplier degradation or something else. You can see these vectors at the next LOOK-binary data sets at DESY IBM storage: vector number H1KFOM.LOOK.ETPDNVC.E14.POSITR.Y94 2214 FAST04 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E15.POSITR.Y94 2215 FAST04 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E19.POSITR.Y94 2219 FAST08 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E21.POSITR.Y94 2221 FAST01 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E22.POSITR.Y94 2222 FAST08 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E23.POSITR.Y94 2223 FAST01 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E24.POSITR.Y94 2224 FAST09 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E25.POSITR.Y94 2225 FAST01 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E26.POSITR.Y94 2226 FAST08 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E27.POSITR.Y94 2227 FAST03 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E28.POSITR.Y94 2228 FAST04 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E29.POSITR.Y94 2229 FAST08 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.E30.POSITR.Y94 2230 FAST14 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P06.POSITR.Y94 2406 FAST09 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P07.POSITR.Y94 2407 FAST14 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P10.POSITR.Y94 2410 FAST04 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P11.POSITR.Y94 2411 FAST09 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P12.POSITR.Y94 2412 FAST09 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P13.POSITR.Y94 2413 FAST04 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P16.POSITR.Y94 2416 FAST08 3010200E 00000 DASD H1KFOM.LOOK.ETPDNVC.P17.POSITR.Y94 2417 FAST13 3010200E 00000 DASD Vector 2425 with CCvcs-changing with time is kept at: H1KFOM.LOOK.ETPDNVC.VCS.POSITR.Y94 2425 FAST01 3010200E 00000 DASD All these LOOK-binary data sets are enough large - near 5.Mbyte. As time scale at all early mentioned vectors it was used the event number at ET&PD&nVC-sample (from 0 up to 690397). If somebody interests with H1Run Number =f(Event Number at sample) one can see data set: H1KFOM.POSITR.Y94 FAST03 3010200E 00000 DASD With using of this data set it is possible to make any zoom for looking for more detail on CC-behaivour inside LumiRUN,time period etc. 03.04.1995 ================= H1KFOM === First HERA e+beams 95 ....... As it was promised at this weekend HERA e+beam program of this year had started. More or less long living e+beam was observed today morning from 07:05 up to 10:21. Ee+=12 GeV, Ie+max =3.0 mA, 2 zugs with bunch triplets were injected. From 08:20 up to 10:21 it was proclaimed "Machine Studies" with this beam. Beam currents are receiving with H1Lumi from H1Ctrig, Black-White TV screens are reflecting now status of H1Lumi and VetoWall detector rates Lserever4HERA and Lserver4unix are operated at H1Lumi MacIIs. Our Movable Platforms are at working position now. Luminosity branch had involved from yesterday into H1CDAQ readout. Currently set of H1Runs is wriiten for Storage Tek testing (H1Runs around 97877). 03.04.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development It were made new releases of programs for FIC2. Only two changings are made in compare with previous releases 24.03.95: 1) it was involved last Egor's updating of Monitor.f-subroutine; 2) it was realized proposed by S.Levonyan (and proclaimed by Nelly at H1 Data Quality Meeting 28.03.95) changing of units for Integrated Luminosity values at LRTL-bank: 233 RUNLUMI I 0 +INF ! Total Integrated Luminosity from the ! beginning of the run ! (in units 10**27 cm-2 = 1.0 mb-1) 234 RH1LUMI I 0 +INF ! H1 Integrated Luminosity from the ! beginning of the run (during H1active) ! (in units 10**27 cm-2 = 1.0 mb-1) These are creation dates and program sizes of last releases: H1LumiOnLineFIC2.......MPST MPS ....233244 Mon, Apr 03, 12:16 1995 M H1LumiOnLineFIC2_sim...MPST MPS ....235938 Mon, Apr 03, 12:15 1995 M 03.04.1995 ===== OnLine ==== H1KFOM === Run 97882 (Random Trigger) Today it was written Run 97882 with Luminosity branch involved into H1CDAQ-operation. Run was written with Random trigger and disposed at HERA04.H1RAWD.C9500177 permanent data set. Beams were absent at this period (from 13:31 up 13:42), HV was ON at H1Lumi Detectors, 5723 events. Data from this Run are good sample for pedestal distribution investigation without beams. = -0.250 GeV; Sigma = 0.950 GeV; = -0.096 GeV; Sigma = 0.425 GeV; = -0.029 GeV; Sigma = 0.078 GeV. LOOK peak finder,bins 200 -5 5 (for ETdep and PDdep), bins 25 -0.5 0.5 for VCdep. It were used Relation Coefficients and CCvcs from 10C-sample 03.04.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development It was made new release of program for FIC1_Master. It were removed all write-lines at TermRunSub.f,StopRunSub.f and main-program which can appear simultaneously with interrupt appearence. Current H1Shift crew (P.Biddulph and E.Wunsch) reported that twice at their shift Luminosity branch was crashed with COPE-exeption reason during night H1CDAQ-stability tests. Today it was found that reason of COPE- exeption at library-subroutine: PREIO (Input/Output library). These are creation date and program size of last release: TwinFIC1...............MPST MPS .....89182 Mon, Apr 03, 17:19 1995 M 04.04.1995 ================= H1KFOM === HERA e+beam Activity ....... HERA e+beam program alived again yesterday near 17:20. During 1.5 hours only 3 bunch beam current was studied with Ie+tot not more then 0.3mA. From 20:40 yesterday up to 06:55 today morning it was fixed 9 e+beam injections and during last 6 injections it were made attempts to make rampings of e-ring. e+beam lived not more then 15 min after starts of ramping. Ie+max was not more then 2.5 mA. Bunch structure was the same as at first e+beam filling (19 bunch triplets with 6 empty bunches between each triplet). Energy monitoring histo shows that 27.52 GeV energy was not achieved (if our calibration is more or less right now). After midnight at the end of longest e+filling which was satrted near 22:15 and finished near 0:58 after midnight I.Sheviakov wrote first H1Runs with s93 triggers (VC=1) - 97979-97981(permanent data sets HERA04.H1RAWD.C9500179-182. Not only Lumi and CTRIG were involved into H1CDAQ - so not more then 15K events per 400MB cartridge. 2K + 23K + 28K VC(front sensetive) triggered events were written at high mentioned Runs. Ee+=12 GeV ,Ie near 2.6mA at start of Run 97979, New Trigger element set was used (as it was wrote at S.Levonian's message - PD2,PD1,ET44,ET,PD,VCv1,Etag=ET*nPD1,NC. Thresholds values (see LUTR-bank contents): VCv1=0.75 GeV, PD=2GeV, PD1=2.25GeV,PD2=10GeV,ET=4.5GeV,ET44=3GeV (12 Gev options). H1CTRIG-synchronization was from e-beam - at this case we ordinary look for another FADC shifts (near 20-30 nsec delayed). At all high mentioned Runs FADC shifts were installed on default values - ET FADCs have shifts 143 (Ph.Br.) and 91 (Lumi Br.) PD FADCs have shifts 199 (Ph.Br.) and 147 (Lumi Br.) NC FADC has shift 140 (Ph.Br.) for ET44 FADCs channels: - for Photoproducrion branch 153 - for Luminosity branch 101 P.S. First evidences from Egor's OnLine Monitoring - more or less "large" responces at ET44-cells existed at et02 and et05 - as seems reasonable "large" response disposition must be et02/et04 High voltage tuning at et04-connected HV-source puts effect on et05-response and vice versa et05 HV puts effect on et04-response. It means that there is some errors with connection HV-channels on ET44 and (may be) with connection ET44-channels on FADC-inputs. 04.04.1995 ================= F11LEV === New e-tagger response....... It would be useful to get at least a rough coordinate distribution for ET44, to see how it is installed w.r.t. the median e-plane. Since it is not movable, it will be it's permanent position, which is important for the simulation purposes. Of course, x-y plot has only sense, if channel mapping is correct (see warning from A.F. in the previous message), and if ET44 is included in LREC. The second item is still behind (my fault), but I will try to prepare a first reasonalbe version of revised LREC for 1995 within coming few days. Here I would like to remind, that it is a responsibility of V.Andreev (in a first order) to look into the real data, related to new tagger AND TO REPORT on the results in LLO !!! Please, do not forget to do it regularly. 04.04.1995 ================= H1KSHE === Calibration data ............ As i'v just being informed by runcoordinator, a stabel e+ beam could be available since 23 h this night. It means we can have a chance to adjust roughly the system and take the calibration data. 05.04.1995 ================= F11LEV === Luminosity information in WWW A first complete version of lumi information in WWW is ready and installed. According to our discussion ~ month ago, there are two roots of the Lumi info in WWW: a) accessible for everybody b) reserved for the internal H1 use. In order to see what has been implemented, start from ether H1 home page and click on H1 luminosity (in the line Status of ...) or go to the H1 Physics Working groups page and inspect the Luminosity section. Your suggestions for further improvements, as well as corrections of possible errors, are HIGHLY WELCOME! Note, the following: 1) please, avoid duplication (and multiplication) of information! The source MUST be unique. There could be many links to it, such that one can access the same information from several places, but the ORIGINAL sourse must be just one. Otherwise, inconsistencies will definitely appear and will confuse people. 2) Online information should be regularly updated. Sir "Online Manager", please look after that. 07.04.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development It were made new releases of program for FIC1_Master and for FIC2. It was made only one changing. FADC shifts for ET44-channels were changed on new values: FADC shift for ET44 at Photoproduction branch became 190 (ET = 199, PD = 143), FADC shift for ET44 at Luminosity branch became 138 (ET = 147, PD = 91). These are creation dates and program sizes of last releases: TwinFIC1...............MPST MPS .....89182 Fri, Apr 07, 10:00 1995 M H1LumiOnLineFIC2.......MPST MPS ....233264 Fri, Apr 07, 09:51 1995 M 07.04.1995 ================= H1KFOM === HERA e+beam Activity ........ HERA e+beam activity alived again yesterday at 20:40 and was continued up to today morning 08:40 with injections of enough large beam currents (up to 25 mA). Machine studies were made with Ee=27.52 and with 12 GeV energies. Beam conditions were bad for making of attempts to calibrate our detectors - we did not see good bremstrahlung events at H1Lumi detectors. Promised stable e+beam from 03:00 up to 06:00 tonight was with bad beam conditions. 09.04.1995 ================= H1KFOM === First LUMIMON'95 ............ Today I found at /acs/data/95/spec directory at dice2 first LUMIMON data set which was recorded at this year. Number of events - 225239. H1Run Range 92467-97981. Data collection from less then 16.01.95 up to 04.04.95. Data at this cartridges (exept last 3 H1Runs - 97979-97981 which were recorded with 12 GeV e+beam and with 'non-right' FADC shift) are not-connected with H1Lumi at all. As seems main statistics at this data set was written inside cosmic Run period (from 23.03.95 up to 31.03.95) when our STC-card was used with some another branch (and - may be - our trigger elements at TEL1-bank were used with another branch too). 10.04.1995 ================= H1KFOM === Run 98879 ................... Today Run 98879 which was recorded on Storage Tek cartridge was moved into dice2-storage and us appeared at HERA04.H1RAWD.C9500205 permanent data set. It was H1Lumi Dedicated Run with all H1Lumi monitoring triggers (s92 was as et44). Prescale Gaps were not tuned so there are some rare triggers and some often triggers (especially et44). I did not remember which energy of Ee+ was at this period at HERA. Ie+ was enough large - near 11mA. Run was written 07.04.95 near 11:44-11:56. Beam conditions were bad. It were installed 'right' FADC shifts for all detectors (shifted on 20 nsec due to e-beam synchronization). It was first H1 Run with right FADC shifts for ET44-channels. It is possible to see shapes of pulses at all channels (Mode 1 was switched on). Trigger Sums are looking for as resonable and have corelations with ETdep,PDdep and ET44dep. Some remark it is possible to make on ET44dep-distribution - there are some 'double' distributions near 24 GeV and after 100 GeV as some 'echos' or something else. It is not understandable yet. et04 and et05 as seems really are disposed vice versa. Some histos and 100ntuple of events from this Run it is possible to find at LOOK-binary data set: H1KFOM.LOOK.R98879 FAST08 3010200E 00000 DASD which is kept at DESY IBM storage. 11.04.1995 ================= H1KFOM === Third LUMIMON'95 ............ Yesterday I found at /acs/data/95/spec - directory at dice2 new LUMIMON-data set (HERA03.H01.LUMIMON.C9500003). 2nd LUMIMON data set is not appeared yet. This LUMIMON-data sets consists of 88268 events and includes 14 Runs (from 98334 up to 98879). Time period of filling is from 05.04.95 10:40 up to 07.04.95 11:50. Only 2 H1Lumi Dedicated Runs got main statistics at this data set: part of Run 98334 (34Kevents and part of Run 98879 (first 53K events). Run 98334 was written during Ee+=27.52 GeV ('right' FADC shifts for ET and PD - shifted on 20 nsec - and 'non-right' FADC shift for ET44- channels). Run 98879 was written during Ee+=12 GeV and with all 'right' FADC shifts for all H1Lumi Channels. Run 98334 was written with s91 and s93 active subtriggers. Run 98879 - with all H1Lumi monitrig (but with bad prescale gaps - due to imposibility to tune its). Both Runs were recorded with bad beam conditions. 11.04.1995 ================= H1KFOM === Second LUMIMON'95 ........... Today afternoon 2nd LUMIMON'95 had appeared at dice2 storage: (HERA03.H01.LUMIMON.C9500002) (one day later then 3rd LUMIMON). This LUMIMON-data sets consists of 97409 events and includes 13 H1Run (from 97981 up to 98334). Time period of filling is from 04.04.95 00:58 up to 05.04.95 10:50. Only 2 H1Lumi Dedicated are disposed at this data data set: part of Run 97981 (24Kevents) and part of Run 98334 (72K evn) Run 97981 was written during Ee+=12.0 GeV ('non-right' FADC shifts for ET and PD and 'non-right' FADC shift for ET44-channels. S91-bit only. Run 98334 was written during Ee+=27.52 GeV and with 'right' FADC-shifts for ET and PD and 'non-right' for ET44. Run 98334 was written with s91 and s93 active subtriggers. Both Runs were recorded with bad beam conditions (only for prelimina- ry investigation, not for calibration). 12.04.1995 ================= H1KFOM === Run 98879 ................... It was made else one LOOK-binary data set for events from H1Run 98879 (near 103 K events). It is kept at DESY IBM storage and ibcludes 100th ntupel of the next structure: NAM(1)='ET0' - FADC-response of et0-channel NAM(2)='ET1' - FADC-response of et1-channel NAM(3)='ET2' - FADC-response of et2-channel NAM(4)='ET3' - FADC-response of et3-channel NAM(5)='ET4' - FADC-response of et4-channel NAM(6)='ET5' - FADC-response of et5-channel NAM(7)='ET1D'- GeV-response of et0+et1+..+et5 (CCe44-'non-right') NAM(8)='RUN' - Run number NAM(9)='ET1T'- Trigg. sum for ET44 (FADC counts) NAM(10)='TE' - IETag+IVC*2+IPD*4+IET*8+IET44*16+IPDlow*32+IPDhigh*64 - or 128 (if there is no TEL1,1-bank at event) NAM(11)='TB' - IS95+IS94*2+IS93*4+IS92*8+IS91*16+IS86*32 - or 64 (if there is no TLV1-bank at event-Random Trigg) CALL BNT (100,0,NVEC,NAM) Data set name which includes this 100th ntupel is: H1KFOM.LOOK.R98879A FAST01 3010200E 00000 DASD From analyze of 100th ntupel-contents it became clear that the reason of early mentioned 'double', 'echoes' collections at ET1D-distribution is presence of 20001-signs (zero pedestals) at cells responses (You can look its Yourself at ETi-columns of 100th ntuples). At nearest time I shall remove the making of this signs at OnLine program. Distribution of ET2 is looking for as 2 peaks distribution. Nature of nearest to zero peak - as seems electrons with impact point near boundary, second peak (with more large deposited energy) - electrons signatures with impact point enough far from boundary. There is good pedestal peak (as seems) due to presense of ETag-events (s86). Photon arm almost did not see some photons (bad beam conditions - so we had very pure statistics VC-triggered(S93)-events (near 3.5K from 103K) and no any event with ET44=1 and VC=1 simultaneously (may be due to bad beam conditions too). If anybody will look into ET4 and ET5 distribution then it is clear that channel mapping at this channels is vice versa (ET5 is looking as ET4 and vice versa). Triggers from Photon Arm were very rare, ET&PD-coincidence - rare too 12.04.1995 ================= H1KSHE === Long term online history .... Dear Colleagues, i am sorry for your attention disturbance, but may be the following information will be interesting for you. Everyone knows (at least it was not once proclaimed) that, one per cent order of accuracy for lumi measurement is not easy task for such beam conditions dependent method which currently is used. In addition the new magnet optics seems will provide new effects that can be cause of additional systematic errors. To avoid any uncertainties, where it is possible, it seems reasonable to store a complete set of beam and detector related information in the online files . For Lumi system the all available now rates, beam and detector parametres (~140 in total, including Veto Wall, Neutron Counter, Radiation Monitor) are stored allready during last two weeks. I see many profits from this kind of history. One of them, for instance, is a possibility of the fast and precise repairing of the online luminosity numbers. The following data elements are recorded. ----------------------------------------- Rates: ------- a. The main LUMI detectors (VC,PD,ET,ET44) trigger bits rates for colliding and pilot bunches,for different thresholds, coincedence triggers rates. b. Topological rate distribution for the most overloaded channels monitoring. c. External systems rates (VETO Wall, Neutr.Count., Radiat. monitor) Parameters & functions: ---------------------- a. All types of current luminosity values. b. Beam currents, beam position. c. Test pulses responses (stability check) for all 80 (3 VC + 25 PD + 43 ET + 6 ET44 + 3 TrigSum) channels. d. Trigger thresholds. Current version is provide with storing of 100 data elements per 10 sec. and plus the same number of elements per 60 sec periods. There is no problem to implemet another data/time options. The data elements are stored in a single time slice together with current time mark. Absolute time accuracy is +-1 sec. during 24 h due to the Macintosh timer is automaticaly corrected every midnight through special LAN service. Finaly You will have time uncertainty free data that makes much more reliable search for any correlation. How to get access to the data? -------------------------------- First release of application to plot any selected rates, parametres as function of time for any initial time and period within one Year interval is available now.(several software buttons control) Second release is imply a possibity for user to involve any mathematical preprocessing of the selected data and plotting the results. The names for most of recorded elements will be defined in the second release too. It is supposed to have the second release in May. You can run the application on remote Macintosh and have access to the data through AppleShare or simply make copy relevant part of data on your hard disc. Of course any plots will be pos- sible produce on the LUMI system Macintoshes and in any time. For dice2 users a similar service will be also implemented i hope soon. 13.04.1995 ================= H1KFOM === Summary of e+p94 Calibrations (continuation of message from 01.04.95 for ET&PD&VC-samples) It were made H1Lumi 15 calibrations for e+p94 data at last year (for data from 1543 G+M H1Runs).Motivations for making of any samples for calibration were different (see message from 01.04.95). Short charcteristics of each sample is seen from next table: 1 2 3 4 5 6 7 8 9 10 11 ---------------------------------------------------------------------- 1. 5A 31.07-09.08 83230-84024 148 54797 27.61 1.29 3.76 2.50 -0.34 ----- at this time was changed from 0. to -2.0cm ------------- 2. 5B 09.08-12.08 84026-84295 39 21032 27.63 1.24 3.49 2.24 -1.07 3. 6A 12.08-29.08 84300-85671 201 95451 27.66 1.34 3.78 2.46 -1.25 4. 6B 29.08-04.09 85699-86160 83 51617 27.63 1.29 3.76 2.36 -1.28 5. 7A 04.09-08.09 86207-86607 74 52032 28.11 1.55 4.68 2.95 -1.24 6. 7B 08.09-11.09 86607-86799 66 59429 27.63 1.43 3.69 2.36 -1.32 ----- at this time VC-setting was changed on VC-front sensetive ---- 7. 7C 11.09-15.09 86799-87054 57 34664 27.61 1.46 3.84 2.41 -1.25 8. 7D 15.09-19.09 87054-87249 87 74931 27.52 1.42 3.92 2.32 -1.07 9. 8A 19.09-21.09 87314-87457 37 29847 27.52 1.44 3.76 2.27 -1.03 8B 21.09-22.09 87459-87526 22 16254 27.33 1.33 3.45 2.00 -1.14 8C 22.09-22.09 87533-87556 10 4429 27.53 1.25 3.54 2.06 -1.04 8D 23.09-23.09 87586-87610 20 3478 27.39 1.27 3.38 1.93 -1.02 10. 8E 25.09-29.09 87697-88022 101 69327 27.62 1.35 3.88 2.31 -1.17 11. 9A 29.09-03.10 88082-88320 52 28786 27.68 1.45 4.17 2.53 -1.07 9B 04.10-05.10 88358-88473 12. 9C 06.10-10.10 88669-88877 117 90888 27.56 1.40 3.89 2.36 -1.08 13. 10A 10.10-16.10 88877-89264 118 128394 27.55 1.41 3.85 2.31 -1.06 14. 10B 16.10-24.10 89264-89877 110 68529 27.48 1.40 4.00 2.59 -1.13 15. 10C 24.10-01.11 89877-90419 197 78493 27.59 1.38 4.10 2.55 -1.07 ---------------------------------------------------------------------- total 31.08-01.11 83230-90419 1543 962508 27.61 1.39 3.90 2.44 -1.10 ---------------------------------------------------------------------- where 2 - sample 'name'; 3 - time period of data collection dd.mm(start)-dd.mm(finish); 4 - G+M H1Run range (data from these Runs were got for calibration); 5 - Number of G+M Runs at Data Sample; 6 - Number of ET&PD&VC-events at G+M H1Runs at Data Sample; 7 - ETrec+PDrec spectrum mean value(LOOK peak finder, bins 80 0 40, abs(Xet)<6.0cm - for ET&PD&VC-sample; 8 - ETrec+PDrec spectrum sigma value(LOOK peak finder, bins 80 0 40 abs(Xet)<6.0cm - for ET&PD&VC-sample; 9 - Eveto spectrum mean value (STATPARM, standard 30th histo at LREC) for ET&PD&VC-sample; 10 - Eveto spectrum sigma value (STATPARM, standard 30th histo at LREC) for ET&PD&VC-sample; 11 - Xpd spectrum mean value (STATPARM, X-projection of 23rd standard histo at LREC) for ET&PD&VC-sample. P.S. All digits were produced with using of latest official release of LREC-package (it was got from H1REC 06.00/15 cmz-file). Relation Coefficients, CCvcs and Global Shifts were got from H1 Data Base as it is ordinary making at official LREC-package. 16.04.1995 ================= F11LEV === Status of Lumi DAQ --> WWW .. Presently, lumi information is reasonably well represented in WWW. With one exception: status of DAQ. This is pity, because a lot of work has been done to improve the system performance. I believe, that this should be described as well. There is a good place for it: on the Lumi on-line page. Therefore, I would like to ask A.Fomenko and I.Sheviakov to prepare a short (~1-2 page) write up of the DAQ upgrade. The items which have to be mentioned are: o motivation for the system upgrade (limitations observed in 1994 and earlier, contribution to the total L1-L2 dead time, reasons for that) o proposed solution (double processor system) and its realisation (with brief description of the main h/w components and overall system configuration, including basic information on the online s/w) o improvements achieved (measured rates and dead time) As a separate topic, one can also describe basic existing online tools (very briefly, just a list of application programs and their purposes). 17.04.1995 ================= H1KFOM === LumiDAQ upgrade short writeup (as first variant - to be improved - if needed): Short Write-Up of the H1Lumi DAQ Upgrade at 94-95 Shutdown Period ----------------------------------------------------------------- o Motivation: ------------ During H1 Data Taking 94 it was found that Luminosity branch inside H1CDAQ became one of branches which put significant influence on H1 Dead Time. Front End Ready signal (FER) from Luminosity branch was delayed sometimes significantly (up to 100msec). Firstly this situation was obsereved by Eckhard Elsen 01.06.94 and was discussed later at one of the June 94 Trigger Meetings. Possible reasons and possible decisions of this problem were widely discussed at H1Lumi LogBook N9 (see data set F11LEV.H1.LUMI.LOGBOOK. PART09 at DESY IBM): 02.06.1994 H1Lumi's FER 07.06.1994 H1Lumi's Dead Time 09.06.1994 Speed up online 14.06.1994 Speed up online (E.Elsen) 14.06.1994 speed up explain 23.06.1994 Speed up online E.Elsen at his comments to this discussions recommended: "...You should use an additional new processor..." The next characteristics of Luminosity branch existed at this time: There were large (up to 100msec) FER delay from Luminosity branch. delay before FER = 1.632 msec =0.071 msec H1 Lumi Dead Line = near 102 Hz. Little improvement of this characteristics were made at 01.07.94 and after this improvements H1 Dead Time dominated by trackers. Sharpness of Luminosity branch problems with FER delay was removed (see messages at H1Lumi LogBook N9): 01.07.1994 H1LumiOnLineReleases 02.07.1994 Speed up online (E.Elsen) It were removed large FER-delays from Luminosity branch. H1 Lumi Dead Line became near 112 Hz. o H1Lumi DAQ improvement and upgrade: ------------------------------------- Additional processor was ordered through S.Burov at 23.06.94. Work for involving of additional processor into H1Lumi DAQ was started immediately after end of H1Data Taking 94 at November 94 by Igor Sheviakov and some summary of this work was proclaimed at H1Lumi LogBook N11 (see data set F11LEV.H1.LUMI.LOGBOOK.PART11 at DESY IBM) at his message 16.11.1994 Some test results delay before FER became closely to 800 mksec H1 Lumi Dead Line became 150 Hz. From 09 Janury 1995 it was started new period of improvement/upgrade of Luminosity branch characterisics and finished near 03.04.95. At this period new ETag44 channels were involved into ReadOut,it were improved some ReadOut algorithmes and subroutines and Lumino- sity branch was involved into operation at 10th H1CDAQ branch together with Forward Muons and Forward Proton Spectrometer branches Some details of improvements are discribed at H1Lumi LogBook N11 messages labeled "OnLine": 09.01.1995 TwinFIC1 Release for 10th Br. ....... 03.04.1995 OnLine Programs Development o H1Lumi DAQ improvement and upgrade Results: -------------------------------------------- As result delay before FER became near 1 msec; H1Lumi Dead Line became near 200 Hz. 18.04.1995 ================= H1KFOM === LumiDAQ upgrade short writeup S.Levonyan made good editing of early proclaimed text and today I put into WWW-readable file his variant of 'Short WriteUp..'. 18.04.1995 ================= H01GOG ===== information on online disk After the presentation in the DQ meeting of the history information available now on the LumiMac (see Egor's last message in logbook), a discussion followed concerning this data. There are four aspects: 1. This information is of great interest to H1 people!!! 2. J.Olsson pointed out that if there is a disk crash, then all data will be lost. It is good system management practice to backup regularly and often (maybe once per day). For tape backup, contact person is E.Wuensch. 3. Offline availability of the information: not by network access to the disk, but by providing copies of the files on offline disk. This could also serve as backup. For this purpose a description of filenames and file contents is needed, as well as some display facility (e.g. LOOK and LOOK-files). For disk space one can contact R.Gerhards. U.Straumann pointed out that much of the history information might be needed later in the physics analysis. 4. U.Straumann suggested to put the data into ORACLE database. This means that one must organize the data in DB-tables. For this work one of the Lumi people (maybe Egor or Sasha Fomenko ?) would have to join the ORACLE working group in H1 (convener J.Olsson). Points 3 and 4 are non-trivial and involve much work!!! 19.04.1995 ================= F11LEV ==== access to the online history I agree, that the data should be: 1) available offline more directly, then via network access to Lumi Mac disk; 2) protected against accidental losses and damages, by regular backups to either IBM/dice disk, or to cartridges. But I do not agree, that it is our (Fomenko, or Egor) responsibility to format the data into DB-tables. Of course they are welcome - if they want - to participate in ORACLE group work, but this will take a significant part of their time, I am afraid. There are sufficient number of people in this group already now, and it is not a common practice, that all subdetector, producing data for the database storage, also provide a software for their formatting/access/dispay etc It must be a general tool available for any kind of such data, not only for this particular online lumi history files. The minimum, we have to provide, is a description of the existing format and to agree on the procedure of the regular copies to the offline storage. 19.04.1995 ================= H1KFOM === Lumi at CTL again ........... At 11 April 1995 afternoon Luminosity branch was switched off from H1 Central Trigger Logic. Today morning Luminosity branch was switched on again to H1 Central Trigger Logic. H1Runs from 99304 up to 100011 were recorded without Luminosity branch at H1CDAQ. H1 Run 100012 is first H1Run with Luminosity branch ON after switching on of Lumi into H1 CTL. 21.04.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development It was made new release of program for FIC1_Master. It was made only one changing. It was removed the making of 'zero pedestal' flag at LRE1-bank (20001 value). These are creation dates and program sizes of last release: TwinFIC1...............MPST MPS .....89156 Fri, Apr 21, 00:30 1995 M This release was booted into FIC1_Master between H1 Runs 100218 and 100219. 22.04.1995 ================= H1KFOM === HERA e+beam Activity ...... Yesterday evening HERA e+beam activity had started near 18:20. It were fixed some attempts to inject more or less high e+currents (at 19:30 it was fixed Ie+ near 16mA, at 22:30 - near 6 mA, at 0:40 - near 7.5 mA). From 01:30 up to 07:10 it was fixed stable 27.555 GeV e+beam with Ie+=3.6mA at start time at Ie+=2.1 mA near e+beam dump time. There were some synchronisation problems (near 2 hours from 03:12 up to 05:07). At this period it were not retranslated values of e+beam bunch currents from HERA too. At period of stable e+beam it were recorded time stability test H1 Runs (100353-100390) with Random trigger mainly. Luminosity branch was switched on at all these Runs. As seems FADC-shifts were installed on default values (on 20 nsec shifted). 22.04.1995 ================= H1KFOM === HERA p-beam Activity ...... Today at 15:20 HERA p-beam injection had started and at 16:40 it were injected 180 bunches with Ip=12mA (3 trains with 60 bunches each). Bunch structure was the next: 3*(6*(10 filled+1 empty)+4empty)+10 empty At 16:40 ramping had started and at 17:30 had finished with Ip=6.8 mA. At 17:50 Lumi detectors were put into working position. From H1Run 100442 it is possible to look for on rates (LUMM-bank) or pedestal distributions with stable p-beam. VC-rate after putting into working position became near 50 Hz. HERA people proclaimed "Proton Beam for experiments" near 17:50. 23.04.1995 ================= H1KFOM === HERA p-beam Activity ...... Yesterday proclaimed stable HERA p-beam for experiments existed up to today 10:05. It were recorded set of H1 Runs with Lumi-banks with Lumi detectors at working positions: 100455-100472 (with Mode 1) - from 18:35 up to 21:10. After problems with power with trailor Lumi branch was included into H1CDAQ after midnight (from 00:20) as seems after reboot (Mode 6) and (as seems) Lumi detectors were put into Parking Positions at this period (H1Runs 100492-100558). Ip=6.9mA at start period (near 18:00 yesterday) and Ip=6.6mA today morning. 23.04.1995 ================= H1KFOM === LUMIMONs 04-08............. It were appeared new LUMIMON-data set at /acs/data/95/spec-directory 4th,5th,6th,7th and 8th. As seems new classification must appear at this data sets. Who knows where some log-data set exists for these data sets (at last year it was HERA05.LUMIMON.LOG at DESY IBM)? For example 8th LUMIMON data set includes data from H1Runs100395 up to 100466 (so last data from stable proton beam are at this data set). 125538 events are at this data set. Next classes were seen at this data set: 6 - PDlow ( 2) 9 - Random (119113) 21 - LREC ( 19) 22 - ET >thr ( 12288) 23 - ET1>thr ( 2014) 27 - from p-filled bunches( 28595) 23.04.1995 ================= H1KFOM === HERA e+beam Activity ...... Today at 11:00 HERA e+beam activity had started. At 12:20 it was fixed first injection of more or less large e+current. At 12:29 it were injected 42 bunches with Ie+=6.04 mA. Bunch structure was the next 14*(3filled+6 empty). But during last 3 bunches injection large part of e+beam was lost. Beam was dumped and injection started again with new bunch structure: 2*(7*(3filled+6 empty)+7empty). At 12:47 - 42 bunches with Ie+=3.4mA. At 12:50 e+beam was dumped again 23.04.1995 ================= H1KFOM === H1Lumi Rates with p-beam... From analyze of LUMM-bank contents at H1Run 100455 (recorded near 18:40 yesterday during existing HERA stable p-beam with 820 GeV) it were found next rates of Lumi Trigger elements and bits: VC - near 57 Hz, PD - near 1350 Hz, PDlow - near 1600 Hz, PDhigh - near 0.3 Hz, ET - near 400 Hz, ET&PD - zero ET&PD&nVC - zero PD&nVC - near 1350 Hz, eTAG - near 400 Hz. P.S.(24.04.95.A.F.) - today morning together with Egor it was found at Egor's history pictures that enough large rates at PD,PD1,ET are connected with so-called 'readout noise' - during pauses between H1Runs (which are not seen at Offline) rates are near zero. VC-rate is not sensetive to readout - at pauses rate is the same - - near 58 Hz. 23.04.1995 ================= H01GOG =========== LUMIMON.LOG file The information where you can find LUMIMON log file is described in WWW (Physics Working Group --> Files --> LUMIMON files (data files of 1995)). So, LUMIMON-1995 files exist only on DICE2. The content of the log file you can see using the command: less /h1/log/LUMIMON.LOG By the way, I have copied 5 LUMIMON tapes from DICE2 to IBM: HERA03.H01.LUMIMON.C9500004-8 All of them contain more or less garbage. But LUMI-classification seems to work correctly. 24.04.1995 ================= H1KFOM === HERA e+beam Activity ...... Yesterday evening HERA e+beam activity had started again at 22:10 and had finished today morning near 07:40. It was fixed 5 e+injections of enough large currents (30mA,33mA,35mA,30mA and 34 mA). It were not fixed succesful ramping of e-ring. Most time 12 GeV e+beam with enough large current existed at HERA e-ring this night. H1Lumi Detectors were at parking positions. 24.04.1995 ================= H1KFOM === Huge quantity of LUMIMONs.. Today 14th LUMIMON had appeared at /acs/data/95/spec-directory. As seems something not good with selection of data for LUMIMON-data sets. May be it is not needed to write data from temporary data logging Runs. For example (if we did not write temporary logged H1Runs) 10,11,12 and 13th LUMIMONs never appeared at LUMIMON-family 95. May be it is needed to make analize on Ie+ and Ip presence simultane- osly - at this case we can collect only useful data. P.S. (S.Lev.) Everything is OK with LUMIMON selection. Simply H1 is writing to offline ~99% of garbage data. This is not expected for the normal running conditions. We did not want to restrict LUMIMON samples to only collision data; very often single e-/e+ data are also important (remember, we even sometimes request stable stand alone lepton beam!) 95% of LUMIMON data are selected by condition: Random trigger (in normal running, this is ~0.4% of data) What we could add: to select only permanent data. But even that is sometimes not good: remember in the past at several occasions Fomenko wanted to write and analyse temporary runs as well. So: if there is no request from LUMI people to keep all data on LUMIMON files, we can suppress temporary data. 24.04.1995 ================= H01LNS === L4 Alarm "tool" for LRTL ====k === 1.) Introduction. - A month ago I reported of some "tools" for Lumi Alarm diagnostics. - These tools were based on testing of histos from the Lumi L4 s/w, and they make diagnostics of the wrong values of ET,PD,VC energies. - These tools were made for L4-on-line, for the sake of Alarming, and their use in any private analysis is much less useful for Alarming. - S.Levonian pointed out some other tasks for Lumi Alarm diagnostics, Some realization of one of these tasks is shortly reported below. 2.) The main points for the LRTL Alarm program. - The now proposed "Alarm tool" is designated for the L4 diagnostics of "the cases of disappearance(!) of the Lumi bank LRTL at H1 L4". Normally, the LRTL should carry the Rates/Luminosity information and should be transferred to H1 every 10 seconds as a KEEP-bank. - The main idea is to read all the HEAD banks and all the LRTL banks, and then to use the time from the HEAD banks for checking the time intervals between the neighboring Lumi LRTL banks. - The main parameter is "the time_of_absence_of_the_LRTL_at_L4". If the time between two LRTLs is more than the parameter, the signal of Alarm is sent to the H1 control console, to wake up the shifters. The next signals are sent at the intervals equal to the parameter, that must be tuned to prevent the shifters against Over-Alarming. - The other important parameter is "the_e_and_p_beam_configuration". The most important config is "ep*cc" that means e&p -beams having nominal energies and the beam current values of more that 1 ma (cc). The other configurations are "e_*c_", "lp*cc", "l_*c_", etc, where "l" (instead of "e") means 12-Gev e-beam and "_" means absent. - The most difficult job was testing and finding of some small peaces of code to "prevent the tool against False- and/or Over- Alarming". - The most important testings were done on the basis of TCL-events and these testing jobs have taken most of the debugging time. - The Fortran text of the proposed "tool" is at dice2/~shtarkov/L45. 3.) List of all the 10-minute's LRTL Alarms for 1994's . All the 10-minute's(!) LRTL Alarm massages for the 1994's, taken from the TCL's #001-102 are shown at the Appendix A. Some Summaries from this testing are now following: - The proposed "tool" has successfully found the case of the LRTL disappearance (ended by Run 86756) that is well known from LLO94. - The second case, known from the LLO, was not found be the "tool", because the relevant runs are fully absent at the TCL cartriges. - In total for 1994's, for the time of more then 10 minutes(!), for the most important beam configuration "ep*cc" (Luminosity), the "tool" has found 16 cases of the LRTL disappearance (see), - Byond the shown list of Alarms, for the time of more then 1 minute, much more cases of Alarm have been found (can be seen at dice2), - And much more Alarms were found for the less important beams - without p-beam (sometimes calibrations) and for 12-Gev e-beam. - As for me, such a long list of Alarms is a little surprising, but I cannot find any real connections to the Luminosity values. 4.) Statistics of the LRTL Alarms from the TCL's 1994's. Some statistics of LRTL Alarms in 1994's is shown at the Appendix B. This info was taken with the "tool" from all the TCL 94's cartriges and splitted to 3 tables. Some comments on statistics are following: - Note, that the tables include numbers of the Alarming LRTL pairs, in contrast to the numbers of the Alarm signals to be sent. - The relevant histograming has shown a regular structure, peaked around 10, 20, 30, ... seconds, and strongly decreasing with time. - The first table (520000) displays the normal LRTL situation, - Something had happened to LRTL at the second table (530000), - The last table has integrated all the Alarms during 1994's. - I cannot make any useful conclusion from this situation. 5.) Some special Conclusions on the LRTL Alarming tool. - The proposed "LRTL Alarm program tool" seems to be working well, It could be now implemented (CMZ) into the Lumi L4-on-line software, For this job helping of S.Levonian is necessary in a number of ways. - There are yet some jobs of cosmetics to be done, not important, Simple analogues of LRTL to be made for KEEP banks TCUR and LUMM, Some other Alarm jobs for Lumi L4 could/should be possibly done. - At last, any questions to/from the L4 proffies can arrize...(!). Sorry for the HERA hot time, L.Shtarkov, DESY, 24.04.95. ----------------------------------------------------------------------- Appendix A. List of "all" the 10-minute's LRTL Alarms for 1994's. For the most important beam configuration ep*cc only. In cases of a few messages/run only the last shown. Important are Number of Run and Number of minutes. Some comments and Summaries see above, point 3. LUMI_ALARM: no_LRTL R_81699 ep*cc E_ 8269 ! 10_min N=119 L M R = 0 053 LUMI_ALARM: no_LRTL R_83235 ep*cc E_21966 ! 10_min N=543 L M R = 0 053 LUMI_ALARM: no_LRTL R_83238 ep*cc E_44657 ! 20_min N=599 L M R = 0 055 LUMI_ALARM: no_LRTL R_83244 ep*cc E_46644 ! 20_min N=527 L M R = 0 055 LUMI_ALARM: no_LRTL R_83248 ep*cc E_67127 ! 30_min N=484 L M R = 0 054 LUMI_ALARM: no_LRTL R_84369 ep*cc E_12363 ! 20_min N=198 L M R = 019** LUMI_ALARM: no_LRTL R_84377 ep*cc E_41450 ! 20_min N=180 L M R = 0 055 LUMI_ALARM: no_LRTL R_84383 ep*cc E_45360 ! 20_min N=184 L M R = 0 055 LUMI_ALARM: no_LRTL R_84369 ep*cc E_12363 ! 20_min N=198 L M R = 019** LUMI_ALARM: no_LRTL R_84377 ep*cc E_41450 ! 20_min N=180 L M R = 0 055 LUMI_ALARM: no_LRTL R_84383 ep*cc E_45360 ! 20_min N=184 L M R = 0 055 LUMI_ALARM: no_LRTL R_86756 ep*cc E_35090 ! 20_min N=176 L M R = 0 055 LUMI_ALARM: no_LRTL R_88723 ep*cc E_ 3268 ! 10_min N= 89 L M R = 0 050 LUMI_ALARM: no_LRTL R_88743 ep*cc E_ 3448 ! 10_min N=102 L M R = 0 051 LUMI_ALARM: no_LRTL R_90213 ep*cc E_ 3770 ! 20_min N= 74 L M R = 0 037 LUMI_ALARM: no_LRTL R_90320 ep*cc E_93093 ! 25_min N= 1 L M R = 0 0 0 Appendix B. Statistics of time for the LRTL Alarms of 1994's. Three tables are accumulating NEV, see "selected". Some comments and Summaries see above, point 4. ---------------------------------------------------------------------- Distribution of Time between any two LRTLs. beams_selected=(ep*cc) NEV(all_runs)=1546303 NEV_selected(all)= 520000 (current R= 82004) ------------------------------------------======---------------------- t> 0sec t>10sec t>20sec t>30sec t>40sec t>50sec t>60sec 520000 24898 825 404 318 248 205 t> 0min t> 1min t> 2min t> 3min t> 4min t> 5min t> 6min 520000 205 123 94 85 73 62 t> 0min t>10min t>20min t>30min t>40min t>50min t>60min 520000 22 4 0 0 0 0 ---------------------------------------------------------------------- Distribution of Time between any two LRTLs. beams_selected=(ep*cc) NEV(all_runs)=1660200 NEV_selected(all)= 530000 (current R= 83294) ------------------------------------------======---------------------- t> 0sec t>10sec t>20sec t>30sec t>40sec t>50sec t>60sec 530000 32343 8058 7532 7370 7213 7064 t> 0min t> 1min t> 2min t> 3min t> 4min t> 5min t> 6min 530000 7064 6447 5878 5364 4873 4439 t> 0min t>10min t>20min t>30min t>40min t>50min t>60min 530000 3329 1325 385 0 0 0 ---------------------------------------------------------------------- Distribution of Time between any two LRTLs. beams_selected=(ep*cc) NEV(all_runs)=4036245 NEV_selected(all)=2000000 (current R= 90236) -----------------------------------------=======---------------------- t> 0sec t>10sec t>20sec t>30sec t>40sec t>50sec t>60sec 2000000 137136 13660 11407 10932 10667 10430 t> 0min t> 1min t> 2min t> 3min t> 4min t> 5min t> 6min 2000000 10430 9449 8609 7889 7214 6652 t> 0min t>10min t>20min t>30min t>40min t>50min t>60min 2000000 5008 1820 385 0 0 0 ---------------------------------------------------------------------- Sorry for the LLO space, L.Shtarkov, DESY, 24.04.95. 24.04.1995 ================= H01GOG ===== temporary data suppressing Selection code for LUMIMON events (s/r ECLUMI) was modified today. After installation at L4 (hopefully tomorrow) all temporary data taken only by the random trigger will NOT be classified anymore, and therefore will NOT be written to LUMIMON files. If temporary data contain LUMI information (trigger bits or energies) they still go to LUMIMON files. With such a modification, the majority (~80-90%) of the events from LUMIMON tapes C950004-C9500017 would not be selected. 25.04.1995 ================= H1KFOM === HERA p-beam Activity ...... Last night at 02:00 it was injected enough large p-beam current - near 20-21 mA. Ramping was finished at 02:28 with Ep=820 GeV and with Ip=18.2 mA. At 03:27 p-beam was dumped or lost. HERA people proclaimed "Technical Problems with S.C.Magnets, Restart 11:00". 25.04.1995 ================= F11LEV === New LREC version .......... Today a new version of LREC module has been released, for 1995 LUMI system configuration. It should appear soon at L4 and L5, and a bit later in the official H1REC cmz file (H1REC librarian is absent presently). Please, those who are interested, note the following important information: 1) This is only a technically new version: - new e-tagger (ET1, or ET44) is implemented, - new raw data banks are taken into account, - few new banks are added to the database, and some old ones have been modified, - new sets of control plots for L5 are in LRSUMM routine, - some ancient and never used stuff is removed. 2) New output banks are created: LR1E and LUEN (see their DDL description for more details) 3) However, the rec. algorithms remain the same, and here still a big room for improvement exists! Just to keep the community informed, I give a short summary on what has been tried during few small windows of free time in March: the main problem, reflecting in rec.quality, is a coordinate reconstruction. Here several things were investigated: a) effect of "dips" in x/y rec., b) coord. rec. at the edges of the calorimeters, c) tuning the shape of so-called "sharing function" (3 types were tried: MC, obtained from EGS4 in 1987, data, from Serpukhov calibration runs, derived by Usik, and from real HERA data-1994, from LUMIMON events) d) studies how a hypothetical "tracker" in front of ET (or ET1) with typical resolution of 0.2-0.5 mm would improve the energy reconstruction. In summary: - only d) gave a definite improvement, and it is clear, that this option must be seriously discussed within the group if one would like to have a reasonable energy reconstruction in the new tagger (present prototype, or final 5*5 device). Also for present ET the improvement is large for ~20% of statistics (at x_ET < -6.0-6.5cm) - using "tuned" shape of R(Ai/Aj) vs X(Y) gives only marginal improvement. Here I want to point, that one has to use the function = f(R), rather then =f(X) as it was measured in calibration runs in Serpukhov and DESY, and used in LREC. Still, I hope finally to use "real-HERA" function, but this will come later. - an effect of "dips" in coordinate distr. is a "feature" of the present rec.algorithm. One can "move" the position of these dips along the crystals, but cannot remove them completely (to recapitulate again: in present scheme!) It was found also, that the distributions look better, if "a bit wrong" algorithm is used, compared to those, obtained by using "more correct way" of determining x,y. All these small effects are however only cosmetics and do not influence significantly the energy determination. 4) Information for LREC installation: ~f11lev/lrec/lrec95.car card file from LREC cmz file which will go to the official H1REC ~f11lev/lrec/lrec95.small.f expanded Fortran code of LREC, using 50K BCS common ~f11lev/lrec/lrec95.DB.banks database banks used by LREC, which are new or modified compared to old version ~f11lev/lrec/lrec95.DDL.banks description of LUMI bank formats (will go to H1TEXT file finally) You will need a status of database as of 20:00 25-Apr-95, or later! 5) Some brief "description" extracted from LREC code *-------------------------------------------------------------------+ * The following convention is used throughout LREC: | * Detector 1 = Electron Tagger (ET) | * 2 = Photon Detector (PD) | * 3 = Cherenkov Water Counter (VC) | * 4 = New Electon Tagger (ET44, or ET1) | *-------------------------------------------------------------------+ ************************************************************************ * * * LREC : Steering routine for LUMI counters reconstruction * * * * INPUT : LREE, LRPE, LR1E - digi BOS banks * * LREP, LRPP, LR1P - online calibration coefficients * * H1_database_lumi - geometry and calibration constants * * OUTPUT : LETR, LPDR, LE1R - reconstructed el/photon energies * * LRXY - reconstructed x/y coordinates * * LUEN - intermediate (deposited) energies * * * * DEBUGGING : IDB = 0 - mimimal output; * * standard set of control plots (~7 Kb) * * 1 - not used * * 2 - test printout from LRINIT and LRSUMM added; * * extended set of histograms (~140 Kb) * * 3 - compete set of control plots (~300-600Kb) * * 4 - same as 3 and printout added (~4lines/event) * * CALLED BY : H1REC * * * * AUTHOR : S.Levonian CREATED : 18.01.89 * * UPDATED : 24.04.95 * ************************************************************************ * * * LRSUMM : Book/fill/output LUMI summary plots * * * * INPUT : MODE = -1 for initialization stage * * 0 for output stage * * 1 for histogram filling * * * * There are 3 options for control plots: * * --------------------------------------- * * 1) Default set ( 21 1-dim histos) - filled always * * 2) Debugging set (+80 1-dim histos) - filled if IDB>1 * * 3) Detailed set (+18 HS + 4 XY ) - filled if IDB>2 * * * * o Default set: x,y distr for ET,PD,ET1 (6) * * E_rec for ET,PD,VC,ET1 (4) * * E_sum (ET+PD, ET1+PD) (2) * * Trig.eff (ET,ET1,VC,3*PD) (6) * * No of hit chan. per det. (3) * * o Debugging: all default histograms (21) plus * * E per channel (81) * * o Complete set: all (1+2) histograms (102) plus * * E_dep for ET,PD,ET1 (3) * * E_clust for ET,PD,ET1 (3) * * E_hot for ET,PD,ET1 (3) * * dx,dy for ET,PD,ET1 (6) * * dE/E_rec ET,PD,ET1 (3) * * E_ET vs E_gamma (1) * * E_ET1 vs E_gamma (1) * * E_ET vs x_ET (1) * * E_ET1 vs x_ET1 (1) * * * * CALLED BY : LREC * * * * AUTHOR : S.Levonian CREATED : 30.09.89 * * UPDATED : 24.04.95 * ************************************************************************ In case of further questions/problems/strange observations, please contact me in Moscow. 25.04.1995 ================= H1KFOM === HERA p-beam Activity ...... Today evening HERA p-beam program started near 17:00. Near 21:00 (during 2nd injection) it was fixed very strange situation - HERA-moni- tor shows Ip=2.86mA, the same value is retranslated into H1Lumi MacII through H1CTrig. All bunch currents are equal (13mkA) and all 220 bunches are filled. HERA p-ring ramping in progress and Ep=436 GeV. I never looked for this situation earlier. At 21:20 ramping was finished - Ep=820 GeV, Ip=2.86mA, situation with bunch currents same. At 21:50 'massage' of e-ring had started. After 23:00 it was looked for little difference (on 1 mkA) between p-beam bunch currents. 26.04.1995 ================= H1KFOM === p-beam and e+beam at HERA.. At 02:25 26.04.95 HERA e+beam activity started with 820 GeV p-beam presence at HERA p-ring (Ip=2.482 mA, 220 bunches). First 4 injections were held without large e+currents (not more then 0.5 mA) and without attempts of ramping. 5th injection had started at 03:40. It were injected 12 bunches with Ie+ near 2.3 mA. e+beam structure was the next: 9 filled + 1 empty + 3 filled. Ramping started at 03:47 and e+beam was lost at Ee+ near 27 GeV. Detectors were at parking position but during ramping at VC-bunch rates it were seen rates shifted on 7- -8 bunches from e+beam bunch currents (Rates-currents synchronisation problem expected if ramping was succesfully finished). 6th injection started at 04:22 and with Ie+=2.045 mA and with 12 bunches (12 first bunches were filled) e-ring ramping started at 04:26 and at 04:32 at the same achieved Ee+ near 27 GeV e+beam was lost. The same shift (7-8 bunch x-ings) was seen between bunch currents and bunch VC rates during ramping. 7th-10th e+injections were finished with the same non-succesfull ramping - beam was lost during last phase of ramping. 11th e+injection had started near 06:20 and firstly this night ramping was held succesfully. At 06:35 Ee+=27.52 Gev, Ie=1.834 mA, 12 e+bunches (from 0 up to 11). H1Lumi detectors were put into working positions. Shift at rate/current was 8 bunch-Xings. Beam position was bad - was near +2.9 cm, - near -1.5cm. After 10 min (at 06:45) 90% of p-beam was lost and at 06:57 e+beam was lost too. Detectors were put into parking position. 26.04.1995 ================= H1KFOM === HERA p-beam Activity ...... Today during all day it were made many injections of HERA p-beam with Ip total not more then 10 mA. Bunch current structure had same strange structure as at previous night (220 filled bunches with equal bunch currents). At 23:00 26.04.95 it was injected Ip=7.04 mA. Ramping of p-ring started at 23:30 and was finished at 00:04 with Ep=820GeV and Ip=7.04 mA (32 mkA per each from 220 bunches). HERA Monitor shows Ip=7.200 mA. After 10 min Ip=6.820 mA (31 mkA per each from 220 bunches HERA Monitor shows 6.920 mA. HERA e-ring magnets 'massage' started at 00:17. p-beam was lost at 00:30. 27.04.1995 ===== OnLine ==== H1KFOM === OnLine Programs Development Today it were made new releases of TwinFIC1-family program (for FIC1- Master and FIC1-Slave). Motivation for its creation was removing from H1Lumi ReadOut chains of Forward Proton Spectrometer's GPTP. It means that VETE-bank again changed its length (56->29) and miniheader contents. Next subroutines were updated: ReadVETEbank.f,OutBanks.f, ReadVETEbankS.f and both releases of InitConstant2.f (for Master and Slave programs). These are creation dates and memory size of last releases: TwinFIC1...............MPST MPS .....88926 Wed, Apr 26, 23:44 1995 TwinFIC1slave..........MPST MPS .....42172 Wed, Apr 27, 01:39 1995 Releases were booted into both FICs after H1Run 101227. 27.04.1995 ================= H1KFOM === p-beam and e+beam at HERA.. Only at 04:44 today HERA p-beam was injected again after 00:30 lost. After ramping Ep=820 GeV, Ip=2.200 mA (with 10 mkA per each from 220 bunches) - HERA TV monitor shows Ip=2.370 mA. Today early morning HERA e+beam activity started at 07:05. It were injected 3 bunches with Ie=0.130 mA. (HERA Monitor shows 0.140 mA). e+injection in progress now (07:30).