1 / 10

Design of the Cuore DB

Design of the Cuore DB. Fabio Bellini Cristina Bulfon Riccardo Faccini Univesita’ “La Sapienza” e INFN Roma Berkeley Meeting Jan 24 th 2007. The context. Cuoricino currently has a database developed by Samuele Svn: http://crio.mib.infn.it/wwwsvn/filedetails.php?repname=dbq Web interface

randy
Download Presentation

Design of the Cuore DB

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design of the Cuore DB Fabio Bellini Cristina Bulfon Riccardo Faccini Univesita’ “La Sapienza” e INFN Roma Berkeley Meeting Jan 24th 2007

  2. The context • Cuoricino currently has a database developed by Samuele • Svn: http://crio.mib.infn.it/wwwsvn/filedetails.php?repname=dbq • Web interface • http://crio.mib.infn.it/cuore/dbQ/ • Information written by DAQ on flat file  scripts to transfer info to DB • Only software accessing DB is the web interface (no direct analysis use)

  3. The need • A need was identified for • Having an automatic writing from DAQ • Apollo, developed by the Genova group • Extend the writing to all relevant programs (including analysis jobs) • Utilize the database directly in analysis jobs • Create new tables for new needs • Since Samuele has now left to the REAL WORLD, the group of Rome has agreed to take over the development and maintenance of the new Database

  4. The Plan • Design a database suited for the needs of Cuore • Identify how it can serve also the analysis in Cuoricino • Port the Cuoricino database to this new one • Including web interface • Implement and maintain the Cuore Database Today: progress report on all items

  5. SlowMon [always] II level processing GUI [every “run”] I level processing DataBase Apollo (always) III level processing The needs of cuore Legenda: programma [quando gira] cosa scrive • Average pulse • Final stabilization • Coefficients (same intervals) Calibration • Ambient variables • Cryostat parameters • … • RawData • Total Trig rate • Trig rate by kind • Noise Level (?) • Baseline info • Run Conditions • Trigger parameters • HW Mapping • Power Spectrum? • Stabilizzazione preliminare • Coefficents • Time intervals • Monitoring plots for shifters • Raw or reco data data • Gain • Baseline • Pulse Rate by kind • Single • Double • Triangular • … • Trig rate by element • Per tower • Per xl • Per E-Card • …. • Trig rate by trigger • Single • Coincidence.. • Reco Data • Xl resolution • … Data storage • Dataset (different root files) • Dark Matter • 2B0N • … • physics results Same nomenclature as Cuore Data Analysis Document #3

  6. Identified “first principles” of the new database • Each table should contain quantities which as much as possible have the same update rate • “stable” • hardware • mapping • settings • run parameters • other (sub-run) • Each table should as much as possible be written by the same program • Protects integrity • Use primary keys (which are unique) and foreign keys (which must have an existing value) to protect integrity • if creating a new line in a table requires an object in a table the object must be referenced • Break any many-to-many relationship by inserting an intermediate table Note change of notation: measure  run [interval between He fills] run  runCycle [intervals between warmings]

  7. HEATERS • [list of existing heaters] • # he_name • * he_kind • he_qc • * he_comments • * he_resistence THERMS [list of existing thermistors] # th_name * th_kind * th_qc * th_comments * r0 * T0 * gamma FISCHERS [list of existing fischer pins] # fisch_id, pin_id XTALS [list of existing xtals] # xl_name * xl_size * xl_kind * xl_qc • FRONTENDS • [list of FE channels] • # fe_id • * fe_board • fe_controller • fe_channel • PULSERS • [list of existing pulsers] • # pulse_id • * p_ch • p_name o comments • DIGITALS • [list of DAQ channels] • # daq_id • * daq_board • daq_crate • daq_channel • daq_type • BESSELS • [list of bessel channels] • # bes_id • * bes_board • bes_controller • bes_channel • bes_slot BOLOSTATUS # bolo_id FK * vbol * rbol * tbol * time_start o time_stop • BOLOMETERS • [assembled bolometers1] • # bolo_id • * det_id FK • o xl_name FK • o he_name FK • * th_name FK • * fisch_id,pin_id FK • * bolo_name • * bolo_tower • * bolo_floor • * bolo_pos • * bolo_x • * bolo_y • bolo_z • * bolo_kind • o comments • CRYOSTAT • # time validity ,det_id FK • main_bath_p • * main_bath_l • * main_bath_flow* 1kpot_level • * mixture_flow* 1kpot_p* 1kpot_t • * 1kpot_flow • * g4_p • * condenser_p • * p_mix • * p_still • p_tower DAQSETTINGS # daq_set, daq_id FK * flag_act * flag_gain * threshold * debounce * n_point * pulse_length * v_adc_limit_min * v_adc_limit_max • FESETTINGS • # fe_set, fe_id FK • * mema o v_bias • * memb o v_tot • * memc o rload • * memd o v_offset • dach • dacl MAPS [maps bolos and electronics3 ] # lg, profile_id FK o bolo_id FK o pulse_id FK o fe_id FK o bes_id FK * daq_id FK PULSERSETTINGS # p_set, pulse_id FK * mem0 o p_amplitude * mem1 o inc_state * mem2 o inc_factor * mem3 o dec_state o dec_factor o num_inc o width DETECTORS [array/towers of bolometrs2] # det_id * run_cycle * det_name * run_cycle4 * start_date * end_date o comments • PROFILES • [hardware configuration ] • # profile_id • * det_id • * profile_name • profile_comments • create_date • is_default • locked BESSETTINGS # bes_set, bes_id FK * mem * bes_param TRGSETTINGS # trg_set,bolo_id FK * trg1_enable * trg1_name * trg1_pars * … (4 trgs) SETDAQSTNGS #daq_set * creation_date o comments SETPLSSTNGS # p_set * creation_date o comments SETFESTNGS # fe_set * creation_date o comments SETBESSTNGS # trg_set * creation_date o comments • RUNS • [run configuration and stats5 ] • # run_number • * det_id4 • * profile_id FK * n_trg • fe_set FK * n_noise • trg_set FK * n_pulse • bes_set FK • daq_set FK • run_type FK • shifter_names • start_date • stop_date • ins_date • comments • stop_status • to_be_saved • saved • n_files SETTRGSTNGS # trg_set * creation_date o comments HW configuration and settings LEGENDA: # Primary key * compulsory attribute o facultative attribute FK Foreign key — 1 instance/ relationship ► many instances/rel. Time frequencies — almost unchanged — hardware — mapping — setting — run — other time interval USERS # user_name * passwd * date_created * level RUNTYPES # run_type * description STOPSTATUS # status_id * status * message

  8. Calibrations • USED_STABILIZATIONS • * stab_algo --FK • * bolo_id – FK • * stab_time_ins – FK • * stab_time_start – FK • stab_time_end – FK • * calib_algo –FK • * calib_set – FK • * calib_time_ins • STABILIZATIONS • # stab_algo --FK • # bolo_id – FK • # stab_time_start • # stab_time_end • # stab_time_ins • * ap_algo --FK • * ap_time_start --FK • * ap_time_end --FK • * ns_algo -- FK • * ps_time_start • * ps_time_end • * offset • * slope • pre-resolution • post-resolution CALIB-SETS # calib_set * start_run * end_run STAB-PARAMS [bolometer by bolometer] # stab_algo --FK # bolo_id – FK o st_position o n_poly_b o n_sigma_b o fit_type_b o n_poly_t o n_sigma_t o fit_type_t o min_delta_A o max_delta_A o min_delta_b o max_delta_b • CALIBRATIONS • # calib_algo –FK • # calib_set – FK • # calib_time_ins • # bolo_id – FK • calib_time_start • calib_time_end • * constant POWER-SPECTRA # ns_algo -- FK # bolo_id – FK # ps_time_start # ps_time_end * powerspectrum AVG-PULSES # ap_algo --FK # bolo_id – FK # ap_time_start # ap_time_end * Avgpulse • STAB-ALGOS • [change in criteria flags a change in algo] • # stab_algo • wiener_filter • o wien_n_baseline o amp_corr • o wien_n_smooth o windowing • o wien_decomp o one_side • o wien_max_second o rise_time • o wien_adaptive_fd o n_points_base • o max_frac o n_chan_af • o min_amp o n_chan_maxmin • o max_second o n_smooth • Description o n_points • o least_square test • o signed_test • o differentiated • o window_type CALIB-ALGORITHMS # calib_algo * description AP-ALGOS # ap_algo * description NS-ALGOS # ns_algo * description • Notes: • Power spectra and average pulses are computed with their own periodicity • stabilizations are supposed to have validity intervals comprised into the PS and AP ones • analysis criteria used in input are listed within the STAB_PARAMS (could be improved if needed) • calibrations have validity intervals which are supersets of the stabilizations • sql does not support versioning  hand made with the insertion time  anything better?

  9. Location of database(s) An open issue • A copy of the database should reside where the DAQ is • Cannot stop data taking because of connectivity problems • Several DAQs running at the same time expected (HallC,Cuoricino,…) • The master database, to be used for analysis, should be the merge of all the existing ones • Where should it reside? (LNGS?) • Periodic mirrors • Tolerable delay in update? (few weeks, a part from conference seasons?) • Merging in a safe way is an engineering problem • Cristina is looking at it

  10. Status and short term plans • Scripts to implement the new database are in place in the http://crio.mib.infn.it/wsvn/dbt svn repository > svn co http://crio.mib.infn.it/svn/dbt to check them out • Scripts to insert the current Cuoricino variables under test • Web interface being worked on (Cristina) • Implementing a beta version in Rome • Need decision on where it will eventually reside • Make your own empty copy with sql createdb qdb psql qdb # \i CreateQdbTable.sql • Hope to see it used soon with the new DAQ and authomatic stabilization

More Related