Gau
di
Use
rs G
uide
Cha
pter
1 I
ntro
duct
ion
Ver
sion
/Issu
e:9/
0
pag
e 2
The
doc
um
ent i
s ar
rang
ed a
s fo
llow
s: C
hapt
er 2
is a
sho
rt r
esum
e of
the
fram
ewor
k ar
chit
ectu
re, p
rese
nted
from
an
“Alg
orit
hm-c
entr
ic”
poi
nt o
f vie
w, a
nd re
-ite
rati
ng o
nly
a p
art
of w
hat i
s pr
esen
ted
in th
e A
DD
.
Cha
pter
3 c
onta
ins
a su
mm
ary
of th
e fu
ncti
onal
ity
whi
ch is
pre
sent
in th
e cu
rren
t rel
ease
, and
d
etai
ls o
f how
to o
btai
n an
d in
stal
l the
sof
twar
e.
Cha
pter
4 d
iscu
sses
in s
ome
det
ail a
n ex
amp
le w
hich
com
es w
ith
the
fram
ewor
k lib
rary
. It
cove
rs th
e m
ain
pro
gram
, som
e of
the
basi
c as
pec
ts o
f im
plem
enti
ng a
lgor
ithm
s, th
e sp
ecif
icat
ion
of j
ob o
ptio
ns a
nd ta
kes
a lo
ok a
t how
the
cod
e is
act
ually
exe
cute
d. T
he s
ubj
ect
of c
odin
g al
gori
thm
s is
trea
ted
in m
ore
dep
th in
Cha
pte
r 5.
Cha
pter
6 d
iscu
sses
the
use
of t
he fr
amew
ork
dat
a st
ores
and
eve
nt d
ata.
Cha
pter
7 g
ives
p
oint
ers
to g
uid
elin
es fo
r d
efin
ing
the
LH
Cb
even
t dat
a m
odel
. Cha
pter
s 8,
9, 1
0 d
iscu
ss th
e ot
her
type
s of
dat
a ac
cess
ible
via
thes
e st
ores
: det
ecto
r d
escr
ipti
on d
ata
(mat
eria
l an
d ge
omet
ry),
hist
ogra
m d
ata
and
n-tu
ple
s.
Cha
pter
11
dea
ls w
ith
serv
ices
ava
ilabl
e in
the
fram
ewor
k: jo
b op
tion
s, m
essa
ges,
par
ticl
e p
rop
erti
es, a
udit
ors,
chr
ono
& s
tat,
rand
om n
um
bers
, inc
iden
ts, i
ntro
spec
tion
. It a
lso
has
a se
ctio
n o
n d
evel
opin
g ne
w s
ervi
ces.
Fra
mew
ork
tool
s ar
e d
iscu
ssed
in C
hapt
er 1
2, th
e u
se a
nd
imp
lem
enta
tion
of c
onve
rter
cla
sses
in C
hapt
er 1
3.
Cha
pter
14
dis
cuss
es s
crip
tin
g as
a m
ean
s of
con
figu
ring
and
con
trol
ling
the
appl
icat
ion
in
tera
ctiv
ely.
Th
is is
follo
wed
by
a d
escr
ipti
on in
Ch
apte
r 15
of h
ow v
isu
alis
atio
n fa
cilit
ies
mig
ht b
e im
plem
ente
d in
sid
e G
aud
i.
Cha
pter
16
des
crib
es th
e p
acka
ge s
tru
ctu
re o
f Gau
di a
nd d
iscu
sses
the
dif
fere
nt ty
pes
of
libra
ries
in th
e d
istr
ibu
tion
.
Cha
pter
17
give
s po
inte
rs to
the
doc
um
enta
tion
for
cla
ss li
brar
ies
whi
ch w
e ar
e re
com
men
din
g to
be
use
d w
ithi
n G
aud
i.
The
use
of c
erta
in S
ICB
faci
litie
s w
ithi
n G
aud
i and
the
wra
pp
ing
of F
OR
TR
AN
cod
e ar
e d
iscu
ssed
in C
hapt
er 1
8.
App
end
ix A
con
tain
s a
list o
f ref
eren
ces.
Ap
pend
ix B
list
s th
e op
tion
s w
hich
may
be
spec
ifie
d
for
the
stan
dar
d c
ompo
nent
s av
aila
ble
in th
e cu
rren
t rel
ease
. Ap
pen
dix
C g
ives
the
det
ails
of
the
synt
ax a
nd p
ossi
ble
erro
r m
essa
ges
of th
e jo
b op
tion
s co
mp
iler.
Fina
lly, A
ppe
ndix
D is
a
smal
l gu
ide
to d
esig
nin
g cl
asse
s th
at a
re to
be
use
d in
con
junc
tion
wit
h th
e ap
plic
atio
n fr
amew
ork.
1.2
Co
nve
nti
on
s
1.2.
1 U
nit
s We
have
dec
ided
to a
dop
t the
sam
e sy
stem
of u
nits
as
CL
HE
P, a
s u
sed
also
by
GE
AN
T4.
Thi
s sy
stem
is fu
lly d
ocum
ente
d in
the
CL
HE
P w
eb p
ages
, at t
he U
RL:
ht
tp://
ww
win
fo.c
ern.
ch/a
sd/lh
c++
/clh
ep/m
anua
l/Use
rGui
de/U
nits
/uni
ts.h
tml.
p
age
3
Gau
di
Use
rs G
uide
Cha
pter
1 I
ntro
duct
ion
Ver
sion
/Issu
e:9/
0
The
list
of b
asic
uni
ts is
rep
rod
uce
d in
Tab
le 1
.1. N
ote
that
this
dif
fers
from
the
conv
enti
on
use
d in
SIC
B, w
here
the
basi
c u
nits
of l
engt
h, t
ime
and
ene
rgy
are,
res
pec
tive
ly, c
enti
met
re,
GeV
, sec
ond
..
Use
rs s
hou
ld n
ot a
ctua
lly n
eed
to k
now
wha
t uni
ts a
re u
sed
in th
e in
tern
al r
epre
sent
atio
n of
th
e d
ata,
as
long
as
they
are
con
sist
ent t
hro
ugh
out t
he G
aud
i dat
a st
ores
. Wha
t the
y ca
re
abou
t is
that
they
can
def
ine
and
plo
t qua
ntit
ies
wit
h th
e co
rrec
t uni
ts. I
n so
me
spec
ialis
ed
algo
rith
ms
they
may
als
o w
ish
to r
enor
mal
ise
the
dat
a to
a d
iffe
rent
set
of u
nits
, if t
he d
efau
lt
set w
ould
lead
to n
umer
ical
pre
cisi
on p
robl
ems.
We
ther
efor
e p
rop
ose
the
foll
owin
g ru
les,
wh
ich
are
dis
cuss
ed m
ore
fully
in r
efer
ence
[5].
1.A
ll d
imen
sion
ed q
uan
titi
es in
the
Gau
di d
ata
stor
es s
hall
conf
orm
to th
e C
LH
EP
syst
em o
f uni
ts.
2.A
ll d
efin
itio
ns o
f dim
ensi
oned
qu
anti
ties
sha
ll be
dim
ensi
oned
by
mu
ltip
lyin
g by
the
unit
s d
efin
ed in
the CLHEP/Units/SystemOfUnits.h
hea
der
file
. For
exa
mp
le:
Not
e th
at th
e u
ser
shou
ld n
ot c
are
abou
t th
e nu
mer
ical
val
ue o
f the
nu
mbe
rs
my_height
and
my_weight
. Int
erna
lly th
ese
num
bers
are
rep
rese
nted
as
1700
. and
4.
68e+
26. r
espe
ctiv
ely,
bu
t the
use
r d
oes
not n
eed
to k
now
.
3.A
ll ou
tpu
t of d
imen
sion
ed q
uan
titi
es s
hou
ld b
e co
nver
ted
to th
e re
quir
ed u
nits
by
divi
din
g by
the
uni
ts d
efin
ed in
the CLHEP/Units/SystemOfUnits.h
hea
der
file
. Fo
r ex
ampl
e:
whi
ch, f
or a
hea
lthy
per
son,
sho
uld
plo
t a n
um
ber
betw
een
19.
and
25.
...
4.Ph
ysic
al c
onst
ants
sho
uld
not
be
def
ined
in u
ser
cod
e. T
hey
shou
ld b
e ta
ken
dir
ectl
y fr
om th
e CLHEP/Units/PhysicalConstants.h
hea
der
file
. For
exa
mpl
e:
Tab
le 1
.1 C
LHE
P s
yste
m o
f uni
ts
Qu
anti
tyU
nit
Len
gth
mill
imet
re
Tim
ena
nos
econ
d
Ene
rgy
MeV
Ele
ctri
c ch
arge
pos
itro
n ch
arge
Tem
pera
ture
Kel
vin
Am
ount
of s
ubs
tanc
em
ole
Pla
ne a
ngl
era
dia
n
const double my_height = 170*cm;
const double my_weight = 75*kg;
my_hist = histoSvc()->book( "/stat/diet","corpulence
(kg/m**2)",30,10.,40.);
double my_corpulence = my_weight / (my_height*my_height);
my_hist->fill( my_corpulence/(kg/m2), 1. );
float my_rest_energy = my_weight * c_squared;
page 9
Gaudi Users GuideChapter 2 The framework architecture
Version/Issue: 9/0
and code which may consist of a simple statement or a set of
statements collected together into a function or procedure:
real function innerProduct(p1, p2)real p1(3),p2(3)innerProduct =
p1(1)*p2(1) + p1(2)*p2(2) + p1(3)*p2(3)end
Thus the physical and mathematical quantities map to data and
the algorithms map to a collection of functions.
A priori, we see no reason why moving to a language which
supports the idea of objects, such as C++, should change the way we
think of doing physics analysis. Thus the idea of having
essentially mathematical objects such as vectors, points etc. and
these being distinct from the more complex beasts which manipulate
them, e.g. fitting algorithms etc. is still valid. This is the
reason why the Gaudi application framework makes a clear
distinction between “data” objects and “algorithm” objects.
Anything which has as its origin a concept such as hit, point,
vector, trajectory, i.e. a clear “quantity-like” entity should be
implemented by deriving a class from the DataObject base class.
On the other hand anything which is essentially a “procedure”,
i.e. a set of rules for performing transformations on more
data-like objects, or for creating new data-like objects should be
designed as a class derived from the Algorithm base class.
Further more you should not have objects derived from DataObject
performing long complex algorithmic procedures. The intention is
that these objects are “small”.
Tracks which fit themselves are of course possible: you could
have a constructor which took a list of hits as a parameter; but
they are silly