Choose timezone
Your profile timezone:
DAQ/Readout WG meeting n.10
→
Europe/Zurich
The Web
The Web
Minutes of Meeting #10 + DAQ/Readout WG
16 December 2013 - 10:00 --
NEXT meeting : TBD via Doodle...
Indico page:
Note: all the possible mentioned attachments (slides, documents, etc.) are present in the indico pages
---
PARTICIPANTS
APC
A. Creusot (A.C.)
CPPM
none
ECAP
none
GRPHE
A. Albert (A.A.)
INFN
C. Bozza (C.B., Salerno), T. Chiarusi (T.C., Bologna), C. Pellegrino (C.P., Bologna)
V. Kulikovsky (V.K., Genova)
NIKHEF
R. Bruijn (R.B.) , V. Van Beveren (V.V.B.)
1. Introduction
T.C. reports what has been discussed at the SC. DAQ design ok but slightly modified the acoustic data flow (passing through a dedicated acoustic TriDAS)
T.C. reports about that in January it is planned to discuss with Acou people for planning into detail the acou stream handling.
T.C. reports the question of Maarten concerning the possibility to add tiltmeter and compass data directly to the post-trigger files, together with optical data.
No decision taken today, but this item should be carefully re-discussed.
2. Data Filter/Writer
Few word to report that R.B. is still "dealing" to update the Jpp clases ( JDAQChronometer...) in order to live with the new Data Types that changed slightly
Nothing more to report.
3. Control Unit
C.B. reports about the implementation of the SAWI (Service Application Web Interface), which can be considered completed (further changes are foreseen, but of the second order).
Further implementations of CU services built on top HTTP/HTML.
Autentication: any token has its own list of privileges
Concerning the various kind of privileges/levels T.C. remind to add the "Observer" kind, for people that are not allowd to do nothing but see what's up.
T.C. also suggest that the various privileges to people could be moderated by some time scheduling connected to the DB (and for this to the Run scheduling).
Next step: - proceed in parallel for integrating DB interface (strong interaction with A.A.) and for implementing the SC interface (strong interaction with V.V.B).
4. Data Base Interface
A.A. present a first deisgn of the Database scheme, starting from the various possible runsetup.
The discussion gets into the details of how the data must be organized before being passed to the
CLBs. V.V.B. says that they should be compactified per groups of items belonging to the same macro cathegory: optics, acoustics, instruments etc. (PLEASE CHECK THIS STATEMENT)
No XML is embedded in the CLB.
Strong interaction to decide about this item will be required among A.A. and V.V.B and together with C.B., who is taking care about the SC module in the CU.
A.A. and V.V.B underline the necessity to get the Data Dictionary.
C.B. put a question concerning the DB configuration: who is supposed to do it and how?
T.C. suggest that the DB interface should cover this task for paramenterizations that are relevant to the DAQ, but C.B. would stay more general, without an expressed custom-made "configurator" which could limit the access to the DB.
A.A. asks how the CLBs will get their own IP.
T.C and V.V.B. confirm that WR system provides CLBs with MAC address.
The IP should be decided in advance, at the moment of the network design.
It can be set manually during CLB integration as well as distributed via DHCP.
5. Slow Control Interface
V.V.B. reports very good news from Nikhef: CLB network connectivity UP, and SC working over network.
V.V.B. reports about possible implementation of the CLB local repository for configurations. In any case such configurations should be conformal to the DB configuration (or at least to the organization of the information retrieved from the DB).
Three layers of info are used:
- ID layer for each CLB (mainly with the IP coded)
- current chosen run setup (with the actual parameters that specialize that given run )
- a default basic configuration which can be overridden by the chosen run setup config.
At the moment a JAVA GUI for tests will be soon implemented to simulate the DB interface.
A discussion concerning the data format originated among V.V.B., A.A., C.B. and T.C.
It is a very important issue to solve, and this should be carefully discussed in the next weeks.
JAVA API need to know the tyes of data.
ACTION: V.V.B, A.A. and C.B. , following the specifics of the SC protocol interface, will decide the data-format and summarize the decision in the next W.G. meeting.
6. PPM-DU
A.C. reports the activities in APC at the test-bench of the PPM-DU.
Simone Biagi, together with Tassos Belias and A.C. managed to operate 2 different crates with 1 Run Control Process.
One crate (the Erlangen one) has been fixed after the partial intervention of Saclay people.
GPS was connected too, but currently in Paris there is not any CLB, so it was not possible to test the conformity of timing distribution (work of half a day, being CLBs available).
7. Varia and conclusions
T.C. introduces Carmelo Pellegrino, a new PhD-student in Bologna who will give contributions to the Data Queue development.
V.K. agrees to meet next January for discussing the acoustic data handling, involving the Erlangen group (Robert Lamhann and colleagues).
8. NEXT MEETING ARRANGEMENT
T.C. reports that next KM3NeT steering committee wil take place in Paris, Januray 8th-9th.
It is unfeasible and also useless to organize a new DAQ/Readout W.G. before such a data.
Let's put our preference via Doodle, at the following link:
http://doodle.com/3fd4xfs5z258bfrq
There are minutes attached to this event.
Show them.