1/20

Status of ZBASE10 November 2010

Jean-Luc Nougaret, with special thanks to Chris

Roderick, Benoit Salvant, Nicolas Mounet and Elias

Metral.

2/20

Outline

• Introduction• Database schema • Populating the database • Java application • Conclusion and future work

3/20

Introduction

Motivation, data storage requirements and

architecture.

4/20

Motivations

• Keep track of the impedance of the machines – To understand high-intensity limitations of the machine.

– To predict the effect of modifications.

• Previous implementations with a GUI – ZBASE (1996), ZBASE3 (2006) now replaced by a

Matlab program. • Organizing the data with standard relational

database

– Rely on a self-describing data system.

– Insulate program from data.

– Manage data with SQL.

– Provide data backup, recovery, transactions and JDBC...

5/20

Data storage requirements

• Store wake fields and impedances. • Store elements and their beta

functions. • Store lists of elements on which to

perform a sum. • Store machines, beams and OP_MODES. • Store ancillary data such as authors,

methods, tunes … • Derived data are not stored.

6/20

Architecture

Database schema

Java application

Client

Structures Provides pedestal

Oracle database

Server

SQL

data

Stored procedure

Store, retrieve and process

impedance data

User

7/20

Database schema

From the conceptual model to the database schema…

8/20

Assumptions

1) Element name is unique across accelerators.2) Element family name is unique across accelerators.3) Wake fields and impedance data belong to a given family

of elements.4) Data are versioned with one PROD version and several user-

defined TEST versions.5) Wake fields and impedance data are stored per family, per

year, per version, per machine, and per OP_MODE of the machine.

6) Sums per machine, year, OP_MODE, for selected elements and versions.

7) Elements are populated from the layout database for a given year.

8) Optic functions and parameters are populated by loading Twiss MAD files for a given year, machine and OP_MODE.

9) Tunes, γ and γtr are stored per year, per machine and per OP_MODE.

10)Elements built from cells store the compound wake field per family.

9/20

Conceptual modelCategory

Name: string

*Wakefield

Record

CoordinateS: doubleW: double

Wakefield

Version

*Impedance

Version

*

In addition to the version, wake fields, impedances and optic functions are stored per machine, year, and OP_MODE.

*Impedance

Record

CoordinateS: doubleRe: doubleIm: double

*Element

Name: string

*

Betas

βx : doubleβy : double

Family

Name: string

*

10/20

Conceptual model (cont’d)

machine

*

1

*

*

year* 1

version

*

1

* *OP_MODE

1

*

*

1 1

*

*

*

Category

Name: string

*Wakefield

Record

CoordinateS: doubleW: double

Wakefield*

Impedance*

*Impedance

Record

CoordinateS: doubleRe: doubleIm: double

*Element

Name: string

*

Betas

βx : doubleβy : double

Family

Name: string

*

- Same structures for wake fields

11/20Database schema (extract)

- Same structure for impedances- Sums related tables not shown- Ancillary tables not shown- Indexes not shown

12/20

SQL DDL exampleCREATE TABLE elem_family_wakefields ( machine_name VARCHAR2(10), machine_year INTEGER, op_mode_name VARCHAR2(30), element_family VARCHAR2(30), version_name VARCHAR2(40), input_file_x CLOB, input_file_y CLOB, config_file CLOB, CONSTRAINT elemfwakes_pk PRIMARY KEY (machine_name, machine_year,

op_mode_name, element_family, version_name),); CREATE TABLE elem_family_wakefield_recs ( machine_name VARCHAR2(10), machine_year INTEGER, op_mode_name VARCHAR2(30), element_family VARCHAR2(30), version_name VARCHAR2(40), coordinate_name VARCHAR2(20) CONSTRAINT

elemfwakerecs_coordinates_fk REFERENCES coordinates(coordinate_name), s BINARY_DOUBLE, x BINARY_DOUBLE, CONSTRAINT elemfwakerecs_pk PRIMARY KEY (machine_name, machine_year,

op_mode_name, element_family, version_name, coordinate_name, s), CONSTRAINT elemfwakerecs_wakes_fk FOREIGN KEY (machine_name,

machine_year, op_mode_name, element_family, version_name) REFERENCES elem_family_wakefields (machine_name, machine_year, op_mode_name, element_family, version_name)

) ORGANIZATION INDEX COMPRESS 6;

13/20

Populating the database

Current issues.

14/20

Populating the database in two stages

OracleSQL Tools

JavaApplication

Data administrator User

1Store substrate layers

of data beforehand

2Store wake fields & impedance data

15/20

Bottom-up layers of data

• Data that can be entered once for all: machines, categories, authors, methods…

• Data that must be entered once before hand: element_families, elements, OP_MODES…

• Data that must be entered beforehand each year: element_betas.

• Data that can be populated automatically: element_configs, element_family_configs.

• Data that must be entered by end-users of the ZBASE system: wakefields, impedances.

16/20

SQL DML example

• Populate element_families:CREATE SYNONYM mad_sequences for lhclayout.mad_sequences;INSERT INTO element_families (element_family, element_category)(

SELECT DISTINCT type_name, mad_class -- returns only one row FROM mad_sequences WHERE type_name=‘BPMYA’ AND version=‘STUDY’);

• Populate elements:INSERT INTO elements(element_name, element_family)(

SELECT name, type_nameFROM mad_sequencesWHERE type_name=‘BPMYA’ AND version=‘STUDY’

);

• Elements not belonging to the MAD sequence must be dealt with separately.

17/20

Java application

First prototype to store wake field and impedance data for

CST simulations.

18/20

First prototype

• Technologies– Written in Java 1.6. – Distributed through Java Web Start.

http://abwww.cern.ch/ap/dist/accsoft/app/accsoft-app-zbase/PRO/Zbase.jnlp

– Relies on the Swing GUI toolkit. – Accesses the database through JDBC.

• Current functionalities – Store CST simulation data into database (5 mn for

500KB*5). – Retrieve CST simulation data from database. – Compute impedance by direct Fourier transform (5 mn).

– Plot wake field and impedance.

19/20

First prototype (cont’d)

20/20

Conclusion and future work

• Database schema – Almost complete.

• Java application – CST simulation storage and retrieval. – Sum implementation to be improved.

• Populating the database – Nothing done. – Identify some families to be stored

first.