Clara, Olivier, Oliver, Manuel, Helfried, Stefan, André, Frank, Bobby, Renaud, Atanassov, Lucas and Wayne
1) External Data Handling and DIP
Oliver gave an overview of the various components available for external data exchange and the current status of each.
His slides can be found under:
http://indico.cern.ch/conferenceDisplay.py?confId=27441
The following points/questions were raised:
CaV:
All but 3 sub-detector scy files have been received and tested (meaning that are compatible with the FW CaV component). TOTEM has its file and will send it to Oliver.
Although there is an agreement on what information should be provided by TS/CV and how to do this, there has been little progress on actually providing it! Wayne and Oliver will follow up on this. This is considered very important for the experiments.
Names for TS data are in French. It was decided to leave it like this for easier discussion with the CCC and piquet in case of problems. However, an option will be provided to have a second field in which an English translation could be provided. The translation would be provided by the experiments themselves.
MCS:
Stefan reported that the DIP data rate had recently changed. Not only is it unacceptable for this to happen without warning but it also shows that Silvain Rabat is not using DIP in the foreseen manner. To be followed up.
LACS:
Prototype is available but waiting for data to be published. Wayne and Oliver will check with Luigi. There was also the question about whether information of who is in the zone will be available to the experiments. How are subzones managed?
CSAM:
Data is already being published (>15,000 DIP items). There is a misuse of a separator which causes problems with the DIP browser. A fix in the browser is possible but this should also e followed up with the CSAM people as the separator used is not conformant. Alarms should be put into the PVSS DCS Alarm Screen. No particular synoptics are required. To avoid the need to have to access the TS database from the ENs, a pre-configured component could be provided to each experiment. There are potential problems if the data is changed afterwards.
RAMSES:
A first discussion was held and it looks like that this should be fairly simple to implement. It should be considered whether a synoptic showing the location of the RAMSES monitors is practical.
LHC Machine:
It was requested to have a simple generic panel (similar to the page 1 from LEP times). TOTEM has more information concerning LHC data. Oliver to check with Lucas.
GCS:
The data which is foreseen to be exchanged is defined in documents one the IT/CO web site. Please see the links below:
http://itcofe.web.cern.ch/itcofe/Projects/LHC-GCS/Analysis/RelatedDocuments/GCS-DCS-ICD_v1-10.pdf
The future versions are published under:
http://itcofe.web.cern.ch/itcofe/Projects/LHC-GCS/Analysis/welcome.html
There is a distribution list to inform users when a new version is available. Please let Renaud know if you wish to be added to this distribution list.
A generic panel has been developed by ALICE which could be of interest to the other experiments. Oliver will see Marco regarding this.
DSS: It is possible to publish any DSS data and this is under the control of the experiment. Hence, the DSS component can subscribe to all published data by default. DSS alarms should be put into the PVSS DCS Alarm Screen.
2. New Applications
The following new applications were requested.
TS/EL:
Despite many requests over the last 2+ years to TS/EL we still do not have anything. Wayne will again contact Georges Burdet.
Proximity Cryogenics:
This seemed to be only relevant for ATLAS which already has an implementation but there are some issues. A specific meeting with Marco Pezzetti could be useful. Renaud to follow up on this.
Primary Gas:
Under the responsibility of David McFarlane but Stefan Haider would be keen to take this over. Renaud will follow this up.
Sniffer:
Silvia Grau to be contacted to see what would be possible.
Networking:
Helfried requested information on network problems. To be followed up.
3. Miscellaneous
It was suggested that should be a recommendation that there should only be a small number (preferably 1) of publisher/subscriber machines per domain and that a table of connections be produced to help with establishing the necessary network connection between them. Stefan requested that all DIP domains provide heartbeat from the underlying data producer, e.g. PLC, to be able to see if everything is working correctly. It was noted that DIP itself provides information on the publisher/subscriber connection status.
There are minutes attached to this event.
Show them.