GAUDI Workshop 2016

Europe/Zurich
CERN

CERN

Description
Workshop to define the future of Gaudi.
    • 09:00 13:00
      Status and Hopes 31/3-004 - IT Amphitheatre

      31/3-004 - IT Amphitheatre

      CERN

      105
      Show room on map
    • 14:00 18:00
      Hackathon: Use Cases and Requirements 31/3-004 - IT Amphitheatre

      31/3-004 - IT Amphitheatre

      CERN

      105
      Show room on map
      • 14:00
        Summary of Morning Session 10m
        Speaker: Benedikt Hegner (CERN)
      • 15:10
        Event Store Discussion 1h 30m
        Speaker: Simon Patton (LBNL)

        - Efficiency/Performace
        - Update of objects
        - Handle & Links Symantics
        - DataObject as a base class
            - Is it more than a common base class?
            - It is reference counted.
            - Enables introspection.
            
        - Can we do DataHandle<int>? Yes.

        - Link is a persistable pointer (not a range)
            - What is a reference to container & a key
            - DataReference use a DataHandle?
                Could be a pointer, but need to be able to
                    recover DataHandle for output.

        - Persistency? - I/O section

        - Registration of object in Whiteboard is contention
            - it is possible, but scheduler contention larger.

        - Updated is not a good idea.
            - Can we live without it?

        - What is the impact on the Archive Event Store?

        - semantics of DataHandles
            - Immutable after insertion
            - Might as well move objects into store
                (writer takes T&&)

        - Charles and Gerhard will bring proposals tomorrow.

        - Check codes to make sure DataHandles are sufficient.

         

    • 09:00 13:00
      Hackathon: Control and Data Flow 6/2-024 - BE Auditorium Meyrin

      6/2-024 - BE Auditorium Meyrin

      CERN

      120
      Show room on map
      • 09:00
        Introduction 10m
        Speakers: Benedikt Hegner (CERN), Charles Leggett (Lawrence Berkeley National Lab. (US)), Marco Clemencic (CERN)
      • 09:10
        Unifying Data Handles 20m
        Speakers: Charles Leggett (Lawrence Berkeley National Lab. (US)), Marco Clemencic (CERN)
      • 09:30
        Re-Entrant (Transform) Algorithms 20m
        Speakers: Gerhard Raven (Natuurkundig Laboratorium-Vrije Universiteit (VU)-Unknown), Gerhard Raven (Nikhef National institute for subatomic physics (NL))
      • 09:50
        Defining Control and Data Flow in Python 20m
        Speaker: Benedikt Hegner (CERN)
      • 10:10
        The ATLAS Trigger Use Case 20m
        Speaker: Benjamin Michael Wynne (University of Edinburgh (GB))
      • 10:30
        Processing multiple events, lumis, runs 20m
        Speaker: Benedikt Hegner (CERN)
    • 14:00 18:00
      Hackathon: Conditions
      • 14:00
        Condition Handling in ATLAS 20m
        Speaker: Charles Leggett (Lawrence Berkeley National Lab. (US))
      • 14:20
        Common Conditions Infrastructure 20m
        Speaker: Hadrien Benjamin Grasland (Laboratoire de l'Accelerateur Lineaire (FR))

        - Common time representation possible?


        - Time interval union for DayaBay/LZ


        - Would like to have Gaudi tasks/schedulables ("ITask")

         - Would like to have a framework interface
           for scheduling grouped condition IO
                  + efficient derivation using concurrent algs
           ("ConditionTask" concept)

         - ConditionSvc's "prepare" hook is good for scheduling IO efficiently

         - Want to annotate tasks as IO-bound/blocking
           so that scheduler can put it on an additional OS thread

         - Do we really need control flow in condition generation?
           (condition gen must be done, it has no optional part like event processing)

         - ConditionSvc::prepare() can be a hook to any condition generation process,
           synchronous or asynchronous, isn't it?


        - What does the user see?

         - ConditionHandle + a way to register them to the framework

         - Need a hook to know what condition generation to schedule and when

         - Should have a way to call prepare() before an event is actually scheduled
           because prepare() can fail if condition storage is full

         - If the scheduler manages IoVs, what is the interface to it ?
           (what information flows where, when?)

         - If all the scheduler does is ask special algorithms whether they need to be
           executed, that's a fine scheduler/condition decoupling


        - Does the condition overhead really matter?

         - One reason to start w/ simple implementations?

         - LHCb trigger scheduling has a strange oscillating behaviour
           due to scheduling bottlenecks

          - Due to on-demand condition loads

          - Preload required, not enforced

         - The interface must be right, even if implementation can need fixing


        - Regarding preloading, need advance knowledge of data required for loading


        - Should we have an interface for data prefetching across multiple events?


        - We should focus on the interfaces that all experiments need in Gaudi

         - We should be able to swap implementations (DD4Hep vs IoV aware scheduler)

         - LHCb would want to outsource condition management outside Gaudi-land

         - Can be done if Gaudi scheduler can manage blocking tasks


        - Key parts of the interface: registering condition requirements + "prepare/release"

    • 20:00 21:00
      Workshop Dinner 1h