DMS meeting 2012 July 27th - 11am CET
EVO connection
Agenda:
- DMS team organization
- Draft documents about the previous DMS: [DMS description] [DMS User Manual]
- Regular EVO meetings + web repository for temporary documents and minutes of meetings ?
- Who is in charge of what?
- Who coordinates?
- General comments on the "DMS for Advanced Virgo" document
The proposed plan of the document is:
- Introduction1: reminding the previous version of DMS and its architecture.
- Introduction2: AdV DMS architecture proposed with computing and software requirements
- Short description of the DMS input parts (Moni, BigBrother, etc...) which produce the flags.
- Description of the changes to be done on the Moni library and Moni processes configurations
- Description of the changes to be done in the PHP scripts dealing with DMS web pages displayed in control room
- Some question marks about the content of the document
- The Moni library part
- What should be the maximal latency of the DMS information?
- Is it ok to have no more bit-coded flags?
- Is it ok to have flags value only equal to +1 (flag is red) ,0 (flag is green) or -1 (flag could not evaluated)
and to have a separate value to code for any additional information (drak grey, yellow, etc...)?
- Is it ok to have only level 0 and level 1 flags built by Moni processes?
Just to prevent missunderstanding: level 2 flags are for me the main flags shown on the left on the
main web page. level 1 flags are the next flags on each line of the main web page, level 0 flags
are those shown on the level2 web page.
- Is it ok to simplify xml files and change some of the keywords?
- Would it be convenient to have only one DMS package containing all the C code and PHP scripts used by DMS?
- Should we develop a new ServersMoni process which will not used existence of data channels
but will get direct information from the servers.
- The DMS scripts part
- Is it ok to regroup level 1 flags to build level 2 flags only in the DMS script?
Just to prevent missunderstanding: level 2 flags are for me the main flags shown on the left on the
main web page. level 1 flags are the next flags on each line of the main web page, level 0 flags
are those shown on the level2 web page.
- How useful is it to keep the yellow color pre-alarm?
- If we remove any "Depend" feature, in which case would it be useful to keep
the light red color associated to "problem induced by an other item"?
- How useful is it to keep the dark grey color alarm saying that a channel used to build the flag
is corrupted. Is it really useful to distinguish this from the light grey color alarm which
says that the flag could not be evaluated (often because a channel is missing)?
- Is there a real difference between the "Time Delay" and the "Persistence" features? OK, understood.
- Should the "Depend" features be kept in DMS script even if DEPEND keyword is not used anymore
in the future ServersMoni process?
- Do we really need to have a difference between "Aggregate Flags" (Alarm Pre-filtering) and "Group" (Alarm Filtering) features?
- Do we really need to have a difference between "Shelving" (Alarm pre-filtering) and "Muting" (Alarm Filtering for notification) features?
- Should we ask for a better machine for DMS. If yes, should it be done soon?
- What is "a backup machine to implement a mechanism of master/slave and make the system more reliable"?
- How useful is it to have automatic sms or emails sent?
Instead, could the operator be the only interface between
DMS alarms and the experts on-call?
- AOB
------------------------------------------------------------------------
#############################################################
Minutes:
#############################################################
Attendance: Francesco, Vincenzo, Didier
Minutes taker: Didier
- DMS team organization
- Draft documents about the previous DMS: [DMS description] [DMS User Manual]
It is agreed that Didier will do modifications on those documents and will be in the authors list.
Didier proposes also that a DMS team is defined and that the full team signs any DMS-related document.
It is agreed also that DMS definition should be enlarged and include also the DMS flags providers (Moni processes,
BigBrother, AlpDMS, etc...).
- Regular EVO meetings + web repository for temporary documents and minutes of meetings ?
Vincenzo explains that there is already a DMS wiki section in the EGO Working Area that
contains minutes of previous meetings and documents. Didier will transfer these minutes
and the attached documents in this area.
Vincenzo explains also that previous meetings (for instance in March 2011 and Dec 2011) were
focalized on DMS scripts and web page related items. In the future, Didier will be included
in the meetings and will have wiki page permissions.
Vincenzo explains also that current activity on the Virgo instrument (especially the input MC)
engages both Vincenzo and Francesco, so they planned to postpone by about one year any upgrade
of the DMS. Meanwhile, a first document containing requirements for DMS upgrade can be
set up but without any regular meeting and with low priority.
- Who is in charge of what?
In the past, Fabio was in charge of AlpDMS, Francesco (+Gary?) was in charge of DMS scripts, Franco was
taking care of BigBrother, Didier was in charge of Moni library and processes, Vincenzo was coordinating
and working on Alarms, Configs, etc... We plan to adopt the same team and tasks repartition
for the DMS upgrade [to be confirmed and better detailed].
- Who coordinates?
For now, Vincenzo continues to coordinate. We agree that it may be Francesco in the future.
We did not discussed in details the items below, since DMS upgrade is postpone. Any further
work on the draft document "DMS for Advanced Virgo" will occur through emails, except if a detail discussion
is needed. Didier's first plan was to upgrade the Moni library in the coming months in order
to make the DMS flags standard and usable also for data analysis.
The changes proposed by Didier in the document imply some changes in the configuration files
of the Moni processes and in the format of output xml files.
Didier will do more detailed proposal with full examples of a new config file and of a new
xml file. He will try to reduce as much as possible the changes in the xml files so that
DMS scripts (and also the flags providers) do not have to change too much their codes.
It is agreed that Didier provide those details in one month or two and that comments
on this detailed proposal will be made by the team in the following weeks.
An other DMS meeting will occur if needed, but not before end of September.
First decisions on which we have agreed on:
- The DMS flags will have only values +1, 0 or -1 and will not be anymore bit-coded.
- An additional field in the xml files will contain the information like yellow or grey flag
which was contained previously in the flag's value.
- The yellow flags were useful, we should try to keep them.
- The production of level 2 flags (which are a OR of level 1 flags) by the Moni processes should be kept.
It may not be a big deal to keep the production of level 2 flags in the Moni processes
but Didier thinks that the DMS script config could be changed in order
to do the OR of level 1 flags itself. Maybe a subject for future discussion.
- General comments on the "DMS for Advanced Virgo" document
The proposed plan of the document is:
- Introduction1: reminding the previous version of DMS and its architecture.
- Introduction2: AdV DMS architecture proposed with computing and software requirements
- Short description of the DMS input parts (Moni, BigBrother, etc...) which produce the flags.
- Description of the changes to be done on the Moni library and Moni processes configurations
- Description of the changes to be done in the PHP scripts dealing with DMS web pages displayed in control room
- Some question marks about the content of the document
- The Moni library part
- What should be the maximal latency of the DMS information?
- Is it ok to have no more bit-coded flags?
- Is it ok to have flags value only equal to +1 (flag is red) ,0 (flag is green) or -1 (flag could not evaluated)
and to have a separate value to code for any additional information (drak grey, yellow, etc...)?
- Is it ok to have only level 0 and level 1 flags built by Moni processes?
Just to prevent missunderstanding: level 2 flags are for me the main flags shown on the left on the
main web page. level 1 flags are the next flags on each line of the main web page, level 0 flags
are those shown on the level2 web page.
- Is it ok to simplify xml files and change some of the keywords?
- Would it be convenient to have only one DMS package containing all the C code and PHP scripts used by DMS?
- Should we develop a new ServersMoni process which will not used existence of data channels
but will get direct information from the servers.
- The DMS scripts part
- Is it ok to regroup level 1 flags to build level 2 flags only in the DMS script?
Just to prevent missunderstanding: level 2 flags are for me the main flags shown on the left on the
main web page. level 1 flags are the next flags on each line of the main web page, level 0 flags
are those shown on the level2 web page.
- How useful is it to keep the yellow color pre-alarm?
- If we remove any "Depend" feature, in which case would it be useful to keep
the light red color associated to "problem induced by an other item"?
- How useful is it to keep the dark grey color alarm saying that a channel used to build the flag
is corrupted. Is it really useful to distinguish this from the light grey color alarm which
says that the flag could not be evaluated (often because a channel is missing)?
- Is there a real difference between the "Time Delay" and the "Persistence" features? OK, understood.
- Should the "Depend" features be kept in DMS script even if DEPEND keyword is not used anymore
in the future ServersMoni process?
- Do we really need to have a difference between "Aggregate Flags" (Alarm Pre-filtering) and "Group" (Alarm Filtering) features?
- Do we really need to have a difference between "Shelving" (Alarm pre-filtering) and "Muting" (Alarm Filtering for notification) features?
- Should we ask for a better machine for DMS. If yes, should it be done soon?
- What is "a backup machine to implement a mechanism of master/slave and make the system more reliable"?
- How useful is it to have automatic sms or emails sent?
Instead, could the operator be the only interface between
DMS alarms and the experts on-call?