1. CLAs Reconstruction and Analysis Physics Data Processing with SOA based Framework Vardan Gyurjyan on behalf of Clas12 software group

2. Outline  Problem statement  SOA based framework as a solution  Current status of the ClaRA project  Future plans  Conclusion October 5, 2015V. Gyurjyan

3. Computing power CMOS Technology Single Chip Integration Node/Rack Integration Network Integration October 5, 2015V. Gyurjyan

4. Integration Chip 4 Cores Computer Card 1Chip 13.6GF/s Mode Card 32 Computer Cards 435 GF/s Rack 32 Mode Cards 13.9 TF/s IBM Blue Gene 72 Racks 1PF/s October 5, 2015V. Gyurjyan

5. Network Evolution User Traffic 2x / 12months Router Capacity 2.2x / 18months Moore’s Law 2x / 18 months Network Capacity 2x / 7 months CAT4 10Mbps 10base-T CAT5 100Mbps 100base-T CAT5e 1Gbps 1000base-T 2003 – CAT6 10Gbps 2007 – CAT7 100Gbps October 5, 2015V. Gyurjyan

6. High Performance Computing Trends 1. Exponential growth in processor performance (coming to an end) 2. Power cost = System cost: invention required 3. Growth in level of parallelism (near term solution) October 5, 2015V. Gyurjyan

7. IBM Approach – Path to Petascale  Multiple modest cores on a single chip rather than one high- performance processor  Watts/FLOP will not improve much from future technologies.  Linux environment and MPI (standard messaging interface) October 5, 2015V. Gyurjyan

8. "The Network is the Computer." John Gage October 5, 2015V. Gyurjyan

9. Specifics of the Offline Software  Lifetime of the software >= lifetime of the experiment.  Collaborative nature of the development.  Coexistence of parallel running applications for the single experiment.  Unprecedented scale and complexity of the physics computing environment  Physics computing environment must keep up with fast growing computing technologies  Large worldwide user base. October 5, 2015V. Gyurjyan

10. PDP (Physics Data Processing) Application Conventional vs. parallel/distributed October 5, 2015V. Gyurjyan

11. Running Conventional Software Application Copy checkout Give up Configure Compile Fix errors Run Modified? Complain yes no yesno ok October 5, 2015V. Gyurjyan

12. Programming Errors  Compile time  Program does not compile.  Compiler reports a “best guess” of the problem  Undeclared variables or functions  Missing semicolon or brace  Typos  Missing files or libraries  Type ambiguities  Run time  Executable crashes or has unexpected behavior  May not appear for all conditions or all data sets  Uninitialized variables  Memory errors  Numeric errors  Type errors in print statements  Closing a NULL file pointer  Accessing a NULL pointer  Variables out of scope October 5, 2015V. Gyurjyan

13. Challenges of the Conventional Approach  Difficult to organize and coordinate activities  Difficult to maintain  Inevitable fragmentation of the software  Poor scalability  Computing skills are required to use physics data processing applications October 5, 2015V. Gyurjyan

14. ABC B A A B C CLAS 6 CLAS 12 A+B << C C: requires a few or no programming skills October 5, 2015V. Gyurjyan

15. One way to eat an elephant A bite at a time October 5, 2015V. Gyurjyan

16. Where we start?  Each bite is a clear, simple, single purpose application, developed by group B member.  Group A, with a tight collaboration with group B and C shall control and manage the process, never loosing maniacal focus on a big picture (elephant). Define a piece of a big problem Understand the problem Distill the problem to its essence solutionTest October 5, 2015V. Gyurjyan

17. “Things should be made as simple as possible, but not simpler.” Albert Einstein October 5, 2015V. Gyurjyan

18. Language and Architecture Evolution Structured and Procedural programming Object Oriented programming Assembly Language Service Oriented programming October 5, 2015V. Gyurjyan

19. SOA  SOA promotes the goal of separating service users from the service implementation.  Style of building reliable systems that deliver functionality as services  Loose coupling between interacting services  Directories and addressing mechanisms are at the center of SOA. Program Arbitrary format Service Standard format Complex Specialized, simple October 5, 2015V. Gyurjyan

20. Attributes of Services  Well defined, easy-to-use, somewhat standardized interface  Self-contained with no visible dependencies to other services  (almost) Always available but idle until requests come  Location transparency  Easily accessible and usable readily, no “integration” required  New services can be offered by combining existing services  Quantifiable quality of service October 5, 2015V. Gyurjyan

21. Service Interface  Standard message based  Highly Polymorphic  Intent is enough  Implementation can be changed in ways that do not break all the service consumers October 5, 2015V. Gyurjyan

22. Service Orientation is scalable  End users can consume and combine a lot of services since they don’t have to know or “learn” how the services are made.  Service providers (A+B) can offer their services to a lot more consumers by optimizing  The user interface  Access  Implementations October 5, 2015V. Gyurjyan

23. “On Demand” Physics Data Processing  Use software as you need  Much lower setup time, forget about  Installation  Implementation  Training  Maintenance  Scalable and effective usage of resources  Parallelism (CPU, Storage, Bandwidth…) October 5, 2015V. Gyurjyan

24. What is ClaRA?  Framework that Implements SOA.  Service development environment.  Toolbox of generic physics data processing services.  Network distributed platform.  The “Glue”, binding together services into an algorithmic data analysis application. October 5, 2015V. Gyurjyan

25. Design criteria  Framework service shall be simple to use and easy to learn.  Framework service should be customizable to be able to adapt to the different data processing tasks.  Framework shall provide context sensitive help and assistance, with many real world physics data processing application examples.  Framework shall provide ready to use services, encapsulating essential functionalities of the physics data processing system.  Services shall be reusable and easily replaceable.  Physics data processing application design and implementation shall require a few or no programming skills.  Neither specific computing environment, nor compiling shall be necessary to build and run physics data processing application.  Framework shall provide graphical environment for physics data processing application development.  Frameworks platform shall be network distributed, and shall have temporal continuity.  The new system shall provide World Wide Web access to the services for remote configuration and execution of the data processing applications. The necessary security considerations must be addressed. October 5, 2015V. Gyurjyan

26. Data and Algorithm  Framework advocates clear separation between:  a) data and algorithm  b) transient and persistent data  Methods in the data object will be limited to manipulations of the internal data members only.  Algorithm will process one type of data and generate data objects of a different type. Algorithm Data October 5, 2015V. Gyurjyan

27. Persistent and Transient Data  Physics algorithm objects should not use data objects directly in the persistent storage.  Transient data storage as a means of communication between physics algorithms.  Two different optimization criteria for applications using persistent and transient data.  Being independent from the persistent storage technology. October 5, 2015V. Gyurjyan

28. Data Object categories Data EventDetectorStatistical October 5, 2015V. Gyurjyan

29. ClaRA Platform Front-End Container Normative Service Service Container node-1 Service Container node-2 Service Container node-3 Service Container node-N cMsg SCC WWW Web Service 1 Web Service 2 Web Service 3 Web Service N SOAP Users CMSG SOAP October 5, 2015V. Gyurjyan

30. Current Status Geometry Service Geometry Service Magnetic Field Map Service Magnetic Field Map Service GEMC Service GEMC Service Tracking Service Tracking Service bCNU Service bCNU Service Event Data Service Event Data Service ClaRA cMsg Platform Thin Clients WWW ClaRA WebServices Platform Math Service Stat Service Probability Service Geometry Service Matrices Service October 5, 2015V. Gyurjyan

31. Examples  EVIO event producer and EVIO event consumer services (C++).  data producer and data consumer services. C examples use cMsg payload (ASCII).  C++ geometry service client example  Java geometry service client example  Web services JSP clients October 5, 2015V. Gyurjyan

32. Tracking composite application Transient data Space- point maker Coarse track finder Cluster Analyzer Ambiguity solver Track fitter Histogram builder Histogram builder Persistent data ClaRA cMsg Platform Thin Clients October 5, 2015V. Gyurjyan

33. Tracking application service decomposition DetectorData EvtData StatData TransientEvtData TransientDetData TransientStatData Track candidates Resolved Tracks Space Points Raw Data Final Tracks SpacePointFormation CoarseTrackFinder SeadMaker VertexFinder ClusterAnalyzer AmbiguitySolver TrackFitter TrackScoring Supervisor start retrieve record retrieve record retrieve record retrieve Transient Storage Tracking State machine October 5, 2015V. Gyurjyan

34. Performance measurements October 5, 2015V. Gyurjyan