1. Clas Reconstruction and Analyses framework
ClaRA
Clas Reconstruction and Analyses framework

2. Physics Data processing
Long life time
Volatile contributor/developer base
Large user base
10 April 2019
V. Gyurjyan

3. Application Development
Software architects define software specification to meet the requirements of applications.
Programmers take a given specification and write a program to implement the specification.
10 April 2019
V. Gyurjyan

4. SOA advantage
The SOA paradigm will explicitly separate software engineering task from programming task.
10 April 2019
V. Gyurjyan

5. Methodology
OO: Application development by identifying tightly coupled classes. Application architecture is hierarchical based on the inheritance relationships.
SO: Application development by identifying loosely coupled services and composing them into executable applications.
10 April 2019
V. Gyurjyan

6. Development
OO: Application development is often delegated to a single team responsible for the entire life cycle of the application. Developers must have knowledge of application domain and programming.
SO: Development is delegated to two independent parties: application builder (user physicist, group C) and service provider (group B). Application builders need to understand application logic and may not know how individual services are implemented. Service providers can program but do not have to understand the applications that use their services.
10 April 2019
V. Gyurjyan

7. Code sharing and reuse
OO: Code reuse through inheritance of class members and through library functions. Library functions have to be imported at compilation time and are platform dependent.
SO: Code reuse at the service level. Services have standard interfaces and are published on some repository. They are platform-independent and can be searched and remotely accessed. Service brokerage enables systematic sharing of services.
10 April 2019
V. Gyurjyan

8. Building, Binding and Compiling
OO: Associating a name to a method at runtime. The method must have been linked to the executable code before the application is deployed.
SO: Binding a service request to a service at runtime. The services can be discovered after the application has been deployed. This feature allows an application to be recomposed at runtime.
10 April 2019
V. Gyurjyan

9. Maintenance
OO: Users (group C) need to upgrade their software regularly. The application has to be stopped to perform the upgrading.
SO: Services can be updated without users‘ involvement.
10 April 2019
V. Gyurjyan

10. ClaRA Design goal CLAS12 software framework and middleware
CLAS12 physics data processing services
10 April 2019
V. Gyurjyan

11. Framework design choices
Separation between: a) data and algorithm b) transient and persistent data
10 April 2019
V. Gyurjyan

12. Algorithm services
Algorithm services will process one type of data and generate data objects of a different type.
Algorithm
Service
Data
Data
Data
10 April 2019
V. Gyurjyan

13. Persistent and Transient Data
Algorithm service should not use directly data objects in the persistent storage.
Transient data storage as a means of communication between physics algorithm services.
Data service translates data from persistent storage into transient storage.
10 April 2019
V. Gyurjyan

14. Why not one data object?
Two different optimization criteria for applications using persistent and transient data.
Being independent from the persistent storage technology.
10 April 2019
V. Gyurjyan

15. Data service Persistent Data Transient Data Data Data Service Adapter
10 April 2019
V. Gyurjyan

16. Data Object categories
Event data
Detector data
Statistical data
10 April 2019
V. Gyurjyan

17. Hypothetical tracking
Supervisor
start
retrieve
SpacePointFormation
EvtData
TransientEvtData
record
start
CoarseTrackFinder
DetectorData
retrieve
Raw Data
SeadMaker
StatData
Space Points
VertexFinder
record
ClusterAnalyzer
Track candidates
TransientDetData
retrieve
start
AmbiguitySolver
TransientStatData
record
Resolved Tracks
start
retrieve
TrackFitter
Final Tracks
TrackScoring
Transient Storage
Tracking State machine
10 April 2019
V. Gyurjyan

18. ClaRA implementation details
ClaRA Platform
10 April 2019
V. Gyurjyan

19. Legacy software/hardware virtualization
Service abstracts software/hardware component
Service invoke actions which monitor or change the component state. S S S
ClaRA
Platform
IPC
IPC
IPC
Fortran Program
Farm Node
Storage
10 April 2019
V. Gyurjyan

20. ClaRA Service Categories
Normative services administrative service
Crate and manage all other services
Environment administration
Supervisor service - Contains state machine of the particular data processing
Data processing service NS SS S
10 April 2019
V. Gyurjyan

21. Service Creation NC NR NA ClaRA platform Description of the service
Administrative domain and container
ClaRA platform NC NR
Description of the service NA
Component
Service
Component
c/c++/Fortran
10 April 2019
V. Gyurjyan

22. C++ client. Service request
#include <cMsg.hxx>
//request a service
cMsg c(“rc://”, ‘service_name”, “service_description”);
c.connect();
10 April 2019
V. Gyurjyan

23. C++ client. Sends a message
//send a message to the representative service
cMsgMessage msg;
msg.setSubject(mySubject);
msg.setType(myType);
msg.setText(myText);
//actual send
c.send(msg);
c.flush();
10 April 2019
V. Gyurjyan

24. C++ client. Receiving a mesage
//callback class
class myCallback:public cMsgCallback{
void callback(cMsgMessage msg, void* userObject){
cout<<“receive subject is: ”<<msg.getSubject()<<endl;
} };
//subscribe and start receiving
c.subscribe(mySubject, myType, new myCallback());
c.start();
// do your computation…
10 April 2019
V. Gyurjyan

25. Summary
ClaRA project is active (with major interruptions) almost a year. More then 40,000 lines of code is developed.
Simplifies physics data processing application development
Separates physicist from the programmer
Normative services of the framework are tested.
Legacy software/hardware virtualization as a service has bin tested.
System distribution and scalability has bin tested.
10 April 2019
V. Gyurjyan

26. Future plans
Develop PersistentEvtDataService, capable of handling EVIO data format (based on JEVIO).
Define persistent detector data IO, and develop PersistentDetectorDataService.
Define persistent statistics data format, and develop PersistentStatisticsDataService.
Define transient data format and interface, and develop TransientDataServices.
Develop ClaRA specific ontology concepts, used in service description and communications.
10 April 2019
V. Gyurjyan