1 / 13

Object Networks—ATLAS' Future Control Framework For Offline?

Explore the ATLAS Control Framework - a key infrastructure ensuring precise software execution. Discover the framework's design decisions, modular core domains, and versatile implementation details for enhanced control and operational efficiency.

dagnew
Download Presentation

Object Networks—ATLAS' Future Control Framework For Offline?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object Networks—ATLAS'Future Control FrameworkFor Offline? Lassi A. Tuura CERN/EP Division Software Architecture WG Lassi A. Tuura, CERN/EP Division

  2. Presentation Overview • What Is It? • Strategic Design Decisions • Other Design Goals • Example Network • Implementation Details Lassi A. Tuura, CERN/EP Division

  3. What Is It? The control framework is the part of the infrastructure that makes sure that • the right piece of software • runs • at the right time • with the right inputs and • the outputs go to the right place Lassi A. Tuura, CERN/EP Division

  4. Strategic Design Decisions #1 • Fully object-oriented design, mainly in C++ • Modular core infrastructural domains • Mutually independent (orthogonal) in design • As toolkits—collections of co-operating classes for app or app framework construction • Will not try to take over and dominate application design, data or execution • Code movability among analysis, offline reconstruction and event filter Lassi A. Tuura, CERN/EP Division

  5. Strategic Design Decisions #2 • Separation of computational and data objects • Use a component model • Package computational units (algorithms) as replaceable components • Components have well-defined interfaces • Communication across component boundaries only in ways provided by the control framework • Recognise data-flow nature of the problem Lassi A. Tuura, CERN/EP Division

  6. Strategic Design Decisions #3 • Event is not a scratch pad storage • Global knowledge ("everybody knows that…") gets quickly out of hand—no different from global variables or COMMON blocks • Components name true data dependencies • Framework reasons about the dependencies • When accompanied by wise component design, significantly improves reusability Lassi A. Tuura, CERN/EP Division

  7. Strategic Design Decisions #4 • Treat all data types the same • Attach no meaning to any type • Event is not special to the framework • Note: Code reuse is not limited to component reuse—code can be shared across components in non-component form Lassi A. Tuura, CERN/EP Division

  8. Other Design Goals • Instant gratification • Framework separate from the components • Dynamically load and unload components • Visual feedback in interactive environment • Spy on data as it "flies by"—components will not notice anything, spies are components too • Allow application to be described as a script that is read, verified, components loaded, initialisation carried out, and network executed Lassi A. Tuura, CERN/EP Division

  9. ExampleNetwork • Colors = data types • Modules = behaviour • Whole network = component • Input-Output dependency Lassi A. Tuura, CERN/EP Division

  10. Implementation Details #1 • Framework holds onto data objects via facets • Kind of a handle that can reduce to a pointer • A type can have any number of facets: transient, reference counting, database, … • Data does not flow anywhere • Outputs hold objects • Inputs observe the outputs they are connected to, methods observe their inputs • Notifications are sent when data changes Lassi A. Tuura, CERN/EP Division

  11. Implementation Details #2 • Notifications do not result in immediate execution, only an action is scheduled for execution • Action queue ordered by data dependencies • Actions pulled from the queue and executed • More actions may be queued as a result of executing the most recently chosen action • Spontaneously generated actions can be queued by GUIs, network components • Queues can be stacked loops, recursion Lassi A. Tuura, CERN/EP Division

  12. Implementation Details #3 • Methods are notified if their inputs have changed • Only if the inputs have changed • If any of the inputs have changed • Required inputs must have values when the call is delivered • Networks can be packaged as components • Reuse as-is in a larger application • Reconfigure: alter parameters but do not change the network • Tear apart and reconfigure: reuse constituents Lassi A. Tuura, CERN/EP Division

  13. Implementation Details #4 • Networks can execute in any context • A normal method can be internally a network • A network can run inside another network • Runs till no more actions to execute and then returns to the caller Lassi A. Tuura, CERN/EP Division

More Related