Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  17 Sep 2025, Mark Grimes, Suggestion, Get manalyzer to configure midas::odb when running offline 
    Reply  17 Sep 2025, Konstantin Olchanski, Suggestion, Get manalyzer to configure midas::odb when running offline 
       Reply  18 Sep 2025, Mark Grimes, Suggestion, Get manalyzer to configure midas::odb when running offline 
          Reply  18 Sep 2025, Stefan Ritt, Suggestion, Get manalyzer to configure midas::odb when running offline 
             Reply  22 Sep 2025, Stefan Ritt, Suggestion, Get manalyzer to configure midas::odb when running offline 
                Reply  22 Sep 2025, Konstantin Olchanski, Suggestion, Get manalyzer to configure midas::odb when running offline 
                   Reply  22 Sep 2025, Stefan Ritt, Suggestion, Get manalyzer to configure midas::odb when running offline 
                Reply  26 Sep 2025, Mark Grimes, Suggestion, Get manalyzer to configure midas::odb when running offline 
          Reply  22 Sep 2025, Konstantin Olchanski, Suggestion, Get manalyzer to configure midas::odb when running offline 
             Reply  22 Sep 2025, Stefan Ritt, Suggestion, Get manalyzer to configure midas::odb when running offline 
Message ID: 3083     Entry time: 22 Sep 2025     In reply to: 3077     Reply to this: 3086
Author: Konstantin Olchanski 
Topic: Suggestion 
Subject: Get manalyzer to configure midas::odb when running offline 
> > ....Before commit of this patch, can you confirm the RunInfo destructor
> > deletes this ODB stuff from odbxx? manalyzer takes object life times very seriously.
> 
> The call stores the ODB string in static members of the midas::odb class. So these will have a lifetime of the process or until they're replaced by another 
> call. When a midas::odb is instantiated it reads from these static members and then that data has the lifetime of that instance.

this is the behavious we need to modify.

> > Of course with this patch extending manalyzer to process two or more runs at the same time becomes impossible.
> Yes, I hadn't realised that was an option.

It is an option I would like to keep open. Not too many use cases, but imagine a "split brain" experiment
that has two MIDAS instances record data into two separate midas files. (if LIGO were to use MIDAS,
consider LIGO Hanford and LIGO Livingston).

Assuming data in these two data sets have common precision timestamps,
our task is to assemble data from two input files into single physics events. The analyzer will need
to read two input files, each file with it's run number, it's own ODB dump, etc, process the midas
events (unpack, calibrate, filter, etc), look at the timestamps, assemble the data into physics events.

This trivially generalizes into reading 2, 3, or more input files.

> For that to work I guess the aforementioned static members could be made thread local storage, and 
> processing of each run kept to a specific thread. Although I could imagine user code making assumptions and breaking, like storing a midas::odb as a 
> class member or something.

manalyzer is already multithreaded, if you will need to keep track of which thread should see which odbxx global object,
seems like abuse of the thread-local storage idea and intent.

> Note that I missed doing the same for the end of run event, which should probably also be added.

Ideally, the memory sanitizer will flag this for us, complain about anything that odbxx.clear() failes to free.

K.O.
ELOG V3.1.4-2e1708b5