This project was born because the existing FLT simulation L1SIMU was
written in the spirit of proof of principle. The new simulation fltsim
will reflect the details of the FLT hardware system.
The new package requirements
Responsibilities
Schedule
Literature and Team communication
Analysis
Design
Programming
Documentation
The new package requirements
:
The global requirements for the fltsim project are:
Reflect as closely as possible the FLT hardware realization (primordial
for correct debugging of the system).
Provide the needed lookup-tables as functions with geometry constants.
Provide efficiencies
Study the real time behavior of the FLT processing.
Simulate the FLT processing in modules which can be extracted from
the program to run in online environment.
Run in stand alone mode and in ARTE frame.
Clear interfaces to the used HERA-B packages (avoid strong dependence
on the changes of these packages).
Use the official HERA-B version control system CVS (still a question).
Simulation should be written according to well defined programming
conventions.
Simulation should satisfy some restrictions to run on different platforms.
Simulation written for HERA-B life time.
Clear strategy for group development and updates.
The DOCUMENTATION should be written during the project realization
Up: fltsim index
Responsibilities:
Responsibilities should be distributed among the involved groups in
the FLT realization. The agreement up to now is :
- First steps in Analysis and Design (all)
- Event management (Fedor)
- ECAL pretrigger related classes (Bologna)
- Muon pretrigger related classes (Dortmund)
- High Pt pretrigger related classes (Princeton, ITEP)
- TFU,TPU, MCU related classes (DESY-HH, Mannheim)
- ARTE interface (Fedor)
- User interface (?)
- Graphics/Visualization (?)
Up: fltsim index
Schedule:
The realization of the project follows the following steps:
- Level-0: Design version. Contains only the framework.
- Level-1: First version for testing and reconsideration of parts of
the design. However, first analysis steps can and must be done with this
version.
- Level-2: Tested version ready to provide analysis results and online
software modules.
- Level-3: Final version according to requirement analysis (full GUI,
more algorithms ...).
In order to organize the development of the work, setting schedules
and internal milestones, a time table is needed. According to the 25/3/97
meeting we have the following time table:
Task |
Name |
Date |
System |
TW |
21/4 |
Detector geometry |
FR |
5/5 |
user interface |
TW |
? |
configuration |
TW |
9/6 |
TFU :naming,interfaces,pipelinesteps |
CH+TF+F.S-L |
1/4 |
first circuit operating functions |
CH+TF+F.S-L |
28/4 |
all TFU circuits |
CH+TF+F.S-L; |
9/6 |
Testboard |
TF |
9/6 |
Electron pretrigger |
Bologna |
9/6 |
Muon pretrigger |
? |
? |
High Pt pretrigger |
later |
? |
TPU |
later |
? |
TDU |
later |
? |
Up: fltsim index
Literature and Team communication:
Team communication is considered as an essential and important ingredient,
in particular the acquisition and sharing of the most relevant literature
and continues discussions. In the following we give a list of books which
seems to cope best with the present various levels of knowledges.
- Beginners without C knowledges:
Practical C++ Programming, Steve Oualline, (O'Reilly)
- Beginners with some C knowledges:
C++ Primer, Stanley B. Lippman (Addison Wesley)
- Beginners with good C knowledges:
C++ for C Programmers, Ira Pohl (Benjamin Cummings)
- Advanced C++ programmers:
The C++ Programming Language, Bjarne Stroustrup (Addison Wesley)
Advanced C++, James O. Coplien (Addison Wesley)
- C++ developers:
Design Patterns, James O. Coplien (Addison Wesley)
Design Patterns, E.Gamma et al. (Addison Wesley)
Object-Oriented Analysis and Design, Grady Booch (Benjamin Cummings)
C++ is a rather complex language which offers many possibilities in
doing the same thing in different ways. As compared to procedural languages
as C and Fortran learning OO programming means more than reading textbooks.
Experience and communication is more important than before.
Up: fltsim index
Analysis:
The aim of the analysis is to analyze, specify and define the system
to be built. This model should tell us WHAT the system will do. We will
model the project in term of object types, their interfaces, their associations
and what happens to those object types over time.
Up: fltsim index
Design:
Based on the found object types during the analysis and their behavior
in time, we will define :
- The classes to be implemented.
- These classes interfaces.
- The data structure each class will employ.
- What operations each class offers and the correspon