Options to test RD lines

This Snippet provides the options to run Moore only with the RD lines and perform bandwidth and rate studies. The file rd-lines.py allows to run Moore and generate the output MDF file together with the monitoring histograms and the manifest file. The file rd-sprucing-lines.py allows to run the sprucing over HLT2 samples. The file hlt2-studies.py allows to determine the rates of the lines using the information from the output printed by Moore.

The argument for following this approach and not using HltEfficiencyChecker is that the latter can not run multi-threaded due to the tupling. Therefore there is a significant improvement on the execution time. When running on signal simulation it is still a good idea to use HltEfficiencyChecker to determine the efficiencies, although something similar can be done by using the information from the monitoring histograms (e.g. the invariant mass histogram).

To run any of these scripts you will need the stack to be installed in your desktop machine. Follow the instructions in lb-stack-setup to do so. It is highly recommended to switch off the Moore functor cache when doing developments since it will slow-down the compilation considerably. This can be done by passing more options to the stack configuration file

utils/config.py -- cmakeFlags.Moore '-DLOKI_BUILD_FUNCTOR_CACHE=OFF'

Note that by doing this you will compile the functor cache the first time you run Moore with a set of options and put it in a temporary directory. This cache will be reused as long as your developments do not alter the functors to be compiled.

Executing the scripts

The recommended way of running tests is:

• Run Moore first to produce the output and redirect the output to a file, e.g.

Moore/build.x86_64_v2-el9-gcc13-opt/run gaudirun.py rd-lines.py | tee rd_data.log

• Compress the result file (bandwidth must be computed using the compressed file size) via e.g.

zstd -3 hlt2_bandwidth_rd_data.mdf

which will create a file named hlt2_bandwidth_rd_data.mdf.zst. To get the size of it simply do

du -h hlt2_bandwidth_rd_data.mdf.zdst

• Determine the rates using hlt2-studies.py with any environment that has the basic python packages pandas, uproot, ... via

./hlt2-studies.py rates-from-log rd_data.log --input-rate 1289692

The latter will produce a Markdown file with the HLT2 rates per line. To compare two different results (you should be using a sample with a similar input rate), run:

./hlt2-studies.py compare-rates before.log after.log --input-rate 1289692

You can also explore the monitoring histograms and do some checks (like on the number of candidates) via

./hlt2-studies.py check-histograms <root file> --regex 'Hlt2RD_.*'

You can modify a few options in rd-lines.py, like the number of events to process or the number of threads. You can also switch from real data to the latest simulation.

Note that rd-lines.py will run both HLT2 and Turbo lines. A similar procedure can be followed to test sprucing lines on HLT2-filtered data, using the rd-sprucing-lines.py options file. If you want to run the latter on the data produced by the former step, then you will simply need to change the input file properties of the rd-sprucing-lines.py script. The sprucing pass-through (meant to be executed after Turbo) can be run via

Moore/build.x86_64_v2-el9-gcc13-opt/run gaudirun.py rd-spruce-passthrough.py

This will create a DST file, which can be later used to make a tuple.

Efficiencies

In order to test efficiencies, you can refer to the HltEfficiencyChecker documentation. However, you might find simpler and faster to simply run the same script as for the data (the one discussed on the previous section) on your simulated sample and then look at the monitoring histograms. Since there is no distinction between online (HLT2) and offline candidates you can use the invariant mass monitoring plot to measure the number of candidates passing the line. Note that you might need to change the monitoring variables of your line if it is a signal line, since the invariant mass is not processed by default (to avoid unblinding measurements).

Bandwidth

Computing the bandwidth for specific lines is harder, but you can always run the previous commands with and without your changes and see the difference on the file size. The bandwidth is then simply the ratio between the compressed file size (hlt2_bandwidth_rd_data.mdf.zdst in the previous section) divided by the number of output HLT2 events and multiplied by the output HLT2 rate. The following expressions are equivalent:

In other words, if you always run over the same sample and the same number of candidates, you can compute its ratio and then evaluate changes to the bandwidth by simply looking at the size of the compressed file.

Throughput

For measuring the throughput, a first-order estimate can be done by running on the same machine the lines without and with your changes and measuring the time. Ensure that no other processes are running to be able to compare pears to pears. The throughput is then simply the ratio between the total number of input events and the time taken to process them.

Avoid using lxplus for this purpose, since it is very prone to having lots of subprocesses or other users connected that will disrupt your tests and lead to unreliable results.

Alternatively, you can execute your algorithms and compare the execution time with other general algorithms in the same sequence that run before yours (e.g. the standard particle makers). This way you can guesstimate the changes in the throughput with respect to a reference execution by studying the time ratio for the same algorithm.

This is true as long as the behavior of the general algorithm that you have chosen is not affected by your changes, and as long as there are no other factors that could make the general algorithm be executed with a time variation that is non-proportional with respect to other algorithms in the sequence. The results obtained this way might be more accurate since they are less affected by environment changes in the executions (e.g. latency problems with databases or accessing data files).

Making a tuple

In order to tuple the output of your line, it is recommended that you have run the Sprucing, which will create a DST file. You can then execute

lb-run davinci/v64r13 lbexec funtuple:main funtuple.yml

changing funtuple.py and funtuple.yml to point to the right input file and making the tuple with the line(s) of your preference.