I would like to see something along the following lines. The hope is that it
would be sufficiently flexible to be used by event generation programs as
well as reconstruction or other event analysis.
Information structure
---------------------
Every piece of parameter information belongs to a _component_. A component
may be either a subdetector (e.g. EM barrel calorimeter), or it may be
an abstraction which happens to be convenient for grouping together
some set of values.
Every component has a name (a string).
A component may (and typically does) have a list of properties (would
appear as a string in an initialization file, but probably translates to value
of some enumerated type).
Might be useful to have the concept of _parent_, where one component
can indicate that it somehow belongs to another.
Each parameter value belongs to exactly one component, but the same parameter
name may appear in more than one component (that is, to fully specify which
parameter is meant you need its name and its containing component).
With components, parameters may have values which are integers (signed
and unsigned?), float (perhaps always stored as double?), strings,
logical flags, or a list of any of these. (Could be that we
want to allow more complex combinations of these, e.g. inhomegeneous
lists, lists including lists, etc.)
Initialization from a file
--------------------------
One way to get such information into a program would be to read it from a file.
For a first-pass attempt at modifying a Detector.ini file to deal with
some of these things, see the bottom of this note. The file is much longer
than necessary to make the points I wanted to make; it's sufficient to look at
the beginning page or so and the end.
I am not attempting to deal here with issues of how the file(s) is(are)
specified and at what time it(they) would be read.
Querying information - the parameter server
-------------------------------------------
All parameters, no matter how they are input, would be maintained by a single
facility. This facility would store all parameters and values in some
convenient form, keeping track of certain organizational information.
The server would have to know the format of the information it was storing,
I'm not sure how. If read from a file, it might be possible to come up
with a syntax which would make the format explicit without being too cluttered
and difficult to use. If not, we'd need to supply ancillary format information
some other way. There would also be "put" methods to add parameters to the
server's database with formatting information either in the name
(PutRealValue(...)) or as an argument (PutValue(ValType typ,...))
In particular, it should be possible to ask the facility for
* a list of all components (i.e., some key for each component so that
it may be queried further)
* a list of all components (i.e., a list of keys) having some particular
property
* a key for a specific component when its name is supplied as input
* all properties belonging to a particular component
* the name of a component when its key is supplied as input
* a value for a specific parameter belonging to a specific component
Possible modes of use
---------------------
In all cases I'm assuming that somehow the information has made it to
the server facility.
Most applications would probably ask for a list of all components. For
each component, it would then ask for its name and list of properties.
This would most likely be enough information for the application to
decide if the component was interesting (to it), and, if so, ask for
parameters belonging to the component.
Small development applications might just ask for the particular component(s)
needed by name.
--------------------------------------------------------------
//
// Exactly which segments and qualifiers appear in a file is
// arbitrary. That is, nothing need be present, except that every
// block beginning
//
// COMPONENT:
//
// must have a line (the component name line)
//
// name = something-or-other
//
// Would be nice if the parser understood includes, for example if
// @fname.ext
// caused it to open and read fname.ext to the end, then revert back
// to reading the including file
//
// Also could be useful to allow the same component to be mentioned
// in more than one COMPONENT block. The set of values stored for
// the component would be the union of those in all blocks referring
// to that component (two blocks refer to the same component by having
// the same value in their component name lines). If the same value name
// (e.g., inner_radius) appeared in more than one block referring to the
// same component, the last value read would overwrite any
// previously-existing value (and maybe generate a warning?)
//
///////////////////////////////////////////////////////////////////////
// ElectroMagnetic SubSystem
COMPONENT:
name = EM_Barrel
parent = EM
PROPERTIES:
barrel
calorimeter
EM
physical
end PROPERTIES;
geometry = cylinder
inner_radius = 55.0f
outer_radius = 90.f
z_outer= 155.0f
layers= 50f
iwall_thickness = 0.0f
owall_thickness = 0.0f
Materials:
W, 0.2f
Si, 0.03f, $
G10, 0.1f
Air, 0.17f
end Materials;
IWall_Materials:
Al, 1.0f
end IWall_Materials;
OWall_Materials:
Al, 1.0f
end OWall_Materials;
end COMPONENT;
COMPONENT:
name = EM_EndCap
parent = EM
PROPERTIES:
endcap
calorimeter
EM
physical
reflect
end PROPERTIES;
geometry = cylinder:
inner_radius= 20.2f
outer_radius= 55.0f
z_inner= 120.0f
z_outer= 155.0f
end geometry;
layers= 50.0f
slope= 0.f
iwall_thickness = 0.0f
owall_thickness = 0.0f
Materials:
W, 0.2f
Si, 0.03f, $
G10, 0.1f
Air, 0.17f
end Materials;
IWall_Materials:
Al, 1.0f
end IWall_Materials;
OWall_Material:
Al, 1.0f
end OWall_Material;
end COMPONENT;
COMPONENT:
name = EM
PROPERTIES:
Calorimeter
EM
end PROPERTIES
Segmentation:
tan_lambda (300.0f, 300.0f, 300.0f)
phi (300.0f, 300.0f, 300.0f)
end Segmentation;
end COMPONENT:
///////////////////////////////////////////////////////////////////////
// Hadronic SubSystem
COMPONENT:
name = HAD_Barrel
parent = HAD
PROPERTIES:
barrel
calorimeter
HAD
Physical
end PROPERTIES;
geometry = cylinder:
inner_radius = 140.0f
outer_radius = 250.0f
z_outer= 265.0f
end geometry;
layers= 38.0f
iwall_thickness = 0.0f
owall_thickness = 0.0f
Materials:
Cu, 2.0f
Polystyrene, 0.5f, $
end Materials;
IWall_Materials:
Al, 1.0f
end IWall_Materials;
OWall_Materials:
Al, 1.0f
end OWall_Materials;
end COMPONENT;
COMPONENT:
name = HAD_EndCap
parent = HAD
PROPERTIES:
HAD
Calorimeter
Endcap
Physical
Reflect
end PROPERTIS;
geometry = cylinder:
inner_radius= 20.2f
outer_radius= 140.0f
z_inner= 155.0f
z_outer= 265.0f
end geometry;
layers= 38.0f
slope= 0.f
iwall_thickness = 0.0f
owall_thickness = 0.0f
Materials:
Cu, 2.0f
Polystyrene, 0.5f, $
end Materials;
IWall_Materials:
Al, 1.0f
end IWall_Materials;
OWall_Material:
Al, 1.0f
end OWall_Material;
end COMPONENT;
COMPONENT:
name = HAD
PROPERTIES
HAD
Calorimeter
end PROPERTIES;
Segmentation:
tan_lambda (100.0f, 100.0f, 100.0f)
phi (100.0f, 100.0f, 100.0f)
end Segmentation;
end COMPONENT;
// Would be nice if parser understood includes
@my_muon.ini
@my_lum.ini
///////////////////////////////////////////////////////////////////////
// Vertex SubSystem
COMPONENT:
name = VERTX_Barrel
PROPERTIES
VERTX
Barrel
Tracker
Physical
end PROPERTIES;
geometry = cylinder:
inner_radius = 1.2f
outer_radius = 7.5f
z_outer= 12.5f
end geometry;
layers= 5.0f
Materials:
G10, 0.1f
Si, 0.03f, $
air, 1.07f
end Materials;
end COMPONENT;
///////////////////////////////////////////////////////////////////////
// Track SubSystem
COMPONENT:
name = TRACK_Barrel
PROPERTIES
TRACK
Barrel
Tracker
Physical
end PROPERTIES;
geometry = cylinder:
inner_radius = 15.f
outer_radius = 54.f
z_outer= 119.0f
end geometry;
iwall_thickness = 0.0f
owall_thickness = 0.0f
layers= 5.0f
// Dimensions as per K.Riles 8.12.98
Materials:
G10, 0.11f
Si, 0.06f, $
air, 7.63f
end Materials;
end COMPONENT;
COMPONENT:
name = TRACK_EndCap:
PROPERTIES
TRACK
Endcap
Tracker
Physical
Reflect
end PROPERTIES;
geometry = cylinder:
z_outer = 119.5f
end geometry;
iwall_thickness = 0.0f
owall_thickness = 0.0f
layers = 1.0f
slope = 0.0f
Tracker_EndCap_Material:
Al, 0.2f
end;
end COMPONENT;
///////////////////////////////////////////////////////////////////////
// Beam pipe
COMPONENT:
name = Pipe_BARREL
PROPERTIES:
barrel
Pipe
Physical
end PROPERTIES:
geometry = cylinder:
inner_radius = 1.0f
outer_radius = 1.2f
z_inner= 125.0f
z_outer= 125.0f
end geometry;
layers= 0.0f
Materials:
Be, 0.2f
end Materials;
end COMPONENT;
///////////////////////////////////////////////////////////////////////
// NLD Field
COMPONENT
name = Coil
PROPERTIES:
Coil
Physical
end PROPERTIES;
geometry = cylinder:
inner_radius = ??
outer_radius = ???
z_outer = ??
end geometry;
Field:
length= 125.0f
r_inner= 90.0f
r_outer= 500.0f // radial distance beyond which field is zero
Solenoid_Vector(0.0f, 0.0f, 6.0f)
Outside_Vector(0.0f, 0.0f, -0.6f)
end Field;
Materials:
Al, 50.0f // r_outer= r_inner+50.0f there. This entry has to be last
end Materials;
end COMPONENT;
COMPONENT
name = CalSmearParam
PROPERTIES:
smear
calorimeter
end PROPERTIES;
// Parameters for smearing energy of hadrons
Had_Part_Energy:
0.45f
0.02f
end Had_Part_Energy:
// Parameters for smearing energy of e, gamma
EM_Part_Energy:
0.12f
0.01f
end EM_Part_Energy;
end COMPONENT;
|
