Bug in sim09k MC

[manuelfs]

It was discussed in the simulation, davinci, and semileptonic e-groups that some raw banks seem to be missing which leads some tools like TupleToolPid, which we use, to crash.

Our tracker-only MC is in sim09k, and Yipeng has run on it. This is one example log file Script1_Ganga_GaudiExec.log

I do see errors that the neutral clusters may be missing, for instance

CaloClusterMCTruthWARNING CaloClusterMCTruth::  The relations table 'Relations/Rec/Calo/Clusters' is empty! StatusCode=FAILURE

@yipengsun can you

• Link to the code and LFN that this log file ran over?
• Check that the ntuples produced are fine (eg, fit variables, isolation BDT, any variable we may need for PID or trigger emulation)?

@ZishuoYang Can you also post a log file and your observation on whether sim09k works for you?

[yipengsun]

For the calorimeter warning, I think it is fine for tracker only, given that we don't really have a calorimeter right?

The LFN is:

/MC/2016/Beam6500GeV-2016-MagUp-TrackerOnly-Nu1.6-25ns-Pythia8/Sim09k/Reco16/Filtered/11574021/D0TAUNU.SAFESTRIPTRIG.DST

[yipengsun]

Also, the LFN is the input to the unsplitted job, whereas the log file is from one of the splitted subjobs. I'll try check the LFN of that log file, or give you a log file-LFN combo.

[yipengsun]

OK, the log is from subjob 0 (a very sane choice), and its actual input data is:

   inputdata =    LHCbCompressedDataset (
     files = [ LHCbCompressedFileSet (
   lfn_prefix = '/lhcb/MC/2016/D0TAUNU.SAFESTRIPTRIG.DST/00140783/0000',
   suffixes = [/00140783_00000001_1.d0taunu.safestriptrig.dst, /00140783_00000036_1.d0taunu.safestriptrig.dst, /00140783_00000074_1.d0taunu.safestriptrig.dst, /00140783_00000081_1.d0taunu.safestriptrig.dst]  

[manuelfs]

Thank you for the LFNs Yipeng. Have you had a chance to check if the nuples are ok?

Also, it seems there may not be a bug after all. One just needs to configure the jobs appropriately (from the simulation thread above)

Dear Nicole,

Thanks very much for confirming! I immediately went to test some 2017 filtered events and indeed, it goes through! That is weird and I hope all or most of the people who did recent 2016 (and before) filtered MC requests made sure they have those lines in their script.

Cheers; Ad.

---

From: Nicole Skidmore Sent: 22 November 2021 10:08 To: Adlene Hicheur; Alessandro Bertolin Cc: Laurent Dufour; Michal Kreps; lhcb-simulation (Simulation for LHCb) Subject: RE: event dump info and crash

Dear Adlene

Yes Im afraid this is as Alessandro described and is something that has caught many people (including myself) out in the past

For 2011, 2012, 2015 and 2016 the CALO reconstruction is rerun with another calibration. This must also be done in MC and so this options file is included in your stripping filtering step

$APPCONFIGOPTS/DaVinci/DV-RedoCaloPID-Stripping_28_24.py

Unfortunetly a by-product of this is that your filtering script needs to contain the lines

# Items that might get lost when running the CALO+PROTO ReProcessing in DV
caloProtoReprocessLocs = ["/Event/pRec/ProtoP#99", "/Event/pRec/Calo#99"]
# Make sure they are present on full DST streams
SelDSTWriterConf['default'].extraItems += caloProtoReprocessLocs

Im afraid without them the MC files are unusable.

Please let me know if I can help any further

Regards Nicole

[Svende]

This is a known problem since quite a while (It was added by me to the SL MC twice https://twiki.cern.ch/twiki/bin/view/LHCbPhysics/SemileptonicMCRequests#Sim09_samples_needed_to_anal_AN3 when I was MC liaison, no idea why it was removed and by whom, very bad idea as it was very relevant info!). It's also written here: https://twiki.cern.ch/twiki/bin/view/LHCbPhysics/FilteredSimulationProduction. We have these magic lines added in our filtering script: https://gitlab.cern.ch/lhcb-datapkg/WG/SemilepConfig/-/blob/master/options/Filter_D0TauNu_Muonic.py#L88 so we should be safe.

[ZishuoYang]

I also have these magic lines added in the filtering script, following the instructions on FilteredSimulationProduction twiki page.

I've run a test job on some recently requested sim09k FullSim MC (Bs->Jpsi X). The log Script1_Ganga_GaudiExec.log looks fine and the tuple also looks fine.

I do see occasional CaloClusterMCTruth warnings: CaloClusterMCTruth:: The WARNING message is suppressed : ' No MC information for the cluster is found'. According to Vanya Belyaev on the davinci mailing list, it's normal:

On 02/06/2017 11:34 AM, Vanya Belyaev wrote: Hi Nis,

the first one is ok, if appears relatively rare: a tiny fraction of CaloCluster indeed has no MC-truth (e.g. due to noise and/or backsplash from hcal, or some other other weird complicated interactions). If the message is rare ( <<1 per event) , it if fine, however if you get it very frequently (>40 per event) it could indicate some major misconfiguration.

Cheers, Vanya

On 02/06/17 11:18, Nis Meinert wrote:

Dear experts,

I am running some selections on MC generated data. The resulting tuple looks fine, but there are warnings in the log. These warnings are:

CaloClusterMCTruthWARNING CaloClusterMCTruth:: No MC information for the cluster is found StatusCode=FAILURE

and

D0.TupleToolMCT...WARNING BackgroundCategory:: Common mother is stable. StatusCode=FAILURE

Are these warnings related and do I have to worry?

Thanks for your help,

Cheers, Nis

[yipengsun]

I also checked a GRID-produced tracker-only ntuple, and the calorimeter-related branches that are used for trigger emulation look fine.

[manuelfs]

Thank you Svende, Zishuo, and Yipeng. It looks like we can close this issue