Calorimeter change between 3.0.10 and 3.2

[Daschm]

Dear Delphes authors,

I've recently updated my Delphes from 3.0.10 to 3.2.0 and I realised that I get different jet spectra in my output, for practically identical detector settings.

I traced the problem back to the calorimeter module: The Towers/Tracks it creates are the same between the two versions, but the EFlow-objects it creates differ (which then in turn lead to different jet clustering results).
After all, it seems to be caused by this change:
​https://github.com/delphes/delphes/commit/2dab7833bd408a7e2d422540ac74c472b30b38ba

Can you elaborate whether that is a bugfix (and only the Delphes 3.2 result is correct) or whether the new code in fact should not produce any different results after all? At least, when I reset the calorimeter.cc code to the one in 3.0.10, the results agree again.

Cheers
Daniel

[Michele Selvaggi]

Dear Daniel,

the change you are mentioning was dictated by a decision to have the particle-flow algorithm in Delphes more similar to the approach taken by the CMS particle-flow. This said, we had that tested at that time, by comparing jet and met before and after and I don't recall radical changes in the observables we chose to compare.

Beside the slightly different way the eflow towers are constructed, you have now the possibility of choosing whether towers are retained or not, by playing with the parameters:

set ECalEnergyMin 0.5
set HCalEnergyMin 1.0

set ECalEnergySignificanceMin 1.0
set HCalEnergySignificanceMin 1.0

which define a minimal energy criterion (E(H)CalEnergyMin) and minimum significance (E(H)CalEnergySignificanceMin).
I believe that these might play a role in the way your jet observables are shaped.

Can you try playing a bit them?

Thanks for looking into this.
Cheers,
Michele

[Daschm]

PT (Green: 3.0.10, Red: 3.2)

[Daschm]

Hi Michele,

I first had these values at the standard values in the ATLAS card (the ones you mentioned), and had my first glimpse at the discrepancies [i.e. analysis level cutflows change by 10-30% as soon as jets are involved]. I then set those parameters back to 0.0 (which I thought would correspond to the 3.0 approach), but the discrepancies remained. I then checked the code and realised that if I revert the code change, I get the old spectrum. I haven't investigated the actual dependence on the XCalMinValues after that.

I attached two distributions of the same property with the same input events, once with Delphes 3.0.10 and once with Delphes 3.2.0 (In the second, EFlowTowers = Merger(EFlowPhotons,EFlowNeutralHadrons).) You see differences in the low-jet pt region. (In both the "XCalMin" parameters are set to 0 and all calo smearing and JES are identical, so it is really just the algorithm's effect).

For now, I just wanted to know whether a different result is expected or not. I couldn't quite get the structure of the eflow algorithm (you guys should comment more ;-) ) and hence wasn't sure how to compare the two codes.

If I understand you correctly, the algorithm did change and is expected to produce different but not too different, results, right? That would be in agreement with what I see. But as I've said, I haven't investigated the dependences on the parameters yet; I assumed if I want the same result I should set them to identical values but that's probably not the case. I'll have a play with them then.

Thanks for the quick reply!
Daniel

[Daschm]

Dear Delphes team,

I am replying to this old ticket of mine as I have a request related to the very same issue:

In CheckMATE, we have always been using our own "hacked" version of Delphes 3.0.10. As you know, we would like to use the newest, public version without any hacks required (Currently that would be 3.3.2).

Unfortunately, all our 8 TeV analyses have been validated using the "old" calorimeter setup and as I mentioned in the earlier messages, the results do slightly change. We therefore cannot be 100% certain that all our countless 8 TeV validations are still correct if we change to the new calorimeter and it would be an enormous amount of effort to re-validate everything.

The most simple way out would be if you simply could provide the source files for your old 3.0.10 Calorimeter Module, i.e. the one before the above mentioned commit, in your public versions (something like /modules/oldCalorimeter.cc / .h). We could then easily use this old module for our 8 TeV analyses but otherwise use the most up-to-date Delphes version (and the updated calorimeter for our new 13 TeV validations).

Would that be possible?

Cheers,
Daniel (on behalf of the CheckMATE team)

[Michele Selvaggi]

Hi Daniel,

sure including the old calorimeter should not be a problem.
Just to make sure, you need the one from 3.0.10, i.e. this one, right?:

​https://github.com/delphes/delphes/blob/3.0.10/modules/Calorimeter.cc

Also, so that you know, we plan on releasing a major version soon (3.4.0), hopefully somewhere between end of july/august.

[Daschm]

Hi Michele,

Yes, that seems to be the correct version.

With this, we should be able to keep Delphes as a completely separate program which we simply connect CheckMATE to via "./configure --with-delphes=xxx". Then, we hopefully never have to worry about any major version updates from your side :-)

See you probably in Beijing!
Cheers,
Daniel