Download presentation
Presentation is loading. Please wait.
Published byEthan Griffin Modified over 9 years ago
1
Testing DAQ PY04 Mark Krasberg University of Wisconsin Berkeley Collaboration Meeting 20 March, 2005
2
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -2- Current Testing DAQ Software Python scripts (PyDOM, autogen- steering, multimon, lcchain.py, cold_reboot_test.py) Domcal Multiple workspaces (for running TestDAQ and STF) TestDAQ launch scripts
3
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -3- Many Different Test Setups 1 LocationStringProc?GPS?ReleaseDBComments SPSYes south polededicatedNo zips! SPTSYes south polededicated DFLYes recent south pole dedicated SwedenYesNo243 with bfdedicatedzip probs (800MBytes) DESYNo 243 NO bf 243 with bf dedicated ChibaNo 243 with bfdedicatedrev 3 dom Bartol 1No old-pkt?nonerev3 dom Bartol 2NoYesnone rev4 doms PSUNo old-pkt?dedicatedrev3 dom BelgiumNo 243 with bfdedicatedrev 4 doms LBLSPLTSYes south polepartial
4
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -4- The Different Setups StringProc yes/no implies different versions of TestDAQ launch scripts, and means data-collector either runs on a dedicated machine, or else it runs on the DOMHub. GPS yes/no means different TestDAQ software necessary Release “243” is last year’s standard FAT release (“bf” fixes bad timing bug) Dedicated database determines whether STF and autogen- steering and multimon can run locally Only South Pole and SPTS have done away with ZIPs so far – this makes things run much smoother. We continue to have occasional ZIP problems in DFL testing, and Sweden encounters ZIP problems more often (their string processor machine had/has only 800 Mbytes).
5
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -5- Make Testing Uniform Across Production Sites LocationStringProc?GPS?ReleaseDB serverComments SPSYes south polededicatedNo zips! SPTSYes south polededicated DFLYes recent south pole dedicated SwedenYesNo243 with bfdedicatedzip probs (800MBytes) DESYNo 243 NO bfdedicated ChibaNo 243 with bfdedicatedrev 4 dom Bartol 1No old-pkt?nonerev3 dom Bartol 2NoYesNonenonerev 4 doms PSUNo old-pkt?dedicatedrev3 dom BelgiumNo 243 with bfnonerev 4 doms LBLSPLTSYes south polepartial
6
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -6- Testing Site Changes Want to standardize the testing sites –Sweden Needs a GPS unit Needs an improved string processor Needs a software upgrade –DESY Needs a GPS unit Needs to use the string processor they already have Needs a software upgrade Martin Kestel will integrate DOMTest
7
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -7- Pole Improvements to Implement for next FAT Improved launch scripts –TestDAQ can be run simultaneously from different local NFS’d accounts (eg SPTS and DFL), if need be. –Local output files go into temporary directory ~/output#######, where “#######”=run number (this means aborted run data is always saved) –Monolith was integrated into the launch scripts we can run monolith on FAT data in the future would be able to look at the data using icetray –An attempt was made to have as little deadtime between runs as possible Axed zip files (finally) –this makes data taking smoother, less deadtime between runs, easier to analyze events Added ability to create LocalCoincidence and Flasherboard TestDAQ steering files automatically (using autogen-steering)
8
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -8- Proposed 2005 FAT TestDAQ runs Axe Optical Sensitivity Runs (use “multimon” instead) Continue to take GainVsHV and DarkNoise runs with Local Coincidence disabled Would like to take Linearity Runs using new trigger mode – LocalCoincidence UP.and.DOWN –This would enable linearity data to be taken with no background –With this mode we would be able to Take backgroundless cosmic data Easily test Local Coincidence –This requires a firmware change –LBL thought they might be able to do this in May, after which we can integrate into FATs Add new LocalCoincidence Runs (using LC enabled UP.or.DOWN) into normal FAT data-taking (LocalCoincidence runs require database to know where the “top” and “bottom” DOMs are Pole improvements (eg. axing zip files) will reduce the deadtime between runs
9
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -9- 2005 FAT Testing Firmware Software – will use the Pole mainboard release (includes Local Coincidence/GPS/Flasherboard support) Use DOR Rev 1’s if available, otherwise we can use Rev 0’s
10
March 21 st, 2005 Berkeley Collaboration Meeting Testing DAQ PY04 Mark Krasberg – University of Wisconsin -10- Summary Want to make the different FAT setups uniform – may not be possible if GPS units unavailable Axe Optical Sensitivity runs in favor of multimon Intend to utilize Pole improvements in this year’s FATs (improvements should reduce deadtime between runs) –Minimize deadtime (axe zip files, for example) –Include Local Coincidence Runs as part of FAT Linearity runs and also dedicated LC runs Want to use the same mainboard release as at South Pole
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.