Uploaded image for project: 'ATLAS Flavour Tagging'
  1. ATLAS Flavour Tagging
  2. AFT-555

FTAG validation code crashes on Sherpa Z high pt samples

    XMLWordPrintable

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

      Dear FTAG team,
      since 22.0.32 we observe that running the validation code on one of our sample A validation samples gives crashes:

      valid1:valid1.361405.Sherpa_CT10_Zmumu_Pt280_500_CVetoBVeto.recon.AOD.e5112_s3227_r12531

      is the dataset. And you can see the crashes here:

      https://bigpanda.cern.ch/task/24914701/

      we've tested locally and the crash can be avoided by removing doBtag from the validation flags, and occurs if you run with only doBtag in the validation flags.

      The following script can reproduce the error:

      #retrieve inputs
      
      rucio download valid1:AOD.24914686._000198.pool.root.1
      ln -fs valid1/AOD.24914686._000198.pool.root.1 ./AOD.24914686._000198.pool.root.1
      
      #transform commands
      
      source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh -c x86_64-centos7-gcc8-opt
      asetup --platform=x86_64-centos7-gcc8-opt Athena,22.0.32
      export ATHENA_PROC_NUMBER=8
      export ATHENA_CORE_NUMBER=8
      Reco_tf.py --inputAODFile="AOD.24914686._000198.pool.root.1" --maxEvents="6000" --preExec "all:from InDetPhysValMonitoring.InDetPhysValJobProperties import InDetPhysValFlags; InDetPhysValFlags.doValidateTightPrimaryTracks.set_Value_and_Lock(True);" --skipEvents="0" --valid="True" --runNumber="361405" --digiSeedOffset1="1" --digiSeedOffset2="1" --AMITag="p4479" --jobNumber="1" --validationFlags doBtag --outputNTUP_PHYSVALFile="NTUP_PHYSVAL.24914701._000107.pool.root.1"
      
      

      Although this sample is not needed for ftag validation it is used for muon validation and it would be best of we could use the same tag for all samples.

      My guess is that some truth navigation that you are using for the new plotting tmakes some assumptions that don't work for Sherpa samples. An inelegant but quick fix could be to check for this DSID and then not make plots that track truth origin, but hopefully there's something nicer as ftag code in general must have to does have to deal with Sherpa truth records for other applications.

      (Mentioning atsiamis here so he knows this is our issue running the high pt Z->mumu and that we are trying to get it fixed)

      Tagging juhofer and fbeisieg as validation contacts.

      Attachments

        Activity

          People

            juhofer Judith Hofer
            jferrand James Ferrando
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated: