Transcript Evaluation of G4 hadronic physics in TileCal

ATLAS Detector Description Database
(status & plans)
Joe Boudreau, Vakho Tsulaia
University of Pittsburgh
ATLAS s/w workshop
10-Dec-2004
Contents
•
General architecture of the Detector Description Database (DDDB)
•
Filling the contents of DDDB, web interface
•
Usage inside ATHENA, data validation
•
Database distribution
•
Strategy for closing geometry releases
•
Conclusion
Geometry DB 10-Dec-2004
2
General architecture
•
The main purpose of DDDB is to store in one common place all primary
numbers for ATLAS subsystems together with the configuration
information (tags, switches)
•
Presently there are two Oracle accounts serving DDDB at CERN
–
Development (DEVDB). Used to enter and validate new data
–
Production (PDB). Starting from recently is default account for ATHENA
applications. Contains just a subset of DEDVB account data (locked tags)
•
•
The main reasons for supporting two different accounts are:
–
It is foreseen to replicate DDDB to remote Oracle servers and also transfer its
contents to MySQL
–
The strategy for these activities is not yet clear
–
… so we have to worry about consistency of distributed data
The present situation with these two accounts is going to be revised
in the near future
Geometry DB 10-Dec-2004
3
General architecture
•
The primary numbers for ATLAS Detector Description are organized
in DDDB into a set of Data Tables
–
Each data table describes some particular piece of ATLAS geometry
–
~150 Data Tables at the moment
•
Data tables are logically grouped into HVS node tree, where
–
Leaf HVS Nodes correspond to the Data Tables
–
Branch HVS Nodes are pure logical entities supposed to group child nodes and
build the tree hierarchy
•
HVS nodes can be tagged
–
Leaf HVS Node Tag consists of a set of corresponding Data Table records
–
Branch HVS Node Tag consists of its children tags
Geometry DB 10-Dec-2004
4
Browsing DDDB contents by node hierarchy
Geometry DB 10-Dec-2004
5
Browsing DDDB contents by tag hierarchy
Geometry DB 10-Dec-2004
6
Filling the contents of DDDB
•
New data table in DDDB can be created only through database
administrator account. To request new data table just send a message
to [email protected] or [email protected] with
following information
–
New data table name
–
Column names and types (your list will be extended by one ID column for internal
purposes)
–
Location in HVS node tree (parent Branch Node name)
Example:
Table name: DummyParams
XPos
double
YPos
double
Description
string
Parent node: ATLAS
Geometry DB 10-Dec-2004
7
Filling the contents of DDDB
•
When the data table is created (you will be notified about that), you
can declare it to HVS
–
•
On the interactive web tool (http://atlas-php.web.cern.ch/atlas-php/DDDB/admin.php)
log in as ‘atlasdd_writer’
–
•
In HVS terminology ‘create leaf (NOT branch) HVS Node’
Contact Joe & I for password
Follow Create new node link, fill the form and click ‘Create’
Geometry DB 10-Dec-2004
8
Filling the contents of DDDB
•
Create new tag for your node (tag name ‘DummyParams-00’) using the
web tool
•
Follow Create new tag link
Step 1: Select node
Step 2: Enter tag name and click ‘Create’
Geometry DB 10-Dec-2004
9
Filling the contents of DDDB
•
Fill the data tables with actual numbers
–
CVS. First you have the source files and then you create a tag
–
HVS. There is NO predefined order. You can first create a tag and then insert the
records in the data table or vice-versa.
•
Log in to atlasdd@dedvb database as atlasdd_writer
–
•
Use SQLPLUS utility, or any other tool allowing execution of SQL scripts on Oracle
db.
Execute a SQL script putting the numbers in the data table (you need
to insert a unique ID for each record in the first column)
Example:
insert into DUMMYPARAMS_DATA values (0,11.1,22.2,'First record');
insert into DUMMYPARAMS_DATA values (1,33.3,44.4,'Second record');
commit;
Geometry DB 10-Dec-2004
10
Filling the contents of DDDB
•
If you made a mistake in data entering, you need to delete newly
created records from DB and put them again
•
Follow Delete records link on the web tool
Step 1: Select node
Step 2: Select the records and click ‘Delete Selected Records’
Geometry DB 10-Dec-2004
11
Filling the contents of DDDB
•
Tag the two new records by ‘DummyParams-00’
•
Follow Collect leaf tags link
Step 1: Select node
Step 2: Select tag
Geometry DB 10-Dec-2004
12
Filling the contents of DDDB
Step 3: Select records to be tagged and click ‘Collect selected records’
Geometry DB 10-Dec-2004
13
Filling the contents of DDDB
Check that the previous steps were successful …
Geometry DB 10-Dec-2004
14
Configuration management in DDDB
•
HVS branch node tags are collected in DDDB hierarchically, level by
level
•
To collect ‘DummyParams-00’ under its parent ‘ATLAS-Dummy’ tag,
you need to follow Collect branch tags link on the web tool
Step 1: Select node
Step 2: Select tag
Geometry DB 10-Dec-2004
15
Configuration management in DDDB
Step 3: Update tag for the desired node
Geometry DB 10-Dec-2004
16
Validation and tag locking
•
Primary numbers and configuration switches in DDDB are presently
validated by building GeoModel descriptions and using them in
Simulation/Reconstruction
•
The primary numbers in DDDB are accessed by ATHENA applications
through RDBAccessSvc
–
The service was developed based on POOL Relation Access Layer, which provides s
common interface to the data in different Relational Database Management
Systems (RDBMS)
–
The concrete RDBM is chosen at run time by loading the appropriate plug-in
•
The primary numbers in all DDDB Data Tables are presented to
clients of RDBAccessSvc in uniform way through Recordset objects
–
Recordset is a snapshot of data table records corresponding to the given tag
–
The records can be retrieved from Recordset by index or using the iterator
–
The actual primary numbers are retrieved from records by field names
Geometry DB 10-Dec-2004
17
Validation and tag locking
•
After successful validation the HVS tags can be locked using the web
tool
•
Tag locking means
–
The tags of all its children HVS Nodes are locked
–
Locked tags cannot be renamed or deleted
–
The data records corresponding to some locked tag cannot be updated or deleted
•
In particular, locking ATLAS node tag closes the entire ATLAS
geometry version
•
Locking also means that the tag is ready to be published on the
Production Database account (PDB)
Geometry DB 10-Dec-2004
18
General strategy for data publishing on PDB
•
The main principle: Only the data corresponding to locked tags
should be published on the PDB side using the dedicated tool
•
We have developed a first version of the data publishing tool based
on POOL RAL
–
Transfers locked tags from DEVDB to PDB
–
Uses transactions
–
Still needs some improvements, especially for configurability
–
Using this program we have successfully published ATLAS-00 and ATLAS-01 tags
•
Any subsequent updates of the PDB database content should not
affect the existing data, just new locked tags will be added
•
PDB database should be the default storage of DD primary numbers
for ATHENA applications, providing just the read-only access
Geometry DB 10-Dec-2004
19
Distribution
•
The Production DB account should be used as a single source for any
further replication of DDDB contents to remote Oracle servers and
for translation to MySQL
•
The strategy and tools for these activities have not been chosen yet.
We foresee two possible scenarios:
1.
2.
Usage of a generic replication tool. (For example: Octopus replicator)
–
Using Octopus we have successfully transferred present contents of PDB account to
MySQL and have built ATLAS GeoModel description based on MySQL
–
We need too keep the present situation with two Oracle accounts if Octopus is chosen
Usage of a HVS-aware tool. (For example: our data publishing tool)
–
Using this tool we could not make Oracle-to-MySQL transfer because of problems with
RAL MySQL plug-in related to data inserts
–
RAL developers are aware of these problems and are fixing them
–
If a HVS-aware tool is chosen we can merge two Oracle accounts into one (on PDB)
Geometry DB 10-Dec-2004
20
Release strategies:
* We need to designate a set of releases tied to specific goals.
* Need to cut releases periodically even if there are no specific
goals, to give people a chance to freeze & distribute their mods.
* Need to allow for patched releases:
* major release of sw is called e.g. 9.0.0.
* main development branch is called 9.x.0.
* bug fix releases called 9.0.x.
* Need to decide on meaningful names for our configurations.
* This practically needs a “release manager”.
* Release schedule needs to be posted (DD home page)
Geometry DB 10-Dec-2004
21
DC2, Rome-Initial, Rome-Final
•Two versions have been frozen already and cannot be touched anymore:
ATLAS-00 == the DC2 configuration
ATLAS-01 == the Rome Initial Layout configuration.
Q: Is there any need to augment our DB with any patch to what we
have now?
• Rome-Final does not have its own dedicated description.
Q: When shall we open this release and when shall we close it?
(early January-end January?)
Geometry DB 10-Dec-2004
22
•Next big step will be the migration of a large amount of file-resident
information to the database, under one or more keyed descriptions.
 Needs a lot of cooperation from subsystems people!
 Also needs to be scheduled. When?
Proposal: Open this first of February
Close this end of February.
Make it available in release 10  (Feb 23 is deadline)
Geometry DB 10-Dec-2004
23
DC3:
* Early Sep 05 is closing date for SW release 11.
* Will be a major effort to describe detectors + cabling and
support in all necessary detail.
* I assume that a lot of new information will come into the
database, hopefully not all of it at the last minute.
Proposal:
*
*
*
*
First freeze at end of May.
Second freeze at start of September.
Reevaluation of the schedule as we proceed.
Plenty of flexibility in the schedule to react to
the legitimate needs of the community.
Geometry DB 10-Dec-2004
24
Conclusion
•
The ATLAS Detector Description Database is an essential part of
GeoModel based Geometry Versioning System
•
The design of DDDB application allows all ATLAS subsystems to put
the primary numbers into database in an uniform way, using SQLbased tools
•
DDDB configuration management and publishing tools have already
been used quite effectively, they need some further developments
though
Geometry DB 10-Dec-2004
25