180 likes | 264 Views
Status and activities in Salerno. Cristiano Bozza Salerno Emulsion Group Nagoya Dec 2006. Status. Human Resources:. Pino Grella (Professor). Cristiano Bozza (Researcher). Chiara Sirignano (Post-doc). Giustino D’Amato (Ph.D. Student). Fulvio Laudisio, Regina Rescigno (Degree Students).
E N D
Status and activities in Salerno Cristiano Bozza Salerno Emulsion Group Nagoya Dec 2006
Status Human Resources: Pino Grella (Professor) Cristiano Bozza (Researcher) Chiara Sirignano (Post-doc) Giustino D’Amato (Ph.D. Student) Fulvio Laudisio, Regina Rescigno (Degree Students) Cristiano Bozza Salerno Emulsion Group Nagoya Dec 2006 Maurizio Di Marino (Technician)
Status 3 (+1) stages operational (1 used for R&D, not 100% OPERA) Efficiency and background OK Vertex location OK in several conditions(Pions, PEANUT, Scanback/Scanforth/TotalScan/Manual checks) CS-brick connection tested with track patterns, OK(not real procedure in OPERA, just error estimation) Cristiano Bozza Salerno Emulsion Group Nagoya Dec 2006
CS-Brick connection X CS2 (0,0) 58 CS1 Z2 Z1 57 Y Z5 • Scan 5 zones, 1 cm2 each, on CS1, CS2, T58, T57 • Map CS1 on CS2 and select matching tracks on CS2 • Map T57 on T58 and select matching tracks on T58 • Map CS2 on T58 Z3 Z4
CS-Brick connection CS1-CS2 mapping T57-T58 mapping QMap.exe cs_1_5_1.tlg cs_2_5_1.tlg map_cs1_cs2_5.txt 300 .03 10 100 QMap.exe target_57_5_1.tlg target_58_5_1.tlg map_target_57_58_5.txt -1300 .03 30 1000
CS-Brick connection CS2-T58 selected mapping QMap.exe MAP_CS1_CS2_1_reformat.TLG MAP_TARGET_57_58_1_reformat.TLG map_cs2_tg58_1.txt
DB evolution DB datafile structure is now controlled at a fine detail level Even the disk head path is optimized, through proper settings on the SQL definition of tables(IOT tables) Improvement depends on disk typeSCSI disks are already partially optimized, so relative improvement is smallGreat performance gain on SATA and EIDE disks
DB evolution Heap organized table (“normal”) Tablespace PK TB TB TB TB PK TB TB TB TB Index organized table (“IOT”) Tablespace TB TB TB TB TB TB TB TB PK entry
ID_EVENTBRICK ID_ZONE SIDE ID POSX POSY SLOPEX SLOPEY DB evolution DB evolution 1 8 10005435 1 1 1394.5 883.9 0.123 0.045 Heap organized table (“normal”) 1 2 8 10005435 1 2 1343.5 835.9 0.163 0.142 3 8 10005435 1 3 2343.5 935.9 0.263 0.182 10005435 1 8 10005435 2 1 1594.5 983.9 0.123 -0.045 8 2 2 8 10005435 2 2 1343.5 735.9 -0.163 0.142 3 8 10005435 2 3 2543.5 635.9 0.263 -0.182 1 1394.5 883.9 0.123 0.045 1 2 1343.5 835.9 0.163 0.142 Index organized table (“IOT”) 3 2343.5 935.9 0.263 0.182 10005435 1 1594.5 983.9 0.123 -0.045 8 2 2 1343.5 735.9 -0.163 0.142 3 2543.5 635.9 0.263 -0.182
DB evolution Improvement depends on disk typeSCSI disks are already partially optimized, so relative improvement is smallGreat performance gain on SATA and EIDE disks(sustained INSERT process)
DB software Data sharing softwareSalerno PEANUT data copied to OPITA01 (LNGS central DB) Complete process repeated 20 times, successful(46 GB data set) Data sharing tests going on with other groups(Mainly Bari and LNGS – CS scanning station)
DB software Oracle backup software (OraBackup) developed by Alessandro Ruggieri (Roma) is under testing in Salerno Tests successful, first release to be circulated soon
Computing Infrastructure 2 Evolution lines: 1) = long term2) = short-term modifications for urgent needs (some improvements can be ported to (1) )
Computing Infrastructure 1) Long term modification • Requires upgraded DB schema • Strengthens security • Improves performance • Fully documented (SW and usage)
Computing Infrastructure 2) Short term modification • PredictionScan3Driver includes forking (special version sent to Bari) • SimpleScanback2Driver can get predictions from CS (under debug with Bari) Careful work still in progress to be sure old and newfunctionalities coexist
Computing Infrastructure New features introduced in “old” software Predictions on first brick plate are readfrom CS doublet tables Predictions on first brick plate are searched for with a “special” configuration for PS3D(forking enabled, wide area) Predictions on other plates are searched forin a “conventional” way (no forking) Double forking must be avoided (i.e., 2 candidatesappear in both scanback plates AFTER forking because they’re very near)
Proposal for evolution strategy Now – End 2006 support to “old” infrastructure and DBs Jan – Apr 2007 Work exclusively on “new” infrastructureand DBs to complete debugAssist labs to “migrate” from “old” to “new” Apr 2007 - .... Use “new” infrastructureand DB for OPERA scanning
“Hot” items Help on these subjects is strongly needed • Make CS-brick connection procedure automatic • Improve scanback procedure (tailor tolerances) • Allow use of X-ray marks