CBM Online Meeting

Name: CBM Online Meeting
Start: 2026-02-12T15:00:00+01:00
End: 2026-02-12T16:15:00+01:00
Location: Virtual

Donnerstag 12.02.2026, 15:00 → 16:15 Europe/Berlin

Virtual

Beschreibung

Zoom: see below

91452703794

Volker Friese

Ausblenden

● Extendend discussion on the recent Data Challenge (04.02.2026) for VT25

General discussion

Information about the DC was given by V. Friese in the Software Meeting of 12 February 2026.

Redmine issue for preparation of of the DC: Issue 3597

Organisation / Setup phase

It took us until lunch to get the system set up. Issues were:

Tuning of the replay system (number of streams, data rate): Is ok, taking into account that we had new components (TS client receiver from multiple streams) which were never tested before. We did not test on small scale (e.g., on a single node) before as we did in previous DCs. This should be improved for future occasions.
Histogram server: We ecountered some problems (container with ROOT, zmq errors). The startup script was not prepared in advance. To be improved for the future.

Operation

We lost some 16% of timeslices. The reasons are under investigation. The isues might be due to network failure. For more details, see https://redmine.cbm.gsi.de/attachments/4472 and the discussion in Redmine issue 3597.

In general, we need more monitoring information about the compute nodes and the network, including the syslogs. Best would be a meeting with the cluster operators / experts. V. Friese will trigger this.

Data processing

The CPU load was only about 10%. Without heavy computing (trigger and event builder are very fast, and real unpackers were not run), we are clearly memory and I/O limited. An assessment of CPU usage is not meaningful without the actual unpackers, which require simulation to raw data (message) level. Real unpackers would, in addtion to assess and optimize their performance, require parameters and would thus give us a better view on the requirements for parameter handling.

Output data

The output file name syntax (run/subrun/tsclient/process/counter) does not allow an esay loop over all files. On the long run, we will need a system for data and metadata management.

Prepration of the next DC (VT26)

Algorithms / Data processing software: what we need to establish is
- time-based reconstruction of STS (available)
- time-based tracking in STS
- event trigger based on STS tracks
- multi-threaded event-by-event reconstruction, including global tracking with CA
- multi-threaded event selection using KFParticle(Finder)
Timeslice distribution: prototype of successor of TSClient developed at ZIB
Process management: Prototype of DDS/ODC developed at JUK
Controls: Would be good to show the EDC coupled to the systems FLES and DDP.

● Other business

S. Zharko asks for a separate container for the parameter service. That will be coordinated with D. Hutter. D. Hutter proposed to give an overview of the container usage in one of the next meetings.

Es gibt eine zugehörige Notiz zu dieser Veranstaltung Anzeigen.

- 15:00 → 15:55
  Extendend discussion on the recent Data Challenge (04.02.2026) for VT25 55m
  Discussion points:
  - what worked, what did not work well?
  - what have we learned w.r.t. operation of CBM at day1?
  - what are the consequences / work items towards the next DC (high-rate)?
  General discussion
  
  Information about the DC was given by V. Friese in the Software Meeting of 12 February 2026.
  
  Redmine issue for preparation of of the DC: Issue 3597
  
  Organisation / Setup phase
  
  It took us until lunch to get the system set up. Issues were:
  
  Tuning of the replay system (number of streams, data rate): Is ok, taking into account that we had new components (TS client receiver from multiple streams) which were never tested before. We did not test on small scale (e.g., on a single node) before as we did in previous DCs. This should be improved for future occasions.
  
  Histogram server: We ecountered some problems (container with ROOT, zmq errors). The startup script was not prepared in advance. To be improved for the future.
  
  Operation
  
  We lost some 16% of timeslices. The reasons are under investigation. The isues might be due to network failure. For more details, see https://redmine.cbm.gsi.de/attachments/4472 and the discussion in Redmine issue 3597.
  
  In general, we need more monitoring information about the compute nodes and the network, including the syslogs. Best would be a meeting with the cluster operators / experts. V. Friese will trigger this.
  
  Data processing
  
  The CPU load was only about 10%. Without heavy computing (trigger and event builder are very fast, and real unpackers were not run), we are clearly memory and I/O limited. An assessment of CPU usage is not meaningful without the actual unpackers, which require simulation to raw data (message) level. Real unpackers would, in addtion to assess and optimize their performance, require parameters and would thus give us a better view on the requirements for parameter handling.
  
  Output data
  
  The output file name syntax (run/subrun/tsclient/process/counter) does not allow an esay loop over all files. On the long run, we will need a system for data and metadata management.
  
  Prepration of the next DC (VT26)
  
  Algorithms / Data processing software: what we need to establish is
  
  time-based reconstruction of STS (available)
  
  time-based tracking in STS
  
  event trigger based on STS tracks
  
  multi-threaded event-by-event reconstruction, including global tracking with CA
  
  multi-threaded event selection using KFParticle(Finder)
  
  Timeslice distribution: prototype of successor of TSClient developed at ZIB
  
  Process management: Prototype of DDS/ODC developed at JUK
  
  Controls: Would be good to show the EDC coupled to the systems FLES and DDP.
- 15:55 → 16:10
  
  Other business 15m
  
  S. Zharko asks for a separate container for the parameter service. That will be coordinated with D. Hutter. D. Hutter proposed to give an overview of the container usage in one of the next meetings.