deletions | additions       diff --git a/sectionPROPOSED_SECO.tex b/sectionPROPOSED_SECO.tex  index 2d54681..642e628 100644  --- a/sectionPROPOSED_SECO.tex  +++ b/sectionPROPOSED_SECO.tex 
...
There cannot be a simple rule to calculate the start and stop of these types of event;   but they should be recorded if they have an influence on a significant number of the experiments.   {\em ALBA} records Currently  beam unrelated events only, if the events taking place up to the beamlines front-ends.   Under this category insertion device failures which have an impact on the operation of a specific beamline are recorded, also recorded incidences  are vacuum events at front ends.   There is no recording of events taking place considered to be ``downtime''  at the beamlines themselves.   {\em Elettra} considers all kind of failures ``beam downtime'' that prevents some facilities,   if they prevent  all the beamlines beamline  to continuewith  their experiments, even if the failures do not directly affect the beam.  If measurements.  This is  the failures are only taking place case  at the beamlines themselves, then they are not recorded.   {\em LNLS-UVX} operator records all beam-unrelated failures in the e-log system.   The database includes the front-ends but, except for those events that have some impact on machine operation, it does not include data from the beamlines.   UVX is basically a dipole based light source, with just two wigglers ALBA, Elettra  anda single EPU, which is the only device controlled by the users. Problems with  the IDs are registered as faults in the datalog even when they SLS.  Other facilities  do not lead to a ``no-beam'' event.   Events related to infrastructure usually affect all beamlines and if they cannot operate the fault leads to a ``no-beam'' event.   But none neglect those types  of these events are automatically entered in the database.   {\em PETRA III} does not count beam-unrelated failures which do not prevent the machine from running within its limits event for their downtime calculation,   as long  asdowntime.  {\em SPring-8} has a control system that heavily depends on  the database; so if some trouble electron beam was not affected.  At most facilities those types  ofthe database occurs, the top-up injection, the orbit feedback, and so on stop.   Those  events are rare, we have them once every few years.   But the beamline control is completely independent evaluated on a case by case basis:  for example an interlock  of the machine one, so user operation can continue in the decay mode.  {\em SLS} adds currently those events manually to the operation event database.  We plan to record problems in the control system communication between the beamline all photon shutter would clearly be considered ``downtime'',   at least at ALBA, BESSY II  and LNLS-UVX;  but a problem with  the machine, since the communication gateways used there did produce problems in IT infrastructure might not, even if  the past in infrequent intervals.   These problems may prevent some beamlines from certain measurements, like synchronous changes majority  of the undulator- and the monochromator-energy. users where affected.  \subsection{Short-user-time}  Many facilities have a cut off for a minimal time to store the beam.  
...
An independent recording of these events would enable to calculate beam availability with and without accounting for the ``Short-user-time';.  This would improve the comparison between facilities that handle ``Short-user-time'' differently.