AFP DQM [rel 22] - change in sync histograms logic

The only difference between this and the previous version is in if statement in sync histograms, which makes significant difference in output.

@caforio

This merge request affects 1 package:

• ForwardDetectors/AFP/Run3AFPMonitoring

Adding @ggach as watcher

added ForwardDetectors master review-pending-level-1 labels

CI Result SUCCESS (hash bba59824)

	Athena	AthSimulation	AthGeneration	AnalysisBase
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 21023]

added review-approved label and removed review-pending-level-1 label

merged

mentioned in commit 345fe844

Hi Nikola - are variables like "previouslb" static in this code (i.e. they remain over multiple calls to the functions)? If so, this could cause some serious trouble.

added sweep:ignore label

Hi Peter,
First of all, thanks for comment!

These variables are global and used for sync histograms to save values from multiple events in particular lumiblock. So, yes, they are created once and their purpose is to save some values for certain amount of time.

For example:
We are in lb 100, then we initialize previouslb=100; fetch new values, and do some calculations (and save them in variables like previouslb).
We are in lb 101, previouslb is 100, then we proceed with filling of lb 100 (since the all values for lb 100 are fetched / processed), and set previouls to 101.

If this approach is not acceptable, could you suggest some other?
Basically, we need ability to store and calculate values over events and some "trigger" (for example lb number change) for fill.

Hi Nikola,

Can you give a specific example?

Best, Peter

Hi Peter,

The specific example is following:
Let's suppose we are in LB 100. Then we count number of events in this LB (fillHistograms is called once for every event), and also number of clusters.
When we processed all LB 100 events, we calculate by formula: value for histogram = number of clusters / (mu * number of events).
So, you see that I collect data through events and in the end of LB (this is what I mean by trigger because lb number changed (if previouslb is different from current -> fill histogram)) I do calculation which I pass as argument of histogram.

Now, we are in LB 101, and we repeat the process...

---

So, the basic idea for me was to collect the data through all events (not only from LB to LB) and to fill histogram only once in the end of program. But, since there is no finalize method (or some way to get information to my code when is the end of processing events) which will allow me this kind of work - I moved to approach from above.

---

Currently I am reading https://github.com/ponyisi/histogram_postprocessing/blob/master/README.md to see am I able (and how) to implement this approach with my code.
Do you think this is applicable to my problem?

Cheers,
Nikola

Hi Peter,

Maybe you missed my reply, this is a kind reminder.

Cheers, Nikola