Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • M MooreAnalysis
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 14
    • Issues 14
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LHCbLHCb
  • MooreAnalysis
  • Issues
  • #2
Closed
Open
Issue created Feb 06, 2020 by Ross John Hunter@rjhunterDeveloper0 of 1 checklist item completed0/1 checklist item

Follow-up from "Add HltEfficiencyChecker tool to mooreanalysis" - behaviour of the routing bits writer/ Z -> mu mu old seg faults.

The following discussion from !1 (merged) should be addressed:

  • @rjhunter started a discussion: (+18 comments)

    @olupton and I made some progress on assessing where the Z \rightarrow \mu\mu issue is coming from.

    First of all, the control flow of this tool is like so:

    trigger_node = CompositeNode(
        'trigger_node',
        combineLogic=NodeLogic.NONLAZY_AND,
        children=[
            top_cf_node, et,
            #top_cf_node,
            mc_unpackers()["MCParticles"],
            mc_unpackers()["MCVertices"], mcdtt
        ],
        forceOrder=True)

    If et (an instance of an EventTuple algorithm) is included, all decay modes work except Z \rightarrow \mu\mu, which seg faults as TupleToolTrigger is trying to write the tree. If et is not included, all decays would fail at the 2nd, perhaps 5th event, complaining that they couldn't find the DecReports. This was strange since the code that allows them to find the DecReports was the first thing we did when we started writing this tool.

    The fact that it wasn't straight away the first event lead Olli to wonder if the GEC was involved, and indeed we saw that for 1 event the GEC was throwing away, the ExecutionReportsWriter wasn't called, and therefore there were no DecReports for that event. We verified this by asking the NoBiasLine to accept everything, and amazingly everything worked for all decays.

    We then also saw that everything works now, for all decays, if et is not in the control flow as well.

    But this begs the question, if MCDecayTreeTuple was properly declaring its dependencies to the ExecutionReportsWriter, then shouldn't ExecutionReportsWriter be called for every event? So we looked in the debug output of the HLTControlFlowMgr and saw that indeed, MCDecayTreeTuple is not declaring any dependencies, whereas EventTuple is declaring its dependency to ExecutionReportsWriter.

    So the question is now, why doesn't MCDecayTreeTuple declare its dependencies properly, but EventTuple does? They seem to both inherit from GaudiTupleAlg in the end. I don't know enough about how the scheduler works to be able to find out where it works out the dependencies. @rmatev @nnolte any ideas how I can look for this?

Assignee
Assign to
Time tracking