Bottom-up philosophy: develop concrete classes first then abstract,
Layered structure:
abstract layer, core elements and data structures
Generic applications - templated layer
concrete classes
continuously moving things up
- concerns: changing interfaces for people, db schema changes
Frameworks basic dynamics:
No central ordering of actions, no central explicit control of data flow: only implicit
dependencies
Event driven manager -
Services:
define events to be dispatched
select amoung resources/plug-ins
manage the sequential actions
Middle layer:
contains most of the code, not the core layer
application is characterised by the events it dispatches
implement generic clients to specific services
simplified API
uniform detailed design
uniform use of ancillary services
Examples - use cases:
L1 trigger simulation
Track reconstruction - no data flow on small scale only on global scale
Physics reconstruction - traj+e cluster => 4-vec
- many algorithms to be applied to this data
- access to original detector data may be required
=> reconstruction scenario:
- reproduce detector status at moment interaction took place (crossing)
- do local reconstruction until "detachable" (from the detector) objects are
obtained
- work with these for analysis
Event driven notification:
- observers register to the dispatchers, one dispatcher per event type
- some external event comes to the dispatcher and this will bebroadcast to all observers
- the framework decides which kind of events to be used
Active and lazy observers:
- lazy observers receive events but do not do anything until an active observer requests
something specifically from a lazy observer.
"Events" currently dispatched:
Object id:
- RecObj coll
- object type
- name of reconstructor called RecUnit (ascii instance name)
(names used for parameters from UI)
- event to which it belongs
- RecUnit not needed to be there
RecObj object model:
- one Reconstructor per physics event
Obj ID
- Detector object: id'ed by type and detector element that it belongs to
- belongs to a single "crossing" or physics event
- must be calibrated/aligned
For local reconstruction, e.g. recon hits in a particular muon chamber, there is a
reconstructor for each detector element which can all run in parallel.
Discussion :
John: Where does the framework end and the application begin? How does the client
developer interact with the framework? How much can one put into the framework to make
life easy for the developers?
Example: having the real state of the detector being available when one wants to
reconstruct?
Vincenzo : Wall between the two is opaque for the developer, and porous for the framework
developerto understand what needs to be dispatched. Now there are 4-5 types of events.
How many types of events need to be known by each use observer? Just a few.
Vincenzo: Not yet, but will be there. User specifies the calib that one wants.
Lassi:
Comment: don't have as many reconstructors.
Question: what size are the reconstructors in terms of sze of task?
Answer: not too big.
All objects that have to do local reconstruction are lazy: they receive notification that
a new event has arrived, and will run only when requested explicitly. Observers do not
generate notifications/events themselves.
Dirk: whole design oriented to be "lazy" or "on-demand", how much does
this help?
Ans: they avoid all of the "dead bodies" which are always executed even
when not needed.
RD: How are dependencies defined?
Ans: done by name/common block type way. Naming varies with the context. For example, for
the tracker reconstruction.
Rene: event driven system, problem is that one loses the global view, for example what to
read from the database. Someone needs to know what to read in advance or together. If data
are stored in a hierarchy, then one must priviledge the knowledge of the hierarchy to
efficiently read things.
Vincenzo: always have the possiblility to load the whole event in active memory.
Rene: caching is important.
Vincenzo: tracker people want to copy into local objects to improve performance. This is a
local optimisation, and does not belong to the framework.
Rene: If one knows that one has a hierarchy, one should expose this, and not have people
presume
Rene : What is the status of CARF and how many classes does it contain
Vincenzo : CARF is in production now. The core is very small - 3 class, dispatcher and
observer. Most of the code is in the middle layer (~50 classes)
Vincenzo: not his job to make GUI, or script interface. Doesn't need a custom GUI.
Rene: need to define the GUI, otherwise one will be developed for the the different
applications. Should define something that works both for batch and interactive use.
RD's Summary (after reflection):
Overall view of the architecture (not necessarily completely correct):
1) There is one dispatcher singleton per event type.
2) There are a number of observers associated with each dispatcher.
3) The observers come in two types:
a) lazy - when triggered by the dispatcher, they do an initial setup but do not perform
what they are supposed to do until directly requested to do so by another objserver.
b) active - when triggered by the dispatcher they immediately do what their supposed to
do.
4) There are external actors that send "triggers" to the dispatcher, who in turn
broadcast these triggers to all observers.
e.g. an object from the db when brought into the db cache can cause an external trigger to
be sent to the dispatcher.
5) The active observers begin their activity immediately, and request other lazy observers
to "do their job" by first looking up the lazy observer by name, and then
calling some method of it.
6) Appears to be only a few external actors which trigger the system, and only a few
observers which are active.
Next week we meet with Dave Quarrie (BaBar). Let JH know if there are specific issues that
we would like Dave to address.
Future Meetings
In July look at the applications, in September make comparisons and try to draw some
conclusions.