Iterative trimming issues and improvements

[giovanni-mocellin]

Brief summary of issue

The iterative trimming at mean+n*sigma was quite successful per se, only a couple fixes/improvements needed. Details in the QC8 report here: https://indico.cern.ch/event/881574/contributions/3714174/attachments/1984737/3306679/QC8_report_20200210.pdf

Types of issue

• Bug report (report an issue with the code)
• Feature request (request for change which adds functionality)

Expected Behavior

Iterative trimming fails if run on multiple chambers (2 is the maximum): tried with different options for CPU usage in scurves analyses, but still gets stuck after the first scurve taken for the bunch of chambers.
Moreover, it would be nice for the user to have all the options taken as default (vfatMask, number of iterations, sigmaOffset, etc.) and only let the CPU usage being a required option.

Current Behavior

Iterative trimming should work smoothly for more than one chamber at a time with scurves analysis parallelization.
The command could be more user friendly and less prone to human errors in case of non-expert use.

Steps to Reproduce (for bugs)

1. In qc8daq machine
2. Trim the detectors with iterative trimming
3. Use as an OH mask anything that has more than 2 chambers in it
4. It will get stuck after the first scurves data taking

Possible Solution (for bugs)

Context (for feature requests)

Your Environment

• Machine: qc8daq
• Version used:
• Shell used:

[AndrewLevin]

In what sense does it get stuck?

[giovanni-mocellin]

Simply it does not move... Hangs forever

[AndrewLevin]

But how many chambers are you trimming and how long did you wait?

[giovanni-mocellin]

They were 8 and we waited for 2.5 days

[giovanni-mocellin]

Over the weekend...

[AndrewLevin]

So, did you already kill the process? What does it show at the end of the log files?

[giovanni-mocellin]

It does not actually produce log files... That's why it is suspicious

Also, the log files produced for multiple chambers, even when it works, are not produced/moved to the chambers folders, but stay in the first chamber's one

[giovanni-mocellin]

The common log shows only that things started and nothing else...

[AndrewLevin]

Also, the log files produced for multiple chambers, even when it works, are not produced/moved to the chambers folders, but stay in the first chamber's one

what do you mean "when it works", I thought you are reporting that it does not work for multiple chambers?

[giovanni-mocellin]

"Iterative trimming fails if run on multiple chambers (2 is the maximum)"

You can still run it for 1 SC = 2 chambers

Not more

[AndrewLevin]

Ah, I missed that, but it is hard to imagine how there could be a bug that is important for 3 chambers but not for 2 chambers. I suspect that it is more related to killing the machine by using too much memory (which may in the end be a software issue). When you run these trimming runs, is the machine doing anything else? How many CPUs and how much memory does the machine?

[giovanni-mocellin]

We usually take in parallel multiple scurves (part of the daily procedure). And also the analysis works. That's why I thought it should have worked for trimming...

[giovanni-mocellin]

[AndrewLevin]

is this screenshot is taken while the trimming is stuck?

[giovanni-mocellin]

No, it is just to show the cores and ram... taken when posted