News: Future of Confluence; Roaming detectors PCs; SardanaMacroExecutor; SardanaChat; Fs Data Management

• Future of Confluence (Atlassian Tools): Peter v.d. Reest organizes meetings with representatives from the DESY departments to understand the requirements and to discuss possible solutions. Who could join?

• Roaming detector PCs: detector PCs which are permanently assigned to a beamline have login restrictions. Logins using functional accounts from other beamlines are disabled. If such a detector is moved to another beamline this needs to be adjusted. Create a ticket in the fs-ec tracker.

• SardanaMacroExectutor:
  • the run_seq macro has been tested, works

    Docstring:
    Syntax:
            run_seq <seq_file> -> 
    
    
        run_seq commandFile.lis
    
          SequencyPath is the directory where commandFile.lis is stored, e.g.:
            spock> senv SequencyPath /home/p99user/temp
    
          commandFile.lis contains a list of spock commands, e.g.:
    
          #
          ascan exp_dmy01 0 1 10 0.1
          mv exp_dmy01 3
          # execute 2nd ascan
          ascan exp_dmy01 0 1 10 0.1
          mv exp_dmy01 2    
    Parameters:
            seq_file : (String) Name of the file with the sequency of macros
    

  • Tools: added SardanaMonitor, Lavue, pyspMonitor

  • Added some explanations about how to restrict the visibility of devices for remote users, see here

• SardanaChat.py: added time stamp and alias, see here

• Fs Data Management:

  News:

  • 14.4.2021: GPFS core will by extended, decided to purchase a new server 5.5 PiB, but: C-FEL buys a part of it and an old 900 TiB server ran out of maintenance.

  • 31.3.2021, dCache need better performance, esp. for many small files.

  • 31.3.2021, Science accounts: the registry-2 is needed for self-service password resets and resource management of science accounts. Currently certain platform adaptors are still missing.

  • Science accounts: request for simplifying the procedure. A discussion with IT has started. This problem is related to registry-2.

  • The pass-though mode is in preparation.

  • The pass-though will be enabled for beamtimes greater than X TB. ( first guess for X: 1 TB, AR and JH are investigating).

  • The GPFS core file system will be upgraded in the near future, 5.6 PiB (- 1.5 PiB for C-FEL).

  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

    Andre: commissioning data are created when groups overlap and when BL scientists align their setup. Commissioning runs are not saved to tape and they are not deleted. To answer the question: No.

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