-
Notifications
You must be signed in to change notification settings - Fork 20
Iterative trimming issues and improvements #297
Comments
In what sense does it get stuck? |
Simply it does not move... Hangs forever |
But how many chambers are you trimming and how long did you wait? |
They were 8 and we waited for 2.5 days |
Over the weekend... |
So, did you already kill the process? What does it show at the end of the log files? |
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 |
The common log shows only that things started and nothing else... |
what do you mean "when it works", I thought you are reporting that it does not work for multiple chambers? |
"Iterative trimming fails if run on multiple chambers (2 is the maximum)" You can still run it for 1 SC = 2 chambers Not more |
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? |
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... |
is this screenshot is taken while the trimming is stuck? |
No, it is just to show the cores and ram... taken when posted |
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
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)
Possible Solution (for bugs)
Context (for feature requests)
Your Environment
The text was updated successfully, but these errors were encountered: