database dd 250505

Slide1: 

OPERA Database group meeting computing organisation at LNGS: networking and practical issues. 25’ Reports on local system developments DAQ + slow control Jacques 15’ BAM Ubaldo 20’ Spectrometer slow control Alberto 15’ Development laboratory Cristiano 10’ BMM 20’ Emulsion scanning database: Cristiano + Imad 30' May 25th, 2005 LNGS Agenda

Slide2: 

Computing and Network at LNGS

Slide3: 

Software distribution: a general software server (repository for common libraries and dev. Tool kits An ORACLE server bridge between Windows and Unix/Linux platforms ( NFS ?Samba?) Computing strategy for OPERA? Standard configuration: Database/software group should be able to define a standard configuration both on Linux and Windows : OS, compiler, software versions etc… DAQ, BMS installation may require this standard in 2005

Slide4: 

BUT: Network and computing at Gran Sasso: the issue of the optical connections from underground to the external lab has to be solved. How to get the hardware installed properly? How to reach a concensus with some standardisation of the connected hardware? - it will be important to develop the idea of having OPERA machines based in the LNGS computing center with  support from LNGS people for administration etc...; How to proceed? - PC/computer organisation underground like: what will be the backup strategy, the access from outside etc...  Even the necessity  to have barracks to avoid loss or damages of the computing power should be understood! (especially if outside network is not present!) WHEN?

Slide5: 

QUESTIONS / Remarks: How to have a usable network organised underground to allow BMS / BAM installation in the automn? And functionning. If machines should stay underground, we need barracks installed before the automn! Computing underground needs to be organized during the next 5 months: design, where the machines should sit, standard definition, Database server, software server etc…. TEAM? BAM: requires… BMS/BMM requires….

Slide6: 

BMS network and computing requirements underground HALL C: 3 PCs - Supervisor     1 PC Standard            Windows     - PLCs direct control   1 PC Standard Windows - portable PC for API debugging, failure treatment HALL C (if no other possibility but move to external lab later) - BMM 1 PC LINUX Machines in Hall C should sit in a barrack (Algeco requested for BMS) close to the detector When the external lab is setup with computing organization for OPERA the BMM machine may join the other machines (servers ….) Machines Operator workstation: shielded area + manipulation control (loading+run)

Slide7: 

Communication, network: The BMS PCs need connection through ETHERNET 4 PCS + 2 IP numbers for PLCS Practical issues: IP number, registration … how it works? Electrical power connection: Triple phase: 320 V Power: 8.5 kW per BMS (all engines on) Enough plugs to connect the PCs

Slide8: 

BAM

Slide9: 

BAM database: Vassil Verguilov (Note from June 17th, 2004) A database scheme exists, implemented in PL/SQL and installed on CERN Oracle server. A PERL front end is being developed. Some interactions are needed with the BAM team to validate the schema . Vassil is willing to continue the development The database can be accessed on CERN Oracle server. Its name is "opera_bam". interface he is currently working on, for editing/viewing the tables, located at http://vasoto.web.cern.ch/vasoto/cgi-bin/view.pl

Slide10: 

BAM The BAM database consists of 17 tables. It can be separated into three parts with respect to their function: Brick tables (2)– collects data about the detectors; Shift tables (5)– contain data about the shifts and events occurred and about people who took part in shift; Components tables (10)– store all the data about the shipments and about the different types of materials and components, that were used for building the detectors;

Slide11: 

Brick Tables Contain tables: Bricks and Conditions. The main table in the database Bricks describes the Brick sub-detectors. It contains information about detector dimensions. The Brick table connects to tables Conditions and Shifts with foreign keys (ShiftID, CondID). The Conditions table provides information about the environment conditions (humidity, air pressure and temperature) and the date and time when the measurement was made. BAM database: Vassil Verguilov (Note from June 17th, 2004)

Slide12: 

Shift Tables Data about the shifts is distributed in the following: Shifts, Operators, Problems, ProblemTypes, ShiftOperators; Shifts table contains the shift date and time and the general notes about the shift. All other data about operators which participated in a shift and problems which occurred are stored in tables Operators and Problems respectively. The connection with shift data is made by two tables which are called ShiftOperators and ShiftProblems. This allows the same operators to take part in different shifts, to have more then one problem to be inserted per shift and to have problems which appeared continuously to be connected with different shifts. BAM database: Vassil Verguilov (Note from June 17th, 2004)

Slide13: 

BAM database: Vassil Verguilov (Note from June 17th, 2004) Components Tables The Materials tables consist of the following tables: Supplies, SupplyTypes, Companies, Ingredients, Components, ComponentTypes, BrickComponents, Sheets, SheetTypes and BrickSheets Table Supplies hold information about shipments of different types of materials specified in SupplyTypes (e.g.: paper glue, paper, lead, etc.). With foreign key called CompanyID the Supplies table connects with Companies table.

Slide14: 

BAM network requirements? Database server?