Trimmed jets storage to root

[amonte]

Dear Delphes Team,
I am trying to use the trimming functionality in Delphes 3.3.2; my problem is, I can't seem to get the trimmed jets info into the root file (or read it from the root file).

I am reclustering a "fat jet" and then trimming it. I added a "fat jet" module in the default ATLAS card,

module FastJetFinder FastFATJetFinder10 {
  set InputArray Calorimeter/towers

  set OutputArray fatjets10

  set JetAlgorithm 6
  set ParameterR 1.0
  set JetPTMin 20.0

  set ComputeTrimming 1
  set RTrim 0.2
  set PtFracTrim 0.05
}

which I then write to root via the TreeWriter module,

add Branch FastFATJetFinder10/fatjets10 FatJet10 Jet

This gives me a FatJet10 varaible that I can access in root, although it does not seem like it is trimmed (changing PtFracTrim leaves FatJet10 unchanged). From looking at the source of FastJetFinder.cc, it looks like the resulting trimmed jet 4-vectors should be stored in TrimmedP4[0], but instead this contains mostly zeros (e.g. via drawing Draw("FatJet10.FatJet10.TrimmedP4[0].Pt()"), or accessing them directly in my root macro, via FatJet10_TrimmedP4[0][i].Pt() ). Same results apply if I try to access other variables, e.g. M() instead of Pt().

If I add some output lines in FastJetFinder.cc, it looks like trimming works as intended (e.g. changing PtFracTrim behaves as expected)

# line 434
cout <<  trimmed_jet.m() << " "<< trimmed_jet.pt() <<endl;

Does Delphes write the trimmed jet info as I described it? Am I misunderstanding how to access the trimmed jet in root? How would I do that?

Thanks,

[amonte]

Just a quick update about accessing the trimmed jets: adding the following code in my root macro just outputs zeroes (suspectedly, the same number of zeroes as the total number of FatJet10 jets in the event):

for (int i = 0; i < FatJet10_size; i++){
    cout <<  FatJet10_TrimmedP4[0][i].Pt();
}

Note that other components of FatJet10, such as FatJet10.Pt(), give reasonable numbers.

I was able to work around this issue by dropping the info about the four hardest subjets by changing the definition of TrimmedP4 from a vector of TLorentzVector's to just a TLorentzVector everywhere in Delphes source code, (DelphesClasses.cc, DelphesClasses.hh, FastJetFinder.cc, Treewriter.cc), and then in FastJetFinder.cc I commented out the lines in the trimming module where the four hardest subjets were assigned to TrimmedP4[1-4].
After running this hacked version of Delphes, the trimmed jet is stored in the TLorentzVector TrimmedP4 and it behaves as expected, e.g. lowering/raising PtFracTrim gives harder/softer trimmed jets.

I am still not sure why FatJet10_TrimmedP4[0][i] does not work the the out-of-the-box Delphes version.

[Michele Selvaggi]

Hi,

have you tried what is suggested here?:

https://cp3.irmp.ucl.ac.be/projects/delphes/ticket/997

Michele

[amonte]

Hi Michele,
thank you for the reply and sorry for the delay in answering. As the writer in the other post, I was also using the MakeSelector method, but switching to the method shown in your examples works.

Unfortunately we also recently switched to PyRoot, and I am again having problems accessing TrimmedP4: my problem shows up by modifying Example1.py (line 45)

    # Print jet transverse momentum
    print jet.PT
    print jet.TrimmedP4[0].Pt()

which prints the first line but crashes when evaluating the second, with

 *** Break *** segmentation violation

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#6  0x0000000000000000 in ?? ()
#7  0x00007f2a1b164c8e in TInstrumentedIsAProxy<TLorentzVector>::operator()(void const*) () from /cms/base/cmssoft/slc6_amd64_gcc481/cms/cmssw/CMSSW_7_1_0_pre9/external/slc6_amd64_gcc481/lib/libPhysics.so
#8  0x00007f2a1f640d39 in TClass::GetActualClass(void const*) const () from /cms/base/cmssoft/slc6_amd64_gcc481/cms/cmssw/CMSSW_7_1_0_pre9/external/slc6_amd64_gcc481/lib/libCore.so
#9  0x00007f2a2114485b in PyROOT::BindRootObject(void*, TClass*, bool) () from /cms/base/cmssoft/slc6_amd64_gcc481/lcg/root/5.34.18-cms/lib/libPyROOT.so
#10 0x00007f2a21136f1f in PyROOT::(anonymous namespace)::pp_get(PyROOT::PropertyProxy*, PyROOT::ObjectProxy*, _object*) () from /cms/base/cmssoft/slc6_amd64_gcc481/lcg/root/5.34.18-cms/lib/libPyROOT.so
#11 0x000000000044d362 in _PyObject_GenericGetAttrWithDict (obj=0x7f2a1d23b500, name=0x7f2a21647e10, dict=0x0) at Objects/object.c:1432
#12 0x0000000000499540 in PyEval_EvalFrameEx (f=0xee66d0, throwflag=<optimized out>) at Python/ceval.c:2255
#13 0x000000000049d54b in PyEval_EvalCodeEx (co=0x7f2a21691030, globals=<optimized out>, locals=<optimized out>, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#14 0x000000000049d5c2 in PyEval_EvalCode (co=0x7fff5c755e88, globals=0x7fff5c755e88, locals=0x7fff5c755e88) at Python/ceval.c:666
#15 0x00000000004bf4d1 in run_mod (arena=<optimized out>, flags=<optimized out>, locals=<optimized out>, globals=<optimized out>, filename=<optimized out>, mod=<optimized out>) at Python/pythonrun.c:1346
#16 PyRun_FileExFlags (fp=0xede570, filename=0x7fff5c757d4f "Example1.py", start=<optimized out>, globals=0xe5fe20, locals=0xe5fe20, closeit=1, flags=0x7fff5c756320) at Python/pythonrun.c:1332
#17 0x00000000004bf788 in PyRun_SimpleFileExFlags (fp=<optimized out>, filename=0x7fff5c757d4f "Example1.py", closeit=1, flags=0x7fff5c756320) at Python/pythonrun.c:936
#18 0x000000000041498c in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:599
#19 0x0000003d8281ed1d in __libc_start_main () from /lib64/libc.so.6
#20 0x0000000000413bd9 in _start ()

Note that this does not happen using C. For example, I can modify Example1.C (on line 53) with the suggestion in the link above and I get no crash and the right numbers

      cout << "Jet pt: "<<jet->PT << endl;
      cout << "Trimmed jet pt: "<<jet->TrimmedP4[0].Pt() << endl;

The crash happens as soon as I try to access TrimmedP4, e.g. inspecting it with the line dir(jet.TrimmedP4) is enough. In the list of attributes of jet, dir(jet), TrimmedP4 is there, together with all the other variables (Eta, PT,...) so it seems that it knows what it is, just not what to do with it.

Could this be a problem of PyRoot itself? I would think libDelphes.so should be providing all of the information to handle the new variables.