BSM particles in calorimeter

[Daschm]

Hi,

I have a model with an LSP like particle which is however not the neutralino. Checking the syntax of the detector cards it seemed to me as if I would have to explicitly set both the efrac and the hfrac energy depositions to 0 for the particle ID number of my invisible particle to get the etmiss right. What I realised is that the EtMiss was even right when I used the standard card, which was convenient but also peculiar because if I wanted to actually have a BSM particle which deposits energy, it seemed as if Delphes would just ignore it.

I then digged deeper into the code and found that e.g. in the StdHEPReader modules, you filter out unstable particles from the event record. This makes sense, as often you have intermediate states in the sample.

However, I also saw that you use not only the MC status code but also test via the ROOT pdgtable objects whether a given PID is stable. It turns out that this is very peculiar, because in for example my case, the LSP particle was a second Higgs protected by a Z2 symmetry from decaying. The ROOT pdgtable however assumes all BSM higgses to have decays and therefore tells Delphes that they are not stable, hence removing them from the record! Alternatively, entirely new particles which are unknown to the pdgtable are also by standard ignored by Delphes.

If I got this correctly, this can lead to dangerous behaviour. My second Higgs, for example, is automatically considered as etmiss but a dark zprime, for example would not, as Root declares it as stable. In one case I have to define the particle to be invisible myself in the detector card, in the other one I don't.I don't think this is intended behaviour. Also I guess it forbids the analysis of e.g. charged BSM particles or completely new objects which have unknown pid but are expected to deposit energy into the detector.

Cheers,
Daniel

[Michele Selvaggi]

Hi Daniel,

you are perfectly right, we already encountered this problem a couple of weeks ago.
We are working on a stable solution which will require the user to provide additional particles (PID,Charge,Stability) in the input card.

For now, I am sure you figured that out already, a quick fix is to:

• remove the "pdgParticle->Stable()" condition from the reader.
• if you have charged stable particles that are not present in the ROOT table, write their charge by hand (depending on the pdgCode eventually)

We'll update this ticket when this matter is permanently fixed.

Thanks
Michele

[Daschm]

Thanks for the quick response. Good to hear that you agree.

Yeah, I would have done that fix too but I wanted to make sure first that there is nothing important hiding in the pdgParticle->Stable() condition that I missed and which would screw up whatever follows if I just remove it.

Cheers,
Daniel