Helmut Wolters

1

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

A base de dados da experiência

U Coimbra U Lisboa UBI Covilhã UCP Figueira da Foz INFN Bologna

Coimbra + Lisboa

António Amorim, Vasco Amaral, Umberto Marconi, Tomé Pessegueiro, Stefan Steinbeck, António Tomé, Vincenzo Vagnoni e Helmut Wolters

Hamburg

Helmut Wolters

2

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Sistema de informação em HERA-B

O detector HERA-B

A base de dados: requisitos e opções

Caracterização da comunidade envolvida

O desenho do sistema de gestão das bases de dados

Os domínios: subdetectores, DAQ, alinhamento...

Sistematização do esquema das bases de dados

Conclusões

Helmut Wolters

3

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

A ideia de HERA-B

Uma colaboração de ~ 300 físicos de Alemanha, China, Dinamarca, Espanha, Estados Unidos, Holanda,

Itália, Noruega, Portugal, Rússia, Eslovénia, Suécia, Suíça, Ucrânia.

Helmut Wolters

4

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Magnet

Muon 1,3,4

SVD(não visível)

O detector HERA-B

ITR- OTR chambers

TRDOTR

ECALRICH

Helmut Wolters

5

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Experiência HERA-B B/B-tagging B/B-tagging

B0/B0 J/KS B0/B0 J/KS

Vertex Detector Si strip 12 m resolution

RICH (/K)multinode PMT

TRD (eh)straw tubes+thin fibers

ECAL(+eh)W/Pb scintillator

shashlik

MUON (h)tube,pad and gaspixel chambers

Tracking: - ITR(<20cm): MSGC-GEM - OTR(>20cm): 5+10mm drift cells

Magnet: 2 Tm

C4F10

HiPt triggerpad/gas pixel

Helmut Wolters

6

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

The Golden Decay:

Helmut Wolters

7

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

O grande desafio: Seleccionar

Helmut Wolters

8

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Como seleccionar ?

Time scale

Input rate

10s

10MHz

5ms

50 kHz

200ms 4 s

500 Hz 50 Hz 20 Hz

Pretrigger: ECAL, System, p T padsL1: e/“Tracking” in4 SL, p T cut, mass cut

Pretrigger: ECAL, System, p T padsL1: e/“Tracking” in4 SL, p T cut, mass cut

1/200

L2: + drift times, magnettraversal, vertexing

L2: + drift times, magnettraversal, vertexing

L3: full track & vertexfit, +SVD tracks, p. id

L3: full track & vertexfit, +SVD tracks, p. id1/100

L4: + full reconstruction,physics selection

L4: + full reconstruction,physics selection

TAPETAPE

1/2.

51/10

Helmut Wolters

9

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

HERA-B DAQ

200 PC’s

200 SHARC DSP

Detector Front End Electronics

FCS

DSP SWITCH DSP SWITCHEvent Control

TriggerPC

TriggerPC

TriggerPC

INTERNET SWITCH

4LTPC

4LTPC

LoggerPC

SLT/TLT

4LT

240 PC’s

Linux

L4-farm

Helmut Wolters

10

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

A base de dados de HERA-B: o problema e os requisitos

Disponibilizar a infra-estrutura e gestão para:

• DB da configuração dos detectores - desenvolvimento de um esquema uniformizado para todos os grupos (subdetectores)

• DB de calibrações e alinhamento

• Distribuição da informação aos farms de reconstrução e trigger

• Associar cada event com a informação correspondente na DB

• Disponibilizar acesso separado offline e online - replicação

• Gestão da actualização do slow control sem redundância dos dados

• Implementação de DB’s para Run Bookkeeping e event tag

Helmut Wolters

11

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Finalidade do DB management system:•O DBMS separa:

• a camada interna (ficheiros) da camada externa (requisitos) considerando o esquema de definição dos dados

•Desempenho:

•O DBMS devia optimizar as definições internas para responder aos pedidos comuns de forma rápida e eficiente

•Estrutura do sistema extremamente complexa

•Problema das bases de dados relacionais (na utilização geral):

•Todos os valores são atómicos (não há arrays, objectos nem pensar...)

•não há arrays ou associações repetidas:

•Calibração PMT -> identificador PMT para cada re-calibração

Helmut Wolters

12

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Object Oriented Database Managers?•OODBMS: Objectos têm atributos (podem ser arrays !)

•Objectos podem ser associadas com outros objectos

•Crítica: mas isso deve ser lento.

•Efectuámos uma avaliação:

•Objectivity contra MIZZI (DBMS relacional «da casa»):

•Objectivity era tão rápido como MIZZI

•Verificámos que com optimizações podia até ser mais rápido

•Outro aspecto: atrair alunos (física ?, informática)

•Projectos com Objectivity (OO, industry standard) são muito mais interessantes do que MIZZI (local, artesanal,

arcaico)

Helmut Wolters

13

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Talvez só queiramos buscas relativamente a intervalos de tempo ?

• pode-se seleccionar objectos pelo valor dos seus atributos

• a maioria dos nossos pedidos são relativamente a tempo ou versão

• excepção: Event Tag Database: seleccionar Tipo de Partícula, E, etc.

• Query on time => Object(Time) or Object(t1,t2)

• MIZZI fornece esta funcionalidade•senão devia-se especializar o DBMS

(exemplo: conditions database de BaBar e R&D45)

t

Helmut Wolters

14

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Caracterização da comunidade HERA-B

• Os físicos em HERA-B gostam de resolver problemas escrevendo os seus próprios programas ou utilizando algo de um colega.

• Sabem bem programar em C/C++ e estão habituados aos conceitos de orientação por objectos. Fortran é «obsolete by default».

• Utilizam ARTE, uma ferramenta de simulação e reconstrução, estabelecida há muito tempo, que fornece um esquema com interfaces para C, C++ e Fortran. A geometria GEANT era utilizada para iniciar as bases de dados de configuração.

Helmut Wolters

15

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Caracterização da comunidade HERA-B (II)

• Por cima de ARTE, foi desenvolvido um simples formatador de objectos, utilizado por muitas pessoas. Nada sistemático!

• Cada subdetector tinha trabalho feito, sem coordenaçãoMS Access, Oracle, MIZZI, ASCII, binários, ...

• O DAQ estava bem avançado e tinha desenvolvido um sistema clientes/servidores que corre em UNIX e DSP’s.

• Situação caótica. Falta um coordenador

• competente

• com autoridade de decidir o caminho a tomar

• LIP entra na colaboração. Fomos designados para organizar a DB.

Helmut Wolters

16

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Caracterização da comunidade HERA-B (II)

• Por cima de ARTE, foi desenvolvido um simples formatador de objectos, utilizado por muitas pessoas. Nada sistemático!

• Cada subdetector tinha trabalho feito, sem coordenaçãoMS Access, Oracle, MIZZI, ASCII, binários, ...

• O DAQ estava bem avançado e tinha desenvolvido um sistema clientes/servidores que corre em UNIX e DSP’s.

• Situação caótica. Falta um coordenador

• competente

• com autoridade de decidir o caminho a tomar

• LIP entra na colaboração. Fomos designados para organizar a DB.

Helmut Wolters

17

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Então Objectivity ?•Toda a gente conhece MIZZI (no DESY, no grupo de software)

•Objectivity => licenças, formação, falta de continuidade para muitas pessoas

problema do manpower

•não conseguimos suporte suficiente nos subgrupos (detectores):

•Decisão então: MIZZI

•Desenvolvemos um sistema cliente/servidor: rpmdb

•por cima do MIZZI

•LEDA (Bologna): wrapper para incorporar objectos através de MIZZI

•organiza a distribuição da base de dados sobre muitos PCs

•encaixa a base de dados no sistema de informação do DAQ (rpm)

Helmut Wolters

18

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

As camadas rpmdb/MIZZI

/PM/ Descrip. field1 ; field 2; ...

.2

.5-.1

56892

...DB: /RICH/HV/

DB: /RICH/HV/

versions

Camada HERA-B (MIZZI+LEDA)

Camada SDB

Key= name+ version

Machine independent blub of DATA

DB layerIndexed Files

Camada HERA-B rpmdbCliente / Servidor

~Berkley db

DBMS independence

Helmut Wolters

19

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

• Um sistema de memorização por transacções, com• protocolo

• capacidade de gravação ou cancelamento, de um grupo de modificações, numa só operação

• recuperação de desastres

• Desenhado para • cargas muito altas

de muitos acessos leitura/escrita em simultâneo

• aplicações que precisam de transacções e capacidade de recuperação.

A camada Berkeley db

http://www.bostic.com/db/index.html

Helmut Wolters

20

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Objectos e associações:Por cima da camada MIZZI

LEDA

(Bologna)key key’

Key key’

Fornece associações entre objectos. • Estas associações são simuladas por tabelas especiais para o efeito.• Chaves funcionam como OID’s, assim simulam-se as classes. • Classes de objectos são carregadas/guardadas explicitamente

DBARTE: interface à ferramenta de simulação que fornece persistência para o ARTE memory scheme.

Helmut Wolters

21

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Retroactive calibration and alignment

run

Calibration for the previous run

Calibration process

Calibration for the new run

Revision 0

Offline 1...

Helmut Wolters

22

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Um editor de base de dados em TCL/TK

Helmut Wolters

23

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

O mecanismo da replicação

DB server

ONLINE OFFLINEfirewall

DB server

Incremental

dump files

Offline DB server

imported

Send to tape Offline

DB server

Helmut Wolters

24

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Bases de dados de configuração

• Integração das DB’s de DAQ, Slow Control e FLT

• DB’s dos Sub-detectores:• TARGET • VDS • ITR • OTR • High Pt • RICH • TRD • ECAL • MUONS

• Relações com as DB’s de alinhamento

• Validade em tempo (escalas diferentes!)

• Fontes dos dados:- ARTE + hardware + text-files + specific programs

Helmut Wolters

25

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

DAQ (Software

Components)

DAQ_ProcTemp

type : const char[64]name : char[64]path : char[64]exec : char[64]env : char[256]args : char[256]restart : unsigned int

(from DAQ_CONF)

Software Component:Run Configuration

Software ComponentSMC Configuration

Software ComponentProcess Templates

Software ComponentProcess Configuration Trees

ProcCfg

RunCfg

DAQ_RunCfg

name : char [64](from DAQ_CONF)

ProcCfg

SMCCfg

DAQ_SMCCfg

name : char [64]sst : unsigned intgsdt : char [256]sdt : char [256]

(from DAQ_CONF)

up

down

NodeGrp

ProcCfg

ProcTemp

ProcCfg

DAQ_ProcCfg

grname : char[64]domain : char[64]name : char[64]range : unsigned int [2]env : char[256]args : char[256]init : char[64]init_args : char[256]external : unsigned intcritical : unsigned intrestart : unsigned intsynch : unsigned intfini : char[64]fini_args : char[256]

(from DAQ_CONF)

DAQ_R_RunProc

DAQ_R_SMCCfg

DAQ_R_ProcCfg

IUdownIUup

NodeGrp

DAQ_NodeGrp

name : char[32]type : char[32]

(from DAQ_CONF)

DAQ_R_ProcNgrp

ProcTemp

Software Components

DAQ_R_ProcTemp

DAQ_R_UITemp

DAQ_R_TempNgrp

Helmut Wolters

26

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

DAQ - Crate

Helmut Wolters

27

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

VDS databases

Helmut Wolters

28

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

OTR From ARTE

GESL

name : char[4]cmp : intshp : intnsl : intmfl : intlay : int:x1 : floatx2 : floaty1 : floaty2 : floatz1 : floatz2 : floatdx : floatdy : floatnpl : intfpl : intnwl : intfwl : intltyp : int

(from ARTE)

gsgd

0..*

GEDE

cmp : intlay : intsec : intshp : intxmin : floatxmax : floatymin : floatymax : floatzmin : floatzmax : floatsxmn : floatsxmx : floatcos : floatsin : floatrot : float[9]aac : floateff : floatdod : floatpit : floatms : floatxfw : float[4]zfw : float[4]nwi : int[4]nsl : intfwl : intxmad : floatymad : floatzmad : floaty1w : float[4]y2w : float[4]gvol : char[4]hwc : char[12]dedx : floatgcop : int

(from ARTE)

0..*tosharc

sharc

isharc : intborad : char[9]fed : intsharc_cable : char[12]sharc_board : intshrac_board_pos : int

tocab

cab

icab : intgencha1 : char[16]gencha2 : char[16]modcha1 : char[16]modcha2 : char[16]modhv : char[16]ftbpos : char[16]ftbasd : char[16]ftpcab : char[16]lvpos : char[16]lvab : char[16]tdccab : char[16]tdccon : char[16]previous 1 : char[16]previous2 : char[16]next1 : char[16]next2 : char[16]status : char[16]T0 : float[16]

sharc_R_cab

Helmut Wolters

29

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

RICH databases I

CDIM

name : char[10]rlos : floatdens : floatnabs : intiabs : intnref : intiref : int

CEFF

efficiency : float

CLEN

id : intnwav : intiwav : intnang : intiang : int

CPDW

orig : float[3]xvec : float[3]yvec : float[3]thick : floatimat : int

CPMD

seno : char[12]isup : intirow : inticol : intlens : intefv0 : int

CPOI

arg : floatfunction : float

CPMT

type : char[12]nx : intxdiv : floatny : intydiv : floatneff : intieff : int

M4WireMap

PMT : intPad : intchannel : int

ASD

ASD

PMType : char[3]ASDConn : char[4]SuperMod : intPMBRow : intPMBCol : intMotherB : intDBConn : int

M16WireMap

PMT : intPad : intchannel : int

Dielectric Material

PointsEfficiency

Lense system

Photon Detector Window

PMT type

PMT definition

Helmut Wolters

30

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

RICHdatabases II

CSPM

orig : float[3]xvec : float[3]yvec : float[3]nref : intiref : introw : intcol : inttype : char[8]name : char[10]

CPMI

rec : floatnref : intiref : int

CSMI

ah : float[2]av : float[2]r : float:rpc : floatrec : floatnref : intiref : int

CSSM

row : intcol : intorig : float[3]norm : float[3]xvec : float[3]type : char[8]name : char[10]hdia : floatnref : intiref : intncor : intcornx : float[6]corny : float[6]cornz : float[6]

CSUP

x0 : float[3]xvec : float[3]yvec : float[3]nx : intxdiv : floatny : intydiv : floatid : int

CVES

pori : float[3]pez : float[3]prad : floatplen : floateori : float[3]eez : float[3]erad : floatelen : floatirad : int

ChannelStatus

ChannelID : intstatus : short

Vessel

Planar Mirror

Spherical Mirror

Single Spherical Mirror

Single Planar Mirror

Supermodule

Helmut Wolters

31

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Manutenção do sistema• Um processo slow control controla permanentemente o

estado dos servidores da base de dados.

• Emite alarmes para o shift crew do detector.

• Ferramentas para start e stop da

configuração dinâmica dos servidores da base de dados

devem ser utilizados por um pequeno grupo de peritos.

• A configuração e o arranque do

sistema distribuído dos servidores das bases de dados

são efectuados através de uma base de dados especial

de configuração para este sistema.

Helmut Wolters

32

LIP Jornadas - E

riceira - 20-21 Dezem

bro 1999

Conclusões Desenvolvemos um sistema cliente/servidor para gerir as DB’s

rpmbd: MIZZI rpm DAQ Subdetectores

Funciona há um ano na experiência (test runs)

Melhorámos o DBEDIT (editor TCL/Tk)

Arrancámos o processo de sistematização: Esquema de diagramas como base de discussão

Quais as fontes da informação ?

Qual a finalidade/utilidade desta informação ?

Qual a gestão de versões apropriada ?

Processamento Online / distribuição aos trigger farms

Interacção entre as bases de dados para cada subsistema:configuração / reconstrução / alinhamento / calibração / slow control

Ainda há muito a fazer... Aperfeiçoar o sistema com a experiência ganha no dia a dia