News: MacroServer gets stuck at P23; FlagProtected; new python-sardana package; Eger prepareDetectorAttrs(); cleanup hasyutils, pyspectra, tnggui package distribution; Fs Data Management

• MacroServer got stuck at P23: SardanaAIO.py did not reset things. If such a condition occurs, consider killing the MacroServer by hand 'kill -9 ...'. Use TngGui.py to identify the problem, inspect log files and device attributes.

• OmvVme58, FlagProtected: was announced in P3C and in an email to p3-scientists. To find the status of the FlagProtected attribute:

  TngUtility.py --list Oms --dbhost haspp09 --attr flagprotected > temp.lis
  emacs temp.lis
  

• python-sardana package updated: fix for the macroserver.properties bug.

• Eiger: changed prepareDetectosAttrs(): added ArmFlag and ImagesPerFile ( request by P08, P10)

  HasyUtils.prepareDetectorAttrs( self, 
                                  name = detectorName,
                                  trig_mode = 'ints',
                                  nbFrames = 1, # per trigger 
                                  acq_time = scanInfo[ 'sampleTime'], 
                                  NbTriggers = scanInfo[ 'intervals'] + 1,
                                  ArmFlag = True,
                                  ImagesPerFile = 1000)
  

  The FilenamePattern changed to (request by P08)

  FilenamePattern = current/raw/<prefix>_<ScanID>/<detectorName>/<prefix>_<ScanID>
  

• cleanup hasyutils, pyspectra, tnggui package distribution: so far python and python3 packages have been installed on the PCs. Changed: Debian-9: python, Debian-10: python3.

  That means

  Debian-9: 
    SardanaAIO.py 
    SardanaRestartMacroServer.py 
    pyspMonitor.py
  
  Debian-10
    SardanaAIO3.py 
    SardanaRestartMacroServer3.py 
    pyspMonitor3.py
  

  appear separated on the PCs. Tabulator is not longer confused.

• Fs Data Management: new demanding detectors forced us to reconsider our data management strategies. In collaboration with IT a note has been prepared proposing several measures which are currently being discussed:

  Summary:

  • the data-on-disk time will be limited to 90 days after the beamtime as ended.

  • the beamline file system will no longer store complete beamtimes. Instead this server will act as a pass-through buffer for data to be moved to the core file system.

  • a substantial upgrades of the FS-related IT infrastructure of the computer center are needed.

  • storage demands may become part of the proposal evaluation

  • maturity of the data analysis pipeline may also be considered during the proposal evaluation

  • the purchase of new detectors has to be reviewed for impact on data volumes.

  Concerns:

  • implement a simplified procedure for creating scientific accounts?

    The reason for this request is of course that the data are quickly moved to the core where they can only (except for exceptions) be accessed from real accounts.

  • can small beamtimes stay in the BL FS?

  • what about commissioning data? Does the 90 days rule also apply?

    The confluence page about the commissioning path can be found here

  • FLASH: for beamtime > xTB 90 days, for beamtimes < xTB 360 days, with x being in the range 5-10 TB