Linear Collider Forum



Today's Messages (off)  | Unanswered Messages (on)

Forum: Mokka
 Topic: New release Mokka 06-07
New release Mokka 06-07 [message #1621] Thu, 13 November 2008 08:57
musat
Messages: 57
Registered: February 2004
Dear friends,

New release Mokka 6.7 is available for download at the usual address: mokka.in2p3.fr.


Cheers,
Gabriel

From Release Notes:

============================================================ ==
New tag mokka-06-07
===================

What is new in this Mokka release
=================================

I. New detector model ILD_00
I.1) New HCAL superdriver SHcalSc02
I.2) New LHcAL superdriver SLcal01
I.3) New LCAL superdriver SLcal02
I.4) New implementation for Yoke and coil
I.5) New Bcal superdriver SBcal01 using BeamCal00 and BeamCalSD00
I.6) New FTD self scaling driver
I.7) New SIT self scaling driver
I.8 ) New SET self scaling driver
I.9) New ETD self scaling dirver

II. Bug fix in TRKSD00
III. New TB models for Cern 2007 and FNAL 2008
IV. moved CGAGearDistanceProperties and CGAGearPointProperties
from gear to Mokka ( libMokkaGear.a )
V. fix for reading problematic stdhep files
VI. new command /Mokka/init/lcioEventParameter
to be used for cross section and processID

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.1.p02 and CLHEP 2.0.3.2
(but it is still compatible with previous Geant4 / CLHEP versions)
LCIO v01-10-03 (needed !!)
gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-11

============================================================ ===================

I. New detector model ILD_00

A new model 'ILD_00' was created for the ILD simulation
baseline reference detector. It is based on the detector parameters
discussed at Cambridge and in the current DRAFT ILDReference document
(www.ilcild.org).

One needs this version of Mokka and a GEAR version v00-11 to use
this model (gear now has parameters for the coil, lhcal and the Yoke).

The following detector drivers are updated or new implementation:

I.1) New HCAL superdriver SHcalSc02 (Angela Lucaci)

It's a new HCAL superdriver with modified endcaps as in
the Tesla design, that is with a square hole in the middle,
and cracks along the square borders. The basic endcap stave
is a union of a box and a right wedge.

The modified geometry needed a new sensitive detector class
for the HCAL endcaps: SDHcalEndCapTesla.

Note that this is used only for the endcaps. The HCAL rings
still use the old class SDHcalEndCap.

In the endcaps, the HCAL layers are perpendicular to the
z-axis. In the x-y plane, the virtual tiles are square, with the
dimensions 30x30 mm^2. Hits in tiles which are not fully
contained in the sensitive volume are rejected. The
counting of the I and J cell coordinates starts from the
lower left corner of the stave, in the x-y plane. The
notation of the staves is the same as in the old geometry
(for more details, see
http://www-flc.desy.de/lcnotes/notes/LC-TOOL-2008-001.pdf)

I.2) New LHcal superdriver SLHcal01

This new super driver implements the LHcal as a parallelepiped
volume, with size = 330.6 mm, 525 mm long. It's placed inside
the Hcal end cap (30 mm after the end cap entering boundary).
Its central hole is a cylinder which is not centered, but
which should follow the crossing angle to avoid overlapping
the beam pipe.

The LHcal has 40 W layers of 10 mm, behind each one a Si
sensitive layer almost as the Ecal rings. For this reason
SLHcal01 reuses the same sensitive detector implemented
for the Ecal rings. The only difference is that the
SLHcal01 has not a pre-shower layer.For this reason
SLHcal01 depends on the Ecal slab parameters, as it's almost
the same technology.

SLHcal01 depends on the following global parameters, with the
current values for the ILD_00:

Ecal_Alveolus_Air_Gap = 0.25
Ecal_Si_thickness = 0.5
Ecal_Slab_PCB_thickness = 0.8
Ecal_Slab_copper_thickness = 0.2
Ecal_Slab_glue_gap = 0.1
Ecal_Slab_ground_thickness = 0.05
Ecal_Slab_shielding = 0.15
Ecal_fiber_thickness = 0.2
Hcal_endcap_center_box_size = 700.0
Hcal_endcap_zmin = 2670.7
LHcal_Electronics_space = 19.4
LHcal_cell_size = 10
LHcal_inner_radius = 93
LHcal_lateral_face_thickness = 10
LHcal_nlayers = 40
LHcal_radiator_thickness = 10
LHcal_zmin_displacement = 30
TUBE_crossing_angle = 14

Currently SLHcal01 exports the following parameters, with the
current values for the ILD_00:
LHcal_zend = 3225.7

I.3) New LCAL superdriver SLcal02 (B. Pawlik)

SLcal02 superdriver does not have database, only parameters.
For actual build of LCAL LumiCalX subdriver is used.
SLcal02 sets the z-position of LCAL (Lcal_z_begin parameter)
according to the value of the Ecal_endcap_zmax. It also assures that
outer radius of LCAL ( Lcal_outer_radius parameter) is consistent with
inner radius of ECAL endcap plug. It checks whether lenght of LCAL
fits into space in ECAl endcup.
Parameters known to SLcal02 are :

name default value comment
------ --------------
Lcal_z_begin 3050 mm
Lcal_inner_radius 80.0 mm
Lcal_outer_radius 195.2 mm
Lcal_n_layers 30
Lcal_phi_offset 0. deg
Lcal_tungsten_thickness 3.5 mm thickness of absorber
Lcal_support_thickness 0.2 mm fanout,interconnection
plane thickness
Lcal_silicon_thickness 0.32 mm silicon sensor
Lcal_layer_gap 0.25 mm clearance between LCAL
planes
Lcal_nstrips_theta 64 radial segmentation
Lcal_nstrips_phi 48 number of phi sectors

SLcal02 needs also following 'exetrnal' parameters normally set SEcal03
superdriver.

Ecal_Lcal_ring_gap - clearance between LCAL and ECAL endcap PLUG
Ecal_endcap_zmax
Ecal_endcup_zmin
Ecal_endcap_plug_rmin
ILC_Main_Crossing_Angle

The default values of parameters above, can be changed by user at run
time with the card:

/Mokka/init/globalModelParameter "parameter_name" value

NOTE: Functionality of changing Lcal_z_begin, and Lcal_outer_radius
at run time is limited in case ECAL is build.


I.4) New implementation for Yoke and Coil (F. Gaede)
SCoil02.cc:
- replace hardcoded values by parameters:
Hcal_Coil_additional_gap, Coil_Yoke_radial_clearance and
Coil_Yoke_lateral_clearance

Yoke04.cc
- added barrelEndcapGap, gear parameters, made barrel and endcap
same thickness, made plug insensitive
- changed outer r of yoke plug to be aligned with hcal endcap

I.5) New Bcal superdriver SBcal01 (A.Hartin)

- first implementation, code from Fcal collaboration,
* position of sensitive layer corrected
* several constants moved to beamcal table
* superdriver by A. Sapronov, A. Rosca and A. Popescu
* implemented in Mokka by A. Hartin and S. Aplin, Oct 2008

I.6) New FTD self scaling driver SFtd04.cc (S. Aplin)

Implementation of a self scaling 7 disk FTD first 3 Disks are Si-pixel technology
last 4 Disks are Si-strip technology Support material Kapton

All disks:
Dimentions and co-ordinates are specified for the sensitive layer, support disks are built
on to these inner_radius = ( beamTubeRadius + beamTubeClearance)

First Disk:
z defined by distance from end of VTX layer 3 outer r defined by radial difference
to SIT layer 1

Second Disk:
z defined relative to TPC half-length: to ensure positioning with SIT set these numbers to
the same value in DB outer r defined by radial difference to SIT layer 1

Third Disk:
z defined relative to TPC half-length: to ensure positioning with SIT set these numbers to
the same value in DB outer r defined by radial difference to SIT layer 1

Fourth, Fifth and Sixth Disk: z defined relative to TPC half-length outer r defined by gap
between TPC inner radius and FTD disks

Last Disk:
z defined by distance from front of ECal Endcap outer r defined by gap between TPC inner
radius and FTD disks

The energy threshold to produce a hit has been set at 20% of a MIP for the thinnest disk.

Parameters Set in Model Parameter DB Table:
TPC_Ecal_Hcal_barrel_halfZ
Ecal_endcap_zmin
TPC_inner_radius
VXD_length_r3

Parameters shared with other drivers:
SSit03:SIT1_Half_Length_Z
SSit03:SIT2_Half_Length_Z
SSit03:SIT1_Radius
SSit03:SIT2_Radius
TubeX01:TUBE_IPOuterTube_end_z
TubeX01:TUBE_IPOuterTube_end_radius
TubeX01:TUBE_IPOuterBulge_end_z
TubeX01:TUBE_IPOuterBulge_end_radius

I.7) New SIT self scaling driver SSit03.cc ( S. Aplin )

The radius of the sensitive layer of the outer layer is defined by the distance to the TPC
inner radius. The radius of the sensitive layer of the inner layer is defined by the relative
position between the SIT outer layer and the VTX outer layer.
Half-lengths in z are defined relative to the TPC ECal barrel length


I.8 ) New SET self scaling driver SSet02.cc ( S. Aplin )

The SET is composed of two support backed silicon layers.

The radius of the outer layer is specified by the distance to the min Radius of the ECal
Barrel. The radius of the inner layer is specified by the radial distance between the two
layers. Both layers have the same Half-length as the TPC

I.9) New ETD self scaling dirver ( S. Aplin )

The inner radius of disks defined by the radial clearance between the ETD and ECal-EndCap
Plug outer radius of disks defined by radial difference from the TPC outer radius z
positions are given by the distance between the last ETD sensitive layer and the
ECal-EndCap face plus layer separation and thickness.


II. bug fix in TRKSD00

Piotr Niezurawski noticed that the sensitive detector implemented in
class TRKSD00 had a bug, as described by him at:

http://polzope.in2p3.fr:8081/MOKKA/issues-tracker/4

This class, originally designed to work with the first versions of the
TPC, was then adopted by many other sub-detectors: ETD, FTD, SET, SiT, VXD.

Piotr made a correction of this bug, the class was renamed to TRKSiSD00
and the necessary corrections were made to all VXD drivers so that they
now use this new class.



III. New TB models for Cern 2007 and FNAL 2008

We have 3 new models for TBCern 2007, that have the new DCHs implementation
made by Fabrizio Salvatore (like the Desy/FNAL DCHs, i.e. with one single
hit collection and each chamber sub-divided in two halves, one for x-hits
and one for y-hits). Their names are:

TBCern07_dchxy_01 (with the ideal Ecal),
TBCern0707_dchxy_01 (with the Ecal in Jully 07 config), and
TBCern0807_dchxy_01(with the Ecal in the August 07 config).

An implementation was made for the TB setup at FNAL, the first period
of '08, except the wire chambers and the detectors before them.
The model name is TBFnal0508


IV. moved CGAGearDistanceProperties and CGAGearPointProperties
from gear to Mokka ( libMokkaGear.a ) (F.Gaede)

moved the code from GEAR to Mokka in order to remove circular dependency

V. fix for reading problematic stdhep files (M.Berggren, F.Gaede)

Fix in HepLCIOInterface for reading problematic stdhep files with FSR on mu and tau leptons.
These files caused double counting of the leptons in older versions of Mokka.
The old behaviour can be restored with:

/Mokka/init/FixStdHepLeptonFSR false

Note: the generator status of 'documentation' type particles that are not presented to geant4
is increased by 100, e.g if the particle had genstat 2 it will have genstat 102 after processing

VI. new command /Mokka/init/lcioEventParameter (F.Gaede)

this command allows to specify constant parameters in the steering file that are
then added to every LCIO event, eg.

/Mokka/init/lcioEventParameter float CrossSection_fb 1234.56
/Mokka/init/lcioEventParameter string Process e3e3h_250_ep+1.0_em-1.0
/Mokka/init/lcioEventParameter int ProcessID 42






 Topic: Scheduled shutdown at LLR
icon4.gif  Scheduled shutdown at LLR [message #1620] Fri, 07 November 2008 06:40
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...

Dear all,

We'll have a scheduled shutdown for electric maintenance on our machine's room, starting the next Sunday 9th November at 20:00 till Monday 10th, 16:00. It includes the Mokka cvs and DB servers.

Sorry for this inconvenience,
Paulo.
 Topic: New release Mokka 06-06-p01
New release Mokka 06-06-p01 [message #1474] Wed, 21 May 2008 04:15
musat
Messages: 57
Registered: February 2004
Dear friends,

New release Mokka 6.6.p01 is available for download at the usual address: mokka.in2p3.fr.

Please note that the last two LDC/LDCPrime models have been
renamed to LDC01_06Sc and LDCPrime_02Sc and their status was set
to 'frozen'.

Cheers,
Gabriel

From Release Notes:

============================================================ ==
New tag mokka-06-06-p01

What is new in this Mokka release
=================================

I. New steering commands available to change FieldManager parameters

II. New FTD self scaling FTD Driver SFtd03

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.1.p02 and CLHEP 2.0.3.2
(but it is still compatible with previous Geant4 / CLHEP versions)
LCIO v01-05, v01-06, v01-07, v01-08-01 or v01-09 (recommended),
gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-08-02

============================================================ ===================

I. New steering commands available to change FieldManager parameters

Two new steering commands were implemented to change the parameters
DeltaIntersection and DeltaOneStep of the FieldManager:
They can be used in the steering file, like, for example:

/Mokka/init/userDeltaIntersection 3e-5 mm
/Mokka/init/userDeltaOneStep 3e-4 mm

II. New FTD self scaling FTD Driver SFtd03

It is a self scaling driver where the z positions of the disks are set
relative to the length of the TPC and the inner radius of the disks are
calculated as a function of the beamtube opening angle.
The TUBE_opening_angle is used, though this does not affect the actual
beam tube in Mokka, as that does not take this value as a parameter,
nor does it attempt to set it. The actual opening angle of the section
of the beam tube lying directly under the FTD in the Mokka model
LDC01_06Sc has a tangent of 0.07876. As the value of TUBE_opening_angle
will be set to 0.092 the FTD will not suffer any geometric overlap with
the beam tube and the inner radii will be of the desired size, not a
great solution but at least safe for now.

There are values for cable shield thickness, cable thickness and
outer support cylinder thickness in the Database.


 Topic: Changes of the names of LDC models
Changes of the names of LDC models [message #1450] Fri, 18 April 2008 05:53
musat
Messages: 57
Registered: February 2004
Dear friends,

People that had contributed to the last two Mokka LDC models decided to rename them as follows:

- rename LDC01_06Sc_test as LDC01_06Sc_p01

and

- rename LDCPrime_02Sc_test as LDCPrime_02Sc_p01

leaving both "unstable".


The DB models03 on pollin1 was updated with respect to these decisions.

Cheers, Gabriel
 Topic: New release Mokka 06-06
New release Mokka 06-06 [message #1449] Fri, 18 April 2008 03:10
musat
Messages: 57
Registered: February 2004
Dear friends,

A new Mokka release Mokka-06-06 is now available for download at

mokka.in2p3.fr

Cheers, Gabriel

=================================

From release Notes:

=================================

I. Updating PhysicsListFactory
II. Bug fix in RunManager class
III. Geometry fixes to Cern 2007 TB models
IV. Density bug fix in TBhcal06
V. Warning for bugs with SEcal02
VI. New SEcal03 driver
VII. Improved FieldMap implementation in Field00
VIII. New Vertex Detector Geometries
IX. New HCAL superdriver SHcalSc01 and new HCAL sensitive detectors
X. Improvement of Ecal implementation for TB Cern 2006 models
XI. Bug fix in VTX-Gear interface
XII. New steering command setting the MC Run Number of LCEvent
XIII. Bug fix in TrackSummary w/ SimulatorStatus - isCreatedInSimulation
XIV. New digital Hcal implementation
XV. New SilC drivers

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.1 and CLHEP 2.0.3.2
(but it is still compatible with previous Geant4 / CLHEP versions)
LCIO v01-05, v01-06, v01-07, v01-08-01 or v01-09 (recommended),
gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-08-02

============================================================ ===================
I. Updating PhysicsListFactory

The PhysicsListFactory can now instantiate the new physics lists that
became available with Geant4 9.1 : FTFP_BERT, QGSC_BERT, QGSP_DIF,
QGSP_BERT_DIF, QGS_BIC and FTF_BIC.

A macro was added to test for the Geant4 release in order to allow
previous Geant4 releases to be used.

II. Bug fix in RunManager class

A fix was made in the method RunManager::RunInitialization() that is
aimed to avoid a memory leak while repeating many times the command

/run/beamOn

The fix was also checked when running Mokka in visualization mode.


III. Geometry fixes to Cern 2007 TB models

Some corrections were added to the drivers TBcatcher06 and TBmuoncount03
in order to remove overlaps between TCMT and Hcal when using nonzero
configuration angles.
A bug in the definition of the hit position in all scintillators drivers
have also been corrected. Now all the hits are generated in the correct
(x,y) position.

IV. Density bug fix in TBhcal06

The density of the PCB (Printed Circuit Board) material FR4 was corrected to
be 1.7*g/cm3 (instead of the old incorrect value of 1.025*g/c,3). The corrected
value was taken from http://pcba10.ba.infn.it/temp/ddd/ma/materials/list.html.


V. Warning for bugs with SEcal02 and its sensitive detector SEcalSD02

The released SEcal02 driver has known bugs concerning the hits in the end caps.
It's not fixed, as we have to insure backward compatibility with the models using
it (LDC01_05Sc and LDCPrime_01Sc). Users should avoid using these models.


VI. New SEcal03 driver and sensitive detector SEcalSD03

The new SEcal03 driver and its sensitive detector fix the known bugs with
SEcal02 and SEcalSD02. Moreover, the Si cells in wafers are now forced to
be squared. The Ecal_cells_size parameters is understood as a hint.
Depending on the Ecal_Barrel_halfZ, Ecal_barrel_number_of_towers,
Ecal_lateral_face_thickness and a lot of other parameters, the SEcal03
driver adjust the cell size to have a integer number of identical cells
in theta Z direction. Then, it forces the same value for the X direction.
The same values are used for the end cap slabs.

The new SEcal03 driver fix also another bug, which let to not propagate
correctly the z_begin value for the LCal01 driver.


VII. Improved FieldMap implementation in Field00

FieldMap implementation was changed in class Field00 and thus
the CPU time was reduced by about 2.5 - 3 %.


VIII. New Vertex Detector Geometries

Three new Vertex Detector geometries VXD03, VXD03_sensin and VXD04 are
implemented in this release. These geometries are realistic and flexible
descritpion of :
- 5 layer LDC like vertex detector (VXD03)
- 5 layer LDC like vertex detector with sensors placed at the bottom
of the support ladder (VXD03_sensin)
- 3 double layer GLD like vertex detector (VXD04).

These three geometries are based on the ladder description for LOI decided
by the wordwide VTX community. Nevertheless these geometries are very
flexible thanks to free parameters that can be set in the Mokka steering
file.

The user can change on fly :
- The radius of each layer.
- the 5 layers can be modified for the VXD03 and the
VXD03_sensin geometries
- the 3 double layers radius and the gap between paired layer
for the VXD04 geometry
- The thickess, and the kind of material of the ladder support
- The length, the width and the thickness of the silicon active part
- Presence or not of electronic and the end of the ladder and/or/not
side band structure along the ladder
- thickness and length of the ladder end electronic
- thickness and width of side band structure
- The side band structure can be swicth on as a sensituve part of the
detector
- The VXD is surounded by a cryostat or not.
The optimal number of ladder per layer are calculated automatically when
radius and width of the layer are changed.

The following list give the different parameters that can by modified in
the steering file.

Common parameters for all the VXD geometries :

VXD_support_ladder_thickness
VXD_support_ladder_material

VXD_active_silicon_thickness

VXD_cryostat_option

VXD_side_band_electronics_thickness
VXD_side_band_electronics_width
VXD_side_band_electronics_option

VXD_end_ladd_electronics_option
VXD_end_ladd_electronics_half_length
VXD_end_ladd_electronics_thickness

VXD_active_side_band_electronics_option

Specific parameters for the VXD03 and VXD03_sensin:

VXD_width_r1 (this is the width of the silicton active part)
VXD_width_r2
VXD_width_r3
VXD_width_r4
VXD_width_r5

VXD_length_r1 (this is the length of the silicon active part)
VXD_length_r2
VXD_length_r3
VXD_length_r4
VXD_length_r5

VXD_inner_radius
VXD_radius_r2
VXD_radius_r3
VXD_radius_r4
VXD_outer_radius

Specific parameters for the VXD04 :

VXD_width_r1 (this is the width of the silicton active part)
VXD_width_r3
VXD_width_r5

VXD_length_r1 (this is the length of the silicon active part)
VXD_length_r3
VXD_length_r5

VXD_inner_radius
VXD_radius_r3
VXD_radius_r5

VXD_layer_gap


Furthermore, users have to use the TUBE02 description of the beampipe
because the modification of the inner most layer will modified the radius
of the beampipe. Indeed the inner most most layer is mechanically linked to
the beampipe.
The distance of the inner most layer and the beampipe is fixed at 1 mm. The
use can also modified the beampipe thickness in the steering file using the
parameter : TUBE_central_thickness.


IX. New HCAL superdriver SHcalSc01 and new HCAL sensitive detectors

SHcalSc01 is a new HCAL superdriver containing only the
scintillator option. An additional gap is introduced in the middle of the staves,
in order to get a little bit more realistic description of the detector.
As a consequence, the HCAL layers are divided into 2 halves (in the left and right
side of a stave). The layers have now an aluminium support. There are also 4 pointing
cracks in the endcaps and in the endcaps rings. The Hcal_cells_size is now by default 3.
In the barrel, a special algorithm is applied to deal with fractional cells at the
edges of a layer. The algorithm is applied in the barrel's sensitive detector
(SDHcalBarrel) and takes care that the fractional tiles always have the size
> Hcal_cells_size/2 and < Hcal_cells_size. The endcaps still have integer cells,
with problems at the edges.

New parameters are introduced:
Hcal_chamber_thickness = thickness of the HCAL chambers; default value 6.5 mm
Hcal_layer_support_length = x-length of the HCAL layer support in the barrel;
default value 5 mm
Hcal_layer_air_gap = gap between layer support and scintillator in the HCAL barrel;
default value 2 mm
Hcal_middle_stave_gaps = gap in the middle of the HCAL barrel staves;
default value 3 mm
Hcal_apply_Birks_law =1 apply Birks law to the HCAL scintillator response, =0 do not
apply Birks law; default value 1.
This parameter is given as a parameter to the constructor of
the HCAL sensitive detectors.

New sensitive detector classes:
- SDHcalBarrel: HCAL barrel sensitive detector, contains fractional tile algorithm
and applies Birks attenuation law to the energy deposition, if
Hcal_apply_Birks_law is 1
- SDHcalEndcaps: HCAL endcaps and endcaps rings sensitive detector,
applies Birks attenuation law to the energy deposition, if
Hcal_apply_Birks_law is 1

New class: the G4 class G4EmSaturation was provided by Vladimir IVANTCHENKO (CERN),
and it is used for the Birks law. It should come with the next GEANT4 release. Untill
then, we just keep a copy of it.

A new encoder: Encoder32Hcal was necessary, since we needed an additional bit for
the stave id. The stave id is now 16 instead of 8. An odd stave id (1, 3, ...)
indicates that we have a hit in the left half of a stave, whereas an even stave id
(2, 4, ...) indicates a hit in the right part of a stave. The bits available for the
layer id were also increased by 1, in the idea that somebody would like to go later
to a larger number of HCAL layers (>64), for testing purposes.


X. Improvement of Ecal implementation for TB Cern 2006 models

Independent Y shifts of the 2 Si layers of each slab were implemented in the
new driver Proto04_02. This driver is connected to 2 new DB's
(ProtoCern0806_02 and ProtoCern1006_02) having a new table 'si_layers'
that stores the Y shifts of all layers (maximum allowed shift is +/- 0.2 mm)

Usage within a full TB model:
/Mokka/init/detectorModel TBCern1006_01_dchxy_new
/Mokka/init/EditGeometry/rmSubDetector ProtoCern1006_01
/Mokka/init/EditGeometry/addSubDetector ProtoCern1006_02

Usage of Ecal alone:
/Mokka/init/subDetector ProtoCern0806_02

============================================================ ===================

XI. Bug fix in VTX-Gear interface
The definition of phi0 and offset have been clarified in gear v00-08-02:
phi0: azimuthal angle of (outward pointing) normal of first ladder in layer
offset: shift of every ladder in the direction of increasing phi

modified VXD01.cc, VXD02.cc, VXD03.cc , i.e. also older models will create a
slightly different gear file (phi0 and offset)

-> use gear v00-08-02 or higher for everything to be consistent


============================================================ ===================

XII. New steering command setting the MC Run Number of LCEvent

A new steering command was added to set the Monte Carlo run number
of every LCEvent:

/Mokka/init/mcRunNumber

This is different than the previously created Calice specific command:

/Mokka/init/dataRunNumber

that was aimed to write the number of the Test Beam run corresponding
to the simulation run.


============================================================ ===================
XIII. Bug fix in TrackSummary w/ SimulatorStatus - isCreatedInSimulation

ensure that the bit LCIO::BITisCreatedInSimulation in the SimulatorStatus
is only set if the MCParticle actually has been created in Mokka/geant4


============================================================ ===================

XIV. New digital Hcal implementation

Thanks to Emmanuel Latour, a new implementation of Digital Hcal is
available as sub-detector SHcal04. Only barrel modules are changed,
the EndCaps and EndCapRings are the same as in previous models.
A detailed description can be found at:

http://polzope.in2p3.fr:8081/MOKKA/detector-models/ldc/DHCAL doc.pdf


============================================================ ===================

XV. New SilC drivers

Thanks to Valeri Saveliev, all SI inner track devices have a new
implementation folowing the SilC designs. It concerns the Sit, the
Ftd, the Etd as well the first implementation for the Set device.
It concerns the SSit02, SFtd04, SEtd01 and SSet01 super drivers
which use the sit02, ftd01, etd01 and set01 new basic drivers.
 Topic: Hcal Endcaps and Endcap Rings Gear description in SHcalSc01
Hcal Endcaps and Endcap Rings Gear description in SHcalSc01 [message #1425] Wed, 19 March 2008 10:05
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Hi

today at the optimization meeting it was mentioned that the radii of the endcap and the endcap ring of the new SHcalSc01 are wrong (="too small") in the Gear output file.

Checking the code, I found that the output of Geant and Gear differ. In principle this seems to be alright, since as I understood it the definitions of the radius of Gear and Geant differ: Geant takes the distance from the center to a corner of the octagon as outer radius. Gear takes the distance of the center to the middle of a side of the octagon. So they should differ by a factor of cos(pi/8), which is taken into account.

Bus I found in addition a factor of cos(pi/9) for the Gear output of the outer radius in the code (line 476 for the endcaps and line 945 for the endcap rings in SHcalSc01.cc).

When working on the code, I didn't change this, because this was already present in SHcal03 (on which SHcalSc01 is based) and I guessed that with this code the reconstruction already was successfully tested. In fact, I didn't touch this part at all.
But now I wonder where this factor of cos(pi/9) comes from? For me it doesn't make sense, but maybe I miss something... Confused

Does anybody know where it comes from or if it could be deleted?

Thanks in advance for any tips, hints and/or solutions Smile
Ralf

[Updated on: Wed, 19 March 2008 10:07]

 Topic: New release Mokka-06-05-p02
yes.gif  New release Mokka-06-05-p02 [message #1333] Fri, 21 December 2007 09:05
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Dear friends,

The new Mokka release 6.5p02 is available at the usual address

mokka.in2p3.fr

You should need it if you want to simulate the last LDC base line (V5) and also the LDC', toward a LDC-GLD merging.

Merry christmas !!!

From Release Notes:

I. Ecal, -z endcap hits fixed
II. New parameters in DB for digitilization
III. GEAR interface updates
IV. Ecal plug (or ring around Lcal)
V. New orientation for Ecal slabs in end caps

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.0.p01 and CLHEP 2.0.3.1
LCIO v01-05, v01-06, v01-07, v01-08-01 or v01-09 (recommended),
gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-08

============================================================ ===================

I. Ecal, -z endcap hits fixed

Before fixes, all end cap hits in Ecal were always placed in
+Z end cap. Fixed.

II. New parameters in DB with hints for digitilization

Tree new parameters in Mokka DB with hints for digitilization:
Hcal_digitization_tile_size and TPC_pad_width.
These parameters have no meaning for Simulation,
they are just written in Gear files used by reconstruction processes.

Note: TPC_pad_height is used in the simulation in tpc08 (TPC06.cc)
which creates tracker hits at the meassurement surfaces defined
by the pad rows

III. GEAR interface updates:
- GEAR interface added to LumiCal and LumiCalX drivers. GEAR interface
removed from SLcal01, as that superdriver is using LumiCalX (and thus
the LumiCalX GEAR interface).
- SHcal03 GEAR interface extended to treat the HCAL ring properly.
The new version of this code requires GEAR v00-08 or newer.
- SHcal03 GEAR interface will now use Hcal_digitization_tile_size
to describe the CellSize0 and CellSize1 parameters in the GEAR file,
i.e. those are now 30mm by default instead of 10mm.

IV. Ecal plug (or ring around Lcal)

A new device, the Ecal plug (or the Ecal ring) is built by SEcal02.
It implements a squared-rounded ring around the LCal. The central
cylinder hole follow the Lcal placement, depending on the crossing
angle, and also its size takes in account the new parameter
Ecal_Lcal_ring_gap which defines the distance between the Lcal and
the ring.
It has the same Ecal internal structure. It mean, the same number of
layers, the same thickness and the same Z placement as the end cap
modules, both for the radiator and Si layers. The only difference,
the sensitive Si layer is a flat plate of Si, without any structure
like wafers, guard rings or fiber walls. The cell size is the same as
for the Ecal end caps. The hits from this new device are written in
two new calorimeter hits collections: EcalEndcapRingCollection and
EcalEndcapRingPreShowerCollection.

V. New orientation for Ecal slabs in end caps

The way to place the slabs inside the Ecal end cap modules is now
turned of pi/2, in such way the alveolus are longer than before.
It avoids projective cracks at (0,0,0) plan, but also it's now
possible to configure a correct extra size for the end caps, around
~ 77 mm bigger than the Barrel. The current implementation has to
be reviewed in the future, as it was done a bit quiclky for this
release.
 Topic: Change in model LDC01_05Sc
Change in model LDC01_05Sc [message #1324] Thu, 06 December 2007 08:58
musat
Messages: 57
Registered: February 2004
Dear Mokka users,

A change was made in the composition of model LDC01_05Sc:
sub-detector tpc07 was replaced by the new tpc08 implemented
by Steve Aplin. The change was made in the central DB, so in
order to build model LDC01_05Sc as specified by this central DB,
you'll need to checkout the head of Mokka (containing new driver
tpc06) and re-compile Mokka.

Cheers, Gabriel
 Topic: Mokka MySQL DB down on December 4
Mokka MySQL DB down on December 4 [message #1317] Thu, 29 November 2007 01:57
musat
Messages: 57
Registered: February 2004
Dear friends,

Our central MySQL server, as well as the Mokka CVS repository
will be down on December 4 in the morning, and will be restarted
in the afternoon, the same day.

Please excuse us for the troubles that this may cause.

Cheers, Paulo and Gabriel
 Topic: FR4 material density in Mokka (HCAL)
question.gif  FR4 material density in Mokka (HCAL) [message #1315] Tue, 27 November 2007 03:19
lucaci
Messages: 14
Registered: November 2007
Hello,
it was brought to my attention that there is an inconsistency in the PCB FR4 material density.

In the code of TBhcal05.cc it is stated that the densities are taken from
http://pcba10.ba.infn.it/temp/ddd/ma/materials/list.html
and the FR4 density is set to 1.025g/cm3.

However, in the above mentioned list, there are 3 materials with 'FR4' in the name: NEMA_FR4, M_NEMA FR4 and T_FR4.
Although they all have the same composition, their density differs: 1.025 g/cm3 for the first case, and 1.7 g/cm3 for the last two cases.

Does anybody know an explanation for this?

Regards,
Angela.
 Topic: New release Mokka-06-05
New release Mokka-06-05 [message #1242] Fri, 02 November 2007 08:55
musat
Messages: 57
Registered: February 2004
Dear friends,

The new Mokka release 6.5 is available at the usual address

mokka.in2p3.fr

From Release Notes:

What is new in this Mokka release
=================================

I. Three new Test Beam models for the Cern 2007 experiments
II. New PostConstructAction() method for VSubDetectorDriver
III. New SEcal02 super detector driver
IV. New SHcal03 super detector driver
V. New driver_default_value field in models03.sharing table
VI. New model_status field in models03.model table
VII. Daughter visibility set to false for yoke03 driver
VIII. New steering commands for test beam data information storing
IX. GEAR interface improvements

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.0.p01 and CLHEP 2.0.3.1
LCIO v01-05, v01-06, v01-07 or v01-08-01, gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-06-01

============================================================ ===================

I. Three new Test Beam models for the Cern 2007 experiment

Three new models for the test beam setups of Jully and August 2007
Cern experiments were implemented:

-TBCern07 : theoretical model, with the ideal Ecal - fully instrumented
-TBCern0707 : Ecal with all slabs present, but the bottom front 6
-TBCern0807 : Ecal with all slabs present, but the bottom front 3,
with the remaining 3 alveolae instrumented with the 'fake'
tungsten slabs

I. a) Thanks to Fabrizio Salvatore, we have new drivers for beam detectors
in the 2007 test beam models (in the following, a brief description of
the changes with respect to the 2006 test beam models are given):

- Cerenkov detector: no changes wrt TB06 model
- Drift chambers: no changes wrt TB06 model
- Scintillators: only 3 scintillators on the beam line (2 10x10cm2
beam trigger and (one 20x20cm2 for muon trigger)
- Veto: added on the beam line a 100x100cm2 scintillator, with a
20x20cm2 hole in the centre, corresponding to the position of
the 20x20cm2 scintillator.
- muon chambers: only one muon chamber is simulated, at the back of
the TCMT

I b) Thanks to Guilherme Lima, we have a new implementation of the TCMT:

- new feature: staggering of the sensitive TCMT layers, cf.
the prototype used at CERN in July-August 2007.
- The sizes of the TCMT absorbers have been enlarged, for a
better match to the real dimensions.

I c) Thanks to Oliver Wendt, a new version of the Hcal is available, with
the following features:

1. Rotation and Staggering of the CALICE analog HCAL

With this release it is possible to rotate and stagger the analog HCAL
in the models TBCern07, TBCern0707 and TBCern0807. This is done to
simulate non perpendicular beam incidence. The rotation and staggering
can be choosen by the detector setup, e.g. TB30 for a rotation of 30
degrees. Additionally, it is possible to rotate the HCAL as a bulk
with the global model parameter HcalRotationAngle. This is done to
handle misalignments.

2. Position and Number of Layers for the CALICE analog HCAL

The number of layers is set to 38 for the detector models TBCern07,
TBCern0707 and TBCern0807. Additionally, the position of the analog
HCAL is adjusted to reflect the situation during data taking in 2007
at CERN.


II. New PostConstructAction() method for VSubDetectorDriver

Super drivers (drivers which are able to scale) which would
not need to create temporary databases on the fly (not
really using old detector drivers) should be able to
propagate the geometry scaling results for subsequent
drivers being built. To provide this functionality, a new
virtual method is added to the VSubDetectorDriver
abstract interface:

virtual G4bool
PostConstructAction(CGAGeometryEnvironment&);

This method is called after the sub-detector construction
and the CGAGeometryEnvironment object passed as parameter
is bypassed for the next drivers. By default it returns true.


VIII. New steering commands for test beam data information storing

Two new steering commands were added that allow users of test beam
simulation to store in the LCIO run header the DataRunNumber and the
DataConfiguration of the data run corresponding to the simulation
run:

/Mokka/init/confDataTag
/Mokka/init/dataRunNumber

III. New SEcal02 super detector driver

This new super driver is part of the new LDC baseline
being built. In this new Ecal implementation, the sensitive
Si are build as wafers placed in towers (3 wafers per alveolus),
so it could be useful for people studding the resolution
degradation created by the fiber gaps and guard rings. The
endcaps are better implemented avoiding booleans, so it should
be faster at run time.
A complete documentation will be provided for the next release.


IV. New SHcal03 super detector driver

This new super driver is part of the new LDC baseline
being built. This new Hcal implementationit's almost the same as
before, but with just 3 modules in the barrel stave and the rings
plugged on the end caps.
A complete documentation will be provided for the next release.

V. New driver_default_value field in models03.sharing table

As new super drivers often reuse old parameters shared by
previous super drivers, but with a new value as default, the
new field driver_default_value was created for the
models03.sharing table. If this field is not equal to NULL,
the actual value overwrites the old one in the database;
otherwise the parameter takes the old default value.

VI. New model_status field in models03.model table

As new models can be unstable for a while, the time to
put all pieces together and tune the parameters, the new
field model_status in models03.model table can now be used
to flag it. For the moment this field can receive the values
'frozen', for models good for production, or 'unstable',
for models being developed. In the future this field will
be also useful to flag obsolete models, which are no more
supported by Mokka.

For the moment, if a model is not frozen, the user is
warmed about there isn't any warring concerning the stability
of the simulation results.

VII. Daughter visibility set to false for yoke03 driver

To display all muon chambers installed inside the yoke take a
lot of time. To provide a faster display for models using this
geometry driver, the daughter visibility are now set to
false for all the vis attributes of its main volumes.

IX. GEAR interface improvements

All HCAL drivers write an additional parameter
Hcal_virtual_cell_size, which is required by the MokkaCaloDigi
processor in MarlinReco. By default, this virtual cell size is set
to the actual cell size of the HCAL.
The pad height in TPC drivers tpc00-tpc03 is now rounded off to
the next smallest micron. This is needed to avoid problems in Marlin,
where due to rounding errors the number of pad rows times the pad height
was seen to extend slightly beyond the actual pad area.
 Topic: Muon System in the Geometry Tree
Muon System in the Geometry Tree [message #1121] Thu, 20 September 2007 01:29
vogel
Messages: 83
Registered: March 2005
Location: DESY, Hamburg, Germany
Hi all,

I just tried the command /Mokka/Visu/Detector/ListGeometryTree with a detector model which contains the new instrumented yoke and I saw that an excessive amount of entries is generated by the yoke (80% of all ~4000 entries).

This looks like the new yoke geometry could need some cleanup (maybe a better usage of mother and daughter volumes, or even replicated volumes?). Besides, it would be nice to have some G4VisAttributes attached to the pieces of the muon system so that they don't show up in plain white.

Cheers,
Adrian
 Topic: vxd01 vs. vxd02
vxd01 vs. vxd02 [message #1075] Fri, 07 September 2007 00:10
hooberman
Messages: 13
Registered: March 2007
What is the difference between vxd01 and vxd02? I thought that LDC00_02Sc had the realistic vertex tracker, but it includes vxd01 by default and I just read that the realistic version is vxd02. To use this geometry with the realistic VTX, must I swap out the vxd01 and replace it with vxd02?

Ben Hooberman
 Topic: New patch 02 to Mokka release 06-04
New patch 02 to Mokka release 06-04 [message #1055] Thu, 06 September 2007 09:08
musat
Messages: 57
Registered: February 2004
Dear friends,

A new Mokka patch mokka-06-04-patch02 is available at

mokka.in2p3.fr

From release notes:

============================================================ ===
What is new in this Mokka release
=================================

I. Fixing the particle charge in MCParticleList for primaries
not tracked.
II. Fixing memory leak when skipping events in stdhep
input files.
III. Bug fixes in scintillators' drivers for Desy and CERN TB models
IV. Adding a GEAR interface to many more detector drivers.
V. Adding new Geant4 physics lists

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.0.p01 and CLHEP 2.0.3.1
LCIO v01-05, v01-06, v01-07 or v01-08-01, gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-06-01

============================================================ ===================

I. Fixing the particle charge in MCParticleList for primaries
not tracked.

Before this patch, all primaries in event file with generator
code > 2 and all particles not tracked by Mokka had the charge
in MCParticleList collection set to zero (not initialized).

With this patch, all known particle in physics list have the
charge information in the MCParticleList collection set
correctly. The unknown particles in the actual physics
list have the charge set to -1000 (a not physical value).

Many thanks to Erik Devetak signaling the problem and helping
to fix it.

II. Fixing memory leak when skipping events in stdhep
input files.

Before this fix, skipping events in stdhep input files
have let to memory leak. For big event files Mokka could
crashes with the runtime error "bad_alloc" (no more memory
available. It's fixed with this patch. Many thanks to Dennis
Martsch for signaling this bug in the Mokka issues tracker
at mokka.in2p3.fr.

III. Bug fixes in scintillators' drivers for Desy and CERN TB models

Before this fix, an error message was printed when Mokka was
built in 'debug' mode. The problem was in the indexing of the
hits in the scintillators.

IV. Adding a GEAR interface to many more detector drivers.

If Mokka is compiled with active GEAR interface, an xml file
with a description of the detector geometry is created. The
information to be put into this xml file needs to be provided
by each individual subdetector driver. Previous versions of Mokka
only had a small number of drivers with GEAR interface; this has
now been extended to cover almost all Tesla and LDC models.
Some details of the xml format were changed (for example the
specification of the magnetic field was moved from the TPC parameter
set into its own global section). Versions of MarlinReco newer
than v00-04 are expected to support this new format. MarlinReco
versions up to (and including) v00-04 will need minor manual
editing of the xml file created by this new Mokka release.

V. Adding new Geant4 physics lists

New physics lists that became available with the recent releases of
Geant4 were added to Mokka PhysicsListFactory:

FTFP_EMV, QBBC, QGSP_BERT_EMV, QGSP_BERT_NQE, QGSP_EMV_NQE,
QGSP_EMX, and QGSP_NQE
 Topic: Mokka Web site and anoncvs
Mokka Web site and anoncvs [message #1017] Tue, 28 August 2007 04:58
musat
Messages: 57
Registered: February 2004
Dear friends,

We are glad to announce that Mokka Web site is now accessible
at the adress mokka.in2p3.fr and that we now have available
an anonymous cvs access to the repository. The CVSROOT should be
set as follows:

export CVSROOT=:pserver:anoncvs@pollin1.in2p3.fr:/home/flc/cvs

(under bash shell)

For security reasons, we set a passwd for it:

%ilc%

Cheers, Paulo and Gabriel

 Topic: New patch 01 for Mokka release 06-04
icon7.gif  New patch 01 for Mokka release 06-04 [message #963] Wed, 11 July 2007 06:39
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Dear friends,

Thanks to Gabriel, a new patch for the Mokka release 6.4 is available, the mokka-06-04-p01, for download at

http://polywww.in2p3.fr:8081/MOKKA/

Cheers, Paulo.

===================================================

From Release Notes:

What is new in this Mokka release
=================================

It's just a patch to get Mokka compliant with geant4 9.0 :

- The global constant "kCarTolerance" is replaced by
G4GeometryTolerance::GetInstance()->GetSurfaceTolerance()

- New physics lists available

- Dropped patches to Geant4 classes G4NistElementBuilder
and G4RunManager

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 9.0 and CLHEP 2.0.3.1
LCIO v01-05, v01-06, v01-07 or v01-08-01, gcc 3.2.3, gcc 3.4.5
or gcc 4.1.1, SL3 or SL4, optionally with Gear v00-04

============================================================ ===================
 Topic: average dE/dx of a mip
average dE/dx of a mip [message #962] Tue, 10 July 2007 22:55
harderk
Messages: 42
Registered: March 2004
Location: RAL
Does anybody know whether Geant4 provides the minimum dE/dx of a mip in a specific material? The energy loss tables contain the dE/dx in bins of momentum, so we would have to search for the minimum ourselves.
 Topic: GEANT4/Mokka needs -fno-strict-aliasing compiler flag
GEANT4/Mokka needs -fno-strict-aliasing compiler flag [message #926] Wed, 20 June 2007 08:12
samson
Messages: 13
Registered: March 2006
Location: DESY, Hamburg
Hi,
during the try to compile a working Mokka on a SL4 machine, Adrian and I were stopped by the known "TrackSummary/G4Allocator" related problem that Mokka has when compiling with gcc versions later than 3.2.3 (cf. Problems with Mokka 4.0 at DESY [message #215]).

It turned out, that the "-fstrict-aliasing" optimisation, which is enabled by default when using "-O2" breaks the the code of the TrackSummary destructor in conjunction with the inlined and overloaded G4Allocator version of the delete operator. In all my tests the "TrackSummary bug" could be averted by setting the "-fno-strict-aliasing" flag.

The reason why this bug has not been seen on every system might be the fact that on some systems the mysql_config tool might silently have introduced this flag if you don't specify the path to your MySQL installation:
$ mysql_config --cflags
-I/usr/include/mysql -g -pipe -m32 -march=i386 \
-mtune=pentium4 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 \
-D_LARGEFILE_SOURCE -fno-strict-aliasing

is the output of mysql_config on a SLD4 system.

Since the broken code is related to the memory management, this might also be the reason for some memory leaks.

I think, that -fno-strict-aliasing must become a default flag for all Mokka object files, since the way to allocate memory with the G4Allocator is not unique to the TrackSummary class.

Although it is likely, that GEANT4 violates the C++ aliasing rules (there are many strange pointer conversions in the inlined G4Allocator code), I am not 100% sure, that the reason for breaking the code is not caused by an bug in the compiler. However, I could reproduce and verify the bug with gcc 3.3.3, gcc 3.4.6, and gcc 4.1.0. The fact that using G4Allocator, in the way Mokka does, leads to broken code (even if it does not always cause crashes) with various versions of gcc should be enough to ask the GEANT4 people to set -fno-strict-aliasing already int the GEANT4 make files.

Cheers, Jörgen.
 Topic: Mokka Web Site
Mokka Web Site [message #879] Tue, 29 May 2007 07:28
musat
Messages: 57
Registered: February 2004
Dear friends,

The Web site of Mokka is down since about 10 days ago.
Due to an electrical power maintenance, our servers were
shut down, and we had problems when trying to restart the Web
server. Our system engineers are doing their best to restore
the site.

Please excuse us for the problems that this caused.

Cheers, Gabriel
 Topic: About patch 02 to Mokka 6.3
About patch 02 to Mokka 6.3 [message #789] Fri, 13 April 2007 05:53
musat
Messages: 57
Registered: February 2004
Dear friends,

After having done some tests with the TB models, two problems appeared:

1. The rotation of the Ecal and Hcal is in opposite directions:
a positive rotation angle makes the Ecal rotate clockwise
(like in the real setup), but it makes the Hcal rotate
counterclockwise (in the mathematically positive direction).
It was decided that we adopt the convention of the Ecal
rotation for both calorimeters and make that available in the
future release.

2. The TCMT reads the value of the TCMTRotationAngle parameter
that one specifies in the steering file, but further away in the
code of the TCMT driver, the angle is hardcoded to zero.
After having exchanged some e-mails among people involved
in the TB implementation, it seems that the TCMT rotation is
not a crucial point for the moment (it would account only
for missalignments, but hardcoding it to zero would have
a small impact on the TCMT precision), and that in the future
we'll make it available if necessary.

Please excuse us for the problems that all these might cause you.

Cheers, Gabriel
 Topic: New Patch 02 to Mokka release 06-03
New Patch 02 to Mokka release 06-03 [message #786] Wed, 11 April 2007 06:51
musat
Messages: 57
Registered: February 2004
Dear friends,

A new tag was made that is mainly aimed to allow Calice collaboration to run Test Beam simulation and compare to real data.

From Release Notes:

What is new in this second patch to Mokka release 6.3
=================================

I. Implementation of separate rotation and X and Y translation of the Calice
Hcal and TCMT prototypes.
II. Implementation of Drift Chambers with separate X and Y sensitivity
for the Desy May 2006 setups.
III. Implementation of drift chambers having a unified hit collection
for the 2006 setups. Renaming of 2006 DCH's.
IV. New steering command for initializing the seed of the random engine.

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 8.1 patch 02 and CLHEP 2.0.2.3
LCIO v01-05, v01-06, v01-07 or v01-08-01, gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-04

============================================================ ===================

I. Implementation of separate rotation and X and Y translation of the Calice
Hcal and TCMT prototypes

The separate Rotation and X and Y translations for the Hcal prototype (driver
TBhcal05_01) and for the TCMT (driver TBcatcher05_01) were implemented. There
are three new "global model parameters" for each of these drivers that one
can change in the steering file with the following commands:

/Mokka/init/globalModelParameter HcalTranslateX -20.0
/Mokka/init/globalModelParameter HcalTranslateY 500.0
/Mokka/init/globalModelParameter HcalRotationAngle 12.5

/Mokka/init/globalModelParameter TCMTTranslateX -20.0
/Mokka/init/globalModelParameter TCMTTranslateY 500.0
/Mokka/init/globalModelParameter TCMTRotationAngle 12.5

Please note that the parameters "HcalRotationAngle" and "TCMTRotationAngle"
should be used to set the rotation, instead of the previous parameter
"configuration_angle" that was used by the old models to set the overall
configuration angle of all detectors. This old parameter still exists in the
DB in order to allow users of previous models to set the angle.


II. Implementation of Drift Chambers with separate X and Y sensitivity
for the Desy May 2006 setups.

For the Desy tb, the 'real' drift chambers give a separate measurement of
the X and Y position of the hits: in particular, the first half of each
chamber (along the beam axis) gives the position of the hits in X and the
second half gives the Y position. In Mokka v06-03p01 the chambers are
simulated with a single gas volume and therefore the generated hits have
an (X,Y,Z) position at each point of the chamber. In order to make the
simulation as close as possible to the reality, Fabrizio re-wrote the
drivers for the Desy chambers in such a way that each chamber is now made
of 2 separate (but contiguous) gas volumes (of the same gas type, mixture,
pressure and temperature). In total the gas volumes are therefore 8
(2xchambers).

The folowing new models were implemented, with a separate X and Y
sensitivity of Drift Chambers:

- TBDesy0506_dchxy: same as TBDesy0506 but with DCH's having separate
X and Y sensitivity (8 hits collections)

- TBDesy0506_01_dchxy: same as TBDesy0506_01 but with separate X and Y
sensitivity of the DCH's (8 hits collections)



III. Implementation of drift chambers having a unified hit collection
for the 2006 setups. Renaming of 2006 DCH's.

One more improvement of 2006 TB models done by Fabrizio is regarding the
collections of hits for both Desy and Cern. Since the number of drift
chambers available at Desy and Cern (and possibly at Fnal later on) is
different, having one collection of hits per chamber in the MC (so 4
collections at Desy, 3 at Cern, XX at Fnal) could be a problem when the
hits are later digitized in the reconstruction. Therefore in the new
drivers for the Desy tb and Cern tb there is now only one collection of
hits that 'collects' all the hits from all the chambers and the chamber
(or volme, in the Desy case) that corresponds to a given hit is identified
by the parameter cellID in the SimTrackerHit collection. For Desy the
cellID map is the following:

DC1 -> layer 0 (X), 1 (Y)
DC2 -> layer 2 (X), 3 (Y)
DC3 -> layer 4 (X), 5 (Y)
DC4 -> layer 6 (X), 7 (Y)

For facilitating the digitization and the tracking, DC1 and DC2 at Desy and
DC3 and DC1 at Cern have been swapped, so that DC1 is always the one
closer to the Ecal (and then 2, 3, (4) are those further and further away
from it).

The folowing new models were defined in the DB:

- TBDesy0506_dchxy_new: same as TBDesy0506_dchxy but with only one hits
collection in the DCH's
- TBDesy0506_01_dchxy_new: same as TBDesy0506_01_dchxy but with only one
hits collection in the DCH's

- TBCern0806_dchxy_new: same as TBCern0806 but only one hits collection
in the DCH's
- TBCern0806_01_dchxy_new: same as TBCern0806_01 but only one hits
collection in the DCH's

- TBCern1006_dchxy_new: same as TBCern1006 but only one hits collection
in the DCH's
- TBCern1006_01_dchxy_new: same as TBCern1006_01 but only one hits
collection in the DCH's


IV. New steering command for initializing the seed of the random engine.

A new steering command was added to allow initialization of the random
engine with a single seed:

/Mokka/init/randomSeed 12345

Geant4 provides an alternate way that can be used to initialize the random
engine by specifying a whole state in a file and then passing it to the
Geant4/CLHEP random number generator.

 Topic: New Patch 01 to Mokkla release 6.3
New Patch 01 to Mokkla release 6.3 [message #757] Fri, 02 March 2007 06:51
musat
Messages: 57
Registered: February 2004
Dear Friends,

In order to facilitate the usage of new Test Beam models and the
analysis of MC and comparison with data, a public patch is now
available - Mokka-06-03-p01 - at the Mokka web pages

mokka.in2p3.fr.

From the Patch Notes:

New tag mokka-06-03-p01
===================

I. Implementation of separate rotation and X and Y translation
of the Calice Ecal prototype
II. Removed X and Y translation of Test Beam upstream detectors

============================================================ ===================

Please note that:

1. This Mokka release co-works with Geant4 8.1 patch 02 and CLHEP 2.0.2.3
LCIO v01-05, v01-06, v01-07 or v01-08-01, gcc 3.2.3, gcc 3.4.5 or
gcc 4.1.1, SL3 or SL4, optionally with Gear v00-03

2. Due to the new definition of the materials, it doesn't work with
Geant4 releases older than 8.1 any more.

============================================================ ===================

I. Implementation of separate rotation and X and Y translation of the Calice
Ecal prototype


The separate Rotation and X and Y translations for the Ecal prototype (driver
proto04_01) were implemented. There are three new "global model parameters"
that one can change in the steering file with the following commands:

/Mokka/init/globalModelParameter EcalTranslateX -20.0
/Mokka/init/globalModelParameter EcalTranslateY 500.0

/Mokka/init/globalModelParameter EcalRotationAngle 12.5

Please note that the parameter "EcalRotationAngle" becomes the one that
should be used to set the rotation, instead of the previous parameter
"configuration_angle" that was used by the old models to set the overall
configuration angle of all detectors. This old parameter still exists in the
DB in order to allow users of previous models to set the angle.


II. Removed X and Y translation of Test Beam upstream detectors

According to the new coordinate system, the beam is kept fixed, so there is
no need for the upstream detectors to translate. The global model
parameters TranslateX and TranslateY are no longer read by the upstream
detector drivers.
 Topic: Mokka and gcc versions
Mokka and gcc versions [message #662] Fri, 26 January 2007 08:53
musat
Messages: 57
Registered: February 2004
Dear friends,

It was noticed by many of you that Mokka didn't work with gcc
release 3.3.3, and some of you expressed worries that it could be
due to a bug in Mokka that would prevent Mokka from working with
more recent gcc versions too.

I had the time to test Mokka with gcc 3.4.5 and with the last
version 4.1.1 and it works. I compiled all software (CLHEP, G4
and Mokka) with each of these versions of gcc and I could process
several events and several runs without problems.

So perhaps the problem came rather from the version 3.3.3 of gcc.

Since the last public release (8.2) of G4 was tested with gcc
4.1.1, perhaps for the next Mokka release we should adopt it
as the tested gcc version for Mokka too.

What do you think about that?

Cheers, Gabriel
 Topic: New release Mokka 6.2 available for download
New release Mokka 6.2 available for download [message #641] Fri, 01 December 2006 07:11
musat
Messages: 57
Registered: February 2004
Dear Fiends,

The new Mokka release 6.2 is available for download. This release
brings several Mokka improvements, but also the test beam models:

* TBDesy0506 : complete and checked. Ecal modules and slabs
have the right X shifts.

* TBCern0806 : complete, with the corrected position of the
Hcal. The tail catcher (work in progress) should in the
future correct its position w.r.t. the Hcal if the
configuration angle is not equal to zero.

* TBCern1006 : complete but not checked yet.

Please not that the TB models TBDesy0506, TBCern0806 and
TBCern1006 now use a new driver ("proto04") for the Calice Ecal,
so in order to run these models one needs to download this new
Mokka release.


From the Release Notes:

============================================================ ===

New tag mokka-06-02
===================

What is new in this Mokka release
=================================

I. SEcal with three different sets of radiator thickness
II. Running Mokka in Batch Mode
III. New Plugins for Mokka
IV. Revised Makefiles to Locate MySQL Headers and Libraries
V. Improved Error Handling for MySQL NULL Values
VI. Usage of getopt(3) to Parse the Command Line
VII. Change in the MokkaGear Output for the TPC
VIII. Added MokkaGear Output for Vertex (VXD00+VXD01)
IX. New drift chambers and scintillator drivers for the
DESY and CERN test beams
X. Improved Material Descriptions
XI. Fix of a Memeory Leak in the Visualisation
XII. New TPC driver
XIII. New yoke-muon driver
XIV. Updates to the Tail Catcher geometry (for Cern TB)
XV. Switchable sensitive cassettes in the CALICE analog HCAL geometry
XVI. Configuration angle of the CALICE analog HCAL for the Cern 2006
test beams
XVII. Position of the CALICE analog HCAL
XVIII. Layers in the sensitive cassette of the CALICE analog HCAL
XIX. Composition of the absorber material in the CALICE analog HCAL
XX. New driver "proto04" with the right X shifts of the modules of the
CALICE Ecal

============================================================ ========

Please note that:

1. This Mokka release co-works with Geant4 8.1 and CLHEP 2.0.2.3
LCIO v01-05, v01-06 or v01-07, gcc 3.2.3 or gcc 3.4.5, SL3 or SL4,
optionally with Gear v00-03

Due to the new definition of the materials, it doesn't
work any more with Geant4 releases older than 8.1.

============================================================ ========

I. SEcal with three different sets of radiator thickness

To help studying new possibilities, the SEcal01 super driver is now able to
build the Ecal modules with three different thicknesses for the radiator
layers. For that two new database parameters were introduced in this release:

Ecal_nlayers3: Number of layers for the last set of layers
(near Hcal) for the Ecal;
Ecal_radiator_layers_set3_thickness: Ecal radiator thickness of
the last Ecal_nlayers3 layers.

Both parameters are set to zero, as the standard models use just two
different sets of radiator thickness for the Ecal.


II. Running Mokka in Batch Mode

Thanks to the new init command

/Mokka/init/BatchMode true

the users can now launch Mokka in batch mode, without an interactive session.
If BatchMode is set in the given steering file Mokka executes just a given
macro file, if any, and exits.


III. New Plugins for Mokka

Two new plugins have been added to the Mokka release. Please see the files

Mokka/source/Plugin/JDoePlugin/Readme
Mokka/source/Plugin/RandomPlugin/Readme

for more information.


IV. Revised Makefiles to Locate MySQL Headers and Libraries

As recently discussed on the Linear Collider Forum, the Mokka makefiles have
been slightly modified to allow for a greater flexibility when locating MySQL
header files and libraries. There are now four ways to determine the location
of MySQL-related files (with upper items having precedence over lower items):

1. Use MYSQL_INCLUDEDIR and MYSQL_LIBDIR, if defined
2. Use MYSQL_PATH, if defined
3. Use the "mysql_config" tool, if known to the shell (i.e. in the PATH)
4. Use "/usr/lib/mysql" and "/usr/include/mysql" as a default

The first possibility should be used only for special applications - be sure
you know what you're doing when you make use of this. The header file
"mysql.h" must be located in the directory "${MYSQL_INCLUDEDIR}" and the
library "libmysqlclient.{a,so}" must be located in "${MYSQL_LIBDIR}". Beware
of version mismatches and other evil things.

The second corresponds to the behaviour of previous Mokka versions, except
for the difference that the makefiles will now be able to handle both binary
and source distributions of MySQL. (The former will usually have header files
and libraries located in "${MYSQL_PATH}/include" and "${MYSQL_PATH}/lib",
respectively; the latter will have them in "${MYSQL_PATH}/include/mysql" and
"${MYSQL_PATH}/lib/mysql".)

The third option is the easiest, most flexible and cleanest - you simply have
to make sure that the "mysql_config" utility is reachable through your PATH.
You should find it in the "bin" directory of your MySQL installation.
Unfortunately it has been reported that the Windoze version of "mysql_config"
currently has a bug.

The last alternative requires no intervention by the user whatsoever. It can
be used if MySQL is installed in the default system directories.

For further information, please see:

http://forum.linearcollider.org/index.php?t=tree&th=227
http://dev.mysql.com/doc/refman/5.0/en/installation-layouts. html
http://dev.mysql.com/doc/refman/5.0/en/mysql-config.html


V. Improved Error Handling for MySQL NULL Values

The methods "Database::fetchDouble", "fetchInt", and "fetchString" will now
abort with a meaningful error message when they encounter an unexpected MySQL
NULL value instead of just crashing with a segmentation fault.

If you intend to make use of NULL entries in the database, you can check for
them by testing the return value of "Database::getTuple" (yes, there is one).

db->exec("SELECT `a`, `b`, `c` FROM `foo`.`bar`;");
char **tuple = db->getTuple();
if (tuple[1]) { // field `b` has an entry
const double b = db->fetchDouble("b");
/* do something with b */
} else { // field `b` is NULL
/* do something else without b */
}


VI. Usage of getopt(3) to Parse the Command Line

The handling of command line options and parameters has been slightly
revised. Mokka now uses the library function "getopt" (from <unistd.h>) to
parse the command line for options, their arguments, and other parameters.
The changes for the user are minimal:

* The help message can be displayed with the option "-H". The question mark
is reserved when using "getopt", and "-h" is already assigned to the
selection of the MySQL host to which Mokka should connect.

* Arguments of options can immediately follow the option character without
a separating space.

* Options without arguments (plus the next option with an argument) can be
concatenated after one single minus sign.

* You can use command line options together with a steering file. If a
steering file is given, its settings will override the settings which
were made on the command line. However, you cannot have more than one
steering file at a time.

* As a consequence, there is finally the possibility to have steering files
with names which begin with a minus sign. Just put "--" in front to
indicate that everything which follows is not a command line option.


VII. Change in the MokkaGear Output for the TPC

The MokkaGear output of the TPC drivers has been modified: The pad width and
the pad height are now set to the default values of 2 and 6, respectively.

Even though the recent TPC drivers make no assumption about the size of the
readout pads whatsoever, Gear cannot store a dummy value such as zero.
Therefore, the Gear information may be meaningless and should be treated with
care.


VIII. Added MokkaGear Output for Vertex (VXD00+VXD01)

This requires Gear v00-03. Writes Gear description for the vertex detector(s)
based on a ladder layout. (Note: for the old simplified model VXD00,
36 ladders are written out to approximate the cylidrical shape.)


IX. New drift chambers and scintillator drivers for the DESY and CERN test beams

* DESY test beam: new driver for the Drift Chambers, that were setup to run
with 96% Ar and 4% Ethane to avoid exposive gas mixture; hits are defined
as 'tracker' hits.
New drivers to define 3 scintillators (2 trigger, one veto) and 2 finger
counters (used for monitoring the beam position); hits are defined as
'calorimeter' hits.

* CERN test beam: the drivers for the folowing detectors on the beam line
have been added to the simulation:
Cerenkov detector (11m long, helium gas, only material is simulated -
no sensitive detector);
3 drift chambers (gas mixture 50% Ar - 50% C02, hits generated as 'tracker' hits);
4 scintillators (3 trigger scintillators and one veto counter, hits generated
as 'calorimeter' hits);
2 muon counters (hits generated as'calorimeter' hits) (note: in the Oct06 tb model
only 1 muon counter is present).

* Desy 05 test beam: for consistency, the hits in the scintillators are defined
as calorimeter hits, as for the above models.

X. Improved Material Descriptions

The element and material definitions for the overall detector construction
have been improved: Instead of using self-cooked elements and materials, the
CGAGeometryManager now takes advantage the rather precise and comprehensive
definitions (including the natural isotope composition for all elements)
which are provided by the G4NistManager wherever possible. In your own code,
you can use the methods

static G4Material *CGAGeometryManager::GetMaterial(const G4String &name)
static G4Element *CGAGeometryManager::GetElement(const G4String &name)

to access these definitions. See the files

$G4INSTALL/source/materials/src/G4NistMaterialBuilder.cc
$G4INSTALL/source/materials/src/G4NistElementBuilder.cc

or the user interface commands in the "/material/" directory for details.
Further definitions for materials which are not predefined by the
G4NistManager and a few alias names (for backward compatibility with the
existing Mokka geometry drivers) can be found in the database "materials02",
which has now become the default materials database.


XI. Fix of a Memeory Leak in the Visualisation

A memory leak related to the visualisation of tracks has been fixed. (With
the release of Mokka version 05-04 (and Geant4.Cool, the drawing of tracks was
disabled by default in order to circumvent the problem.)

The leak was caused by the internal handling of G4VisAttributes in Geant4 and
is currently being looked after by the Geant4 group.


XII. New TPC driver

A new TPC geometry driver named "tpc05" has been implemented. It inherits all
the features introduced in previous driver (tpc04).

New features are :
- Cathode plane in more detail - carbon support plus copper metalization,
total thickness of dead layer at 90degrees has increased to 5mm in total !
- Readout plane has not changed in structure only some of dimensions were
adjusted plus the remaining space after the gem tower is filled with
"electronics". It will now give a X0 of about 0.3 for default size
(endplate region of 160mm).
- Hit at each step approach was kept but TPC volume was divided into two
collections, TPCCollection and TPC_skinCollection (2.0cm thick volume on
the outer edge of TPC). With modification of the

/Mokka/init/lcioDetailedTRKHitMode

command that is now working with collections! and not with drivers it is
possible to have momentum information in this region (enough for having
the exact momentum on entry and exit of the TPC active volume) without the
overhead of storing the momentum at each hit.
If this is desired option the stearing file should contain following line

/Mokka/init/lcioDetailedTRKHitMode TPC_skinCollection

for momentum at each hit in TPC one should have

/Mokka/init/lcioDetailedTRKHitMode TPCCollection
/Mokka/init/lcioDetailedTRKHitMode TPC_skinCollection

plus a command for each silicon detector collection if needed.


XIII. New yoke-muon driver

New driver "yoke03" integrates in it self the yoke and the muon detector. It
inherits the caracteristics of yoke02 with some changes:

- additional parameter Yoke_with_plug decides should there be the plug or not
(it must be true for LDC00_xx (TESLA) series othervise there will be a gap in
geometry)

- if the plug is ON, it will have 5 active rpc layers of the same structure as
for the muon system equally distributed along the length of plug. Hits will
be in MuonPlugCollection.

- for design accuracy barrel was shorten and the endcap has full radius.

- muon system was implemented as a set of rpc layers. yoke is segmented in
the proposed way 100mm of iron + 40mm of air. in the air gap the rpc
structure from table is then filled in. first n layers are inside of the
iron and the last is on the surfice of the yoke. There are two collections
MuonBarrel and MuonEndCapCollection.

- hits are stored in cells of 30mm x 30mm (the number should be choosen
to be equivalent to expected position resolution) size and are of
SimCalorimeterHit type.

- all the numbers in the yoke03 tables can be changed without any problem
as long there is enough space to put the rpc structure in air gap and
enough thickness of iron to placne n-layers. If this is not true program
will abort with hint to check the geometry.


XIV. Updates to the Tail Catcher geometry (for Cern TB)

Updates to the Tail Catcher geometry, as installed
for the Cern test beam (Aug.2006):

- add air-filled gaps before and after TCMT cassettes
- MySQL DB: update absorber thicknesses and air gaps
as measured in the real setup.


XV. Switchable sensitive cassettes in the CALICE analog HCAL geometry

All scintillator cassettes in the CALICE analog HCAL are individually switchable with the
global model parameter HCALLayerPattern. To do so just add the following line in the
steering file: /Mokka/init/globalModelParameter HCALLayerPattern 1111...11
With a character '1' in the first position of this pattern a scintillator layer is build
at the first position of the geometry model. With a '1' at the second position a
scintillator layer is build at the second position and so on. If the character '0' is set
at any position of the pattern a volume of air with the size of the scintillator cassettes
is created at the corresponding position.
The lenght of the pattern 1111...11 needs to be exactely as long as the number of layers
defined in database (e.g. 38).


XVI. Configuration angle of the CALICE analog HCAL for the Cern 2006 test beams

The configuration angle of the CALICE analog HCAL for the Cern 2006 test beams is
set to 0.0 degrees.


XVII. Position of the CALICE analog HCAL

The position of the HCAL can be adjusted by the parameters x_begin, y_begin and z_begin
defined in the database of the geometry driver. These coordiantes are given with respect
to the outer surface of the last layer of the ECAL (standard coordinate system).


XVIII. Layers in the sensitive cassette of the CALICE analog HCAL

The order of layers in the sensitive cassettes of the CALICE analog HCAL is swapped due
to the assembly of the HCAL at the Cern test beam studies 2006.


XIX. Composition of the absorber material in the CALICE analog HCAL

The composition of the absorber material in the CALICE analog HCAL has been changed from
iron (99.8%mass) + graphite (0.2%mass) to iron (98.43%mass) + manganese (1.4%mass) +
graphite (0.17%mass). The type of the steel is S235JR.


XX. New driver "proto04" with the right X shifts of the modules of the
CALICE Ecal

The X shifts of the modules of the CALICE Ecal were changed according to the
setups of the DESY and CERN Test Beams of 2006: the central module (or
module #2) is fixed, and the modules 1 (1.4 mm Tungsten) and 3 (4.2 mm
tungsten) are shifted in opposite directions parallel to the X axis. The
values of the shifts depend on the configuration angle, and are the ideal
values used for the Ecal design. These changes in the Ecal configuration
are part of the new driver "proto04".
 Topic: Mokka download page
warning.gif  Mokka download page [message #634] Thu, 02 November 2006 00:46
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Dear all,

I forgot to say that all Mokka releases, also the last prerelease 06-02-pre02, are available for download from the Mokka Web page, address “mokka.in2p3.fr”, just following the “Download Mokka” link on the home page. The direct address is for the download page is

http://polywww.in2p3.fr:8081/MOKKA/download/download

Sorry, Paulo.
 Topic: Mokka prerelease mokka-06-02-pre02
icon14.gif  Mokka prerelease mokka-06-02-pre02 [message #632] Mon, 30 October 2006 06:50
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Dear friends,

A Mokka prerelease, mokka-06-02-pre02, is available for download. This prerelease brings several Mokka improvements, but also the test beam models:

* TBDesy0506 : complete and checked.

* TBCern0806 : complete, but the position of the Hcal seems to be not good. It should be 90 mm upper, perhaps the same for the tail catcher (work in progress). Anyway this model should be already good for the Ecal prototype.

* TBCern1006 : complete but not checked yet.


These models are not yet completely stable, so please, consider it as a "prerelease".

Cheers, Paulo.

From the release notes:

What is new in this Mokka release
=================================

I. SEcal with three different sets of radiator thickness
II. Running Mokka in Batch Mode
III. New Plugins for Mokka
IV. Revised Makefiles to Locate MySQL Headers and Libraries
V. Improved Error Handling for MySQL NULL Values
VI. Usage of getopt(3) to Parse the Command Line
VII. Change in the MokkaGear Output for the TPC
VIII. Added MokkaGear Output for Vertex (VXD00+VXD01)
IX. New drift chambers and scintillator drivers for the
DESY and CERN test beams
X. Improved Material Descriptions
XI. Fix of a Memeory Leak in the Visualisation
XII. New TPC driver
XIII. New yoke-muon driver
XIV. Updates to the Tail Catcher geometry (for Cern TB)
XV. Switchable sensitive cassettes in the CALICE HCAL geometry
XVI. Configuration angle of the CALICE HCAL for the Cern 2006 test beams

============================================================ ========

Please note that:

1. This Mokka release co-works with Geant4 8.1 and CLHEP 2.0.2.3 or
Geant4 8.0.p01 and CLHEP 1.9.2.2 or 2.0.2.2, LCIO v01-05, v01-06 or
v01-07, gcc 3.2.3 or gcc 3.4.5, SL3 or SL4, optionally with
Gear v00-03

============================================================ ========

I. SEcal with three different sets of radiator thickness

To help studying new possibilities, the SEcal01 super driver is now able to
build the Ecal modules with three different thicknesses for the radiator
layers. For that two new database parameters were introduced in this release:

Ecal_nlayers3: Number of layers for the last set of layers
(near Hcal) for the Ecal;
Ecal_radiator_layers_set3_thickness: Ecal radiator thickness of
the last Ecal_nlayers3 layers.

Both parameters are set to zero, as the standard models use just two
different sets of radiator thickness for the Ecal.


II. Running Mokka in Batch Mode

Thanks to the new init command

/Mokka/init/BatchMode true

the users can now launch Mokka in batch mode, without an interactive session.
If BatchMode is set in the given steering file Mokka executes just a given
macro file, if any, and exits.


III. New Plugins for Mokka

Two new plugins have been added to the Mokka release. Please see the files

Mokka/source/Plugin/JDoePlugin/Readme
Mokka/source/Plugin/RandomPlugin/Readme

for more information.


IV. Revised Makefiles to Locate MySQL Headers and Libraries

As recently discussed on the Linear Collider Forum, the Mokka makefiles have
been slightly modified to allow for a greater flexibility when locating MySQL
header files and libraries. There are now four ways to determine the location
of MySQL-related files (with upper items having precedence over lower items):

1. Use MYSQL_INCLUDEDIR and MYSQL_LIBDIR, if defined
2. Use MYSQL_PATH, if defined
3. Use the "mysql_config" tool, if known to the shell (i.e. in the PATH)
4. Use "/usr/lib/mysql" and "/usr/include/mysql" as a default

The first possibility should be used only for special applications - be sure
you know what you're doing when you make use of this. The header file
"mysql.h" must be located in the directory "${MYSQL_INCLUDEDIR}" and the
library "libmysqlclient.{a,so}" must be located in "${MYSQL_LIBDIR}". Beware
of version mismatches and other evil things.

The second corresponds to the behaviour of previous Mokka versions, except
for the difference that the makefiles will now be able to handle both binary
and source distributions of MySQL. (The former will usually have header files
and libraries located in "${MYSQL_PATH}/include" and "${MYSQL_PATH}/lib",
respectively; the latter will have them in "${MYSQL_PATH}/include/mysql" and
"${MYSQL_PATH}/lib/mysql".)

The third option is the easiest, most flexible and cleanest - you simply have
to make sure that the "mysql_config" utility is reachable through your PATH.
You should find it in the "bin" directory of your MySQL installation.
Unfortunately it has been reported that the Windoze version of "mysql_config"
currently has a bug.

The last alternative requires no intervention by the user whatsoever. It can
be used if MySQL is installed in the default system directories.

For further information, please see:

http://forum.linearcollider.org/index.php?t=tree&th=227
http://dev.mysql.com/doc/refman/5.0/en/installation-layouts. html
http://dev.mysql.com/doc/refman/5.0/en/mysql-config.html


V. Improved Error Handling for MySQL NULL Values

The methods "Database::fetchDouble", "fetchInt", and "fetchString" will now
abort with a meaningful error message when they encounter an unexpected MySQL
NULL value instead of just crashing with a segmentation fault.

If you intend to make use of NULL entries in the database, you can check for
them by testing the return value of "Database::getTuple" (yes, there is one).

db->exec("SELECT `a`, `b`, `c` FROM `foo`.`bar`;");
char **tuple = db->getTuple();
if (tuple[1]) { // field `b` has an entry
const double b = db->fetchDouble("b");
/* do something with b */
} else { // field `b` is NULL
/* do something else without b */
}


VI. Usage of getopt(3) to Parse the Command Line

The handling of command line options and parameters has been slightly
revised. Mokka now uses the library function "getopt" (from <unistd.h>) to
parse the command line for options, their arguments, and other parameters.
The changes for the user are minimal:

* The help message can be displayed with the option "-H". The question mark
is reserved when using "getopt", and "-h" is already assigned to the
selection of the MySQL host to which Mokka should connect.

* Arguments of options can immediately follow the option character without
a separating space.

* Options without arguments (plus the next option with an argument) can be
concatenated after one single minus sign.

* You can use command line options together with a steering file. If a
steering file is given, its settings will override the settings which
were made on the command line. However, you cannot have more than one
steering file at a time.

* As a consequence, there is finally the possibility to have steering files
with names which begin with a minus sign. Just put "--" in front to
indicate that everything which follows is not a command line option.


VII. Change in the MokkaGear Output for the TPC

The MokkaGear output of the TPC drivers has been modified: The pad width and
the pad height are now set to the default values of 2 and 6, respectively.

Even though the recent TPC drivers make no assumption about the size of the
readout pads whatsoever, Gear cannot store a dummy value such as zero.
Therefore, the Gear information may be meaningless and should be treated with
care.


VIII. Added MokkaGear Output for Vertex (VXD00+VXD01)

This requires Gear v00-03. Writes Gear description for the vertex detector(s)
based on a ladder layout. (Note: for the old simplified model VXD00,
36 ladders are written out to approximate the cylidrical shape.)


IX. New drift chambers and scintillator drivers for the DESY and CERN test beams

* DESY test beam: new driver for the Drift Chambers, that were setup to run
with 96% Ar and 4% Ethane to avoid exposive gas mixture; hits are defined
as 'tracker' hits.
New drivers to define 3 scintillators (2 trigger, one veto) and 2 finger
counters (used for monitoring the beam position); hits are defined as
'calorimeter' hits.

* CERN test beam: the drivers for the folowing detectors on the beam line
have been added to the simulation:
Cerenkov detector (11m long, helium gas, only material is simulated -
no sensitive detector);
3 drift chambers (gas mixture 50% Ar - 50% C02, hits generated as 'tracker' hits);
4 scintillators (3 trigger scintillators and one veto counter, hits generated
as 'calorimeter' hits);
2 muon counters (hits generated as'calorimeter' hits) (note: in the Oct06 tb model
only 1 muon counter is present).

* Desy 05 test beam: for consistency, the hits in the scintillators are defined
as calorimeter hits, as for the above models.

X. Improved Material Descriptions

The element and material definitions for the overall detector construction
have been improved: Instead of using self-cooked elements and materials, the
CGAGeometryManager now takes advantage the rather precise and comprehensive
definitions (including the natural isotope composition for all elements)
which are provided by the G4NistManager wherever possible. In your own code,
you can use the methods

static G4Material *CGAGeometryManager::GetMaterial(const G4String &name)
static G4Element *CGAGeometryManager::GetElement(const G4String &name)

to access these definitions. See the files

$G4INSTALL/source/materials/src/G4NistMaterialBuilder.cc
$G4INSTALL/source/materials/src/G4NistElementBuilder.cc

or the user interface commands in the "/material/" directory for details.
Further definitions for materials which are not predefined by the
G4NistManager and a few alias names (for backward compatibility with the
existing Mokka geometry drivers) can be found in the database "materials02",
which has now become the default materials database.


XI. Fix of a Memeory Leak in the Visualisation

A memory leak related to the visualisation of tracks has been fixed. (With
the release of Mokka version 05-04 (and Geant4.Cool, the drawing of tracks was
disabled by default in order to circumvent the problem.)

The leak was caused by the internal handling of G4VisAttributes in Geant4 and
is currently being looked after by the Geant4 group.


XII. New TPC driver

A new TPC geometry driver named "tpc05" has been implemented. It inherits all
the features introduced in previous driver (tpc04).

New features are :
- Cathode plane in more detail - carbon support plus copper metalization,
total thickness of dead layer at 90degrees has increased to 5mm in total !
- Readout plane has not changed in structure only some of dimensions were
adjusted plus the remaining space after the gem tower is filled with
"electronics". It will now give a X0 of about 0.3 for default size
(endplate region of 160mm).
- Hit at each step approach was kept but TPC volume was divided into two
collections, TPCCollection and TPC_skinCollection (2.0cm thick volume on
the outer edge of TPC). With modification of the

/Mokka/init/lcioDetailedTRKHitMode

command that is now working with collections! and not with drivers it is
possible to have momentum information in this region (enough for having
the exact momentum on entry and exit of the TPC active volume) without the
overhead of storing the momentum at each hit.
If this is desired option the stearing file should contain following line

/Mokka/init/lcioDetailedTRKHitMode TPC_skinCollection

for momentum at each hit in TPC one should have

/Mokka/init/lcioDetailedTRKHitMode TPCCollection
/Mokka/init/lcioDetailedTRKHitMode TPC_skinCollection

plus a command for each silicon detector collection if needed.


XIII. New yoke-muon driver

New driver "yoke03" integrates in it self the yoke and the muon detector. It
inherits the caracteristics of yoke02 with some changes:

- additional parameter Yoke_with_plug decides should there be the plug or not
(it must be true for LDC00_xx (TESLA) series othervise there will be a gap in
geometry)

- if the plug is ON, it will have 5 active rpc layers of the same structure as
for the muon system equally distributed along the length of plug. Hits will
be in MuonPlugCollection.

- for design accuracy barrel was shorten and the endcap has full radius.

- muon system was implemented as a set of rpc layers. yoke is segmented in
the proposed way 100mm of iron + 40mm of air. in the air gap the rpc
structure from table is then filled in. first n layers are inside of the
iron and the last is on the surfice of the yoke. There are two collections
MuonBarrel and MuonEndCapCollection.

- hits are stored in cells of 30mm x 30mm (the number should be choosen
to be equivalent to expected position resolution) size and are of
SimCalorimeterHit type.

- all the numbers in the yoke03 tables can be changed without any problem
as long there is enough space to put the rpc structure in air gap and
enough thickness of iron to placne n-layers. If this is not true program
will abort with hint to check the geometry.


XIV. Updates to the Tail Catcher geometry (for Cern TB)

Updates to the Tail Catcher geometry, as installed
for the Cern test beam (Aug.2006):

- add air-filled gaps before and after TCMT cassettes
- MySQL DB: update absorber thicknesses and air gaps
as measured in the real setup.


XV. Switchable sensitive cassettes in the CALICE HCAL geometry

All scintillator cassettes in the CALICE HCAL are individually switchable with the global
model parameter HCALLayerPattern. To do so just add the following line in the steering
file: /Mokka/init/globalModelParameter HCALLayerPattern 1111...11
With a character '1' in the first position of this pattern a scintillator layer is build
at the first position of the geometry model. With a '1' at the second position a
scintillator layer is build at the second position and so on. If the character '0' is set
at any position of the pattern a volume of air with the size of the scintillator cassettes
is created at the corresponding position.
The lenght of the pattern 1111...11 needs to be exactely as long as the number of layers
defined in database (e.g. 38).


XVI. Configuration angle of the CALICE HCAL for the Cern 2006 test beams

The configuration angle of the CALICE HCAL for the Cern 2006 test beams is
set constantly to 0.0 degrees.
 Topic: Central MySQL server will be down
Central MySQL server will be down [message #613] Tue, 12 September 2006 04:47
musat
Messages: 57
Registered: February 2004
Dear friends,

Due to an electrical power shutdown, the central MySQL server
will be stopped from September 13, at about 19:00 GMT+1 timezone,
until September 14, about 16:30 - 17:00.

Please excuse us for the troubles that this may cause.

Cheers, Gabriel
 Topic: New Mokka release mokka-06-01
New Mokka release mokka-06-01 [message #497] Tue, 06 June 2006 07:06
musat
Messages: 57
Registered: February 2004
Dear friends,

We are happy to announce a new Mokka release, mokka-06-01, that
you can download from :

http://mokka.in2p3.fr

Cheers, Gabriel Musat

From release notes:

What is new in this Mokka release
=================================

I. Monte Carlo truth information stored by default in the LCIO file.
II. HEPEvt ASCII event file format versus Monte Carlo truth
information in LCIO.
III. New hepevt ASCII Brahms-like event files reader
IV. Possibility to choose a port number for the MySQL server host
or a socket file for local connections
V. Cooking the Model geometry at launch time
VI. First version of "MokkaGear" - automatic creation of gear files
VII. Changes and extensions of the Common Geometry Access (CGA) interface.

============================================================ ========

Please note that:

1. This Mokka release co-works with geant4.8.0.p01, LCIO v01-05, v01-06
or v01-07, gcc 3.2.3, CLHEP 1.9.2.2 or 2.0.2.2
============================================================ ========

I. The optional treatment "WriteCompleteHepEvt" for the Monte Carlo truth
information that is stored in the LCIO file becomes the default. The user
can switch it off thanks to the new Mokka init command

/Mokka/init/lcioWriteCompleteHepEvt

The old

/Mokka/init/userInitBool WriteCompleteHepEvt true

mechanism became obsolete and doesn't work anymore.

II. HEPEvt ASCII event file format versus Monte Carlo truth
information in LCIO.

HEPEvt ASCII event file format is the Geant4 file one, as stated by the
G4HEPEvtInterface documentation at

http://geant4.web.cern.ch/geant4/G4UsersDocuments/UsersGuide s/
ForApplicationDeveloper/html/Fundamentals/eventGenerator.htm l

The complete list of particles present in the HEPEvt ASCII file
is now copied to the MCParticle list in the LCIO output file, as it
was already done for the stdhep file format if WriteCompleteHepEvt
was set. It means, all particles the original generator (HepEvt) status
is preserved. The dynamic attributes of the particles like four momentum,
vertex and endpoint are updated during the simulation, e.g. for predefined
decays. Particles that are created during simulation like decays in
flight or nuclear interactions in the tracker region are added to the
list. The resulting list of MCParticles is closer to what is expected
in LCIO.
Note that this file format doesn't bring the vertex position neither the
creation time. This information has no sense for Geant4, as the
documentation above states: "Note that an event generator is not assumed
to give a place of the primary particles, the interaction point must be
set before invoking GeneratePrimaryVertex() method".


III. New hepevt ASCII Brahms-like event files reader

Mokka is able now to read in event files in the hepevt Brahms/lund
ASCII format. It works exactly as for the HEPEvt ASCII files described
before. Note that vertex and time information are dropped, even if it's
available with this file format. This facility is only available with
Mokka compiled with LCIO.


IV. Possibility to choose a port number for the MySQL server host
or a socket file for local connections

You can now connect to a particular port on the MySQL server host by
setting the host name in the form "host:port". If no port is given, the
default port (usually 3306) will be used. Examples:

/Mokka/init/dbHost pollin1.in2p3.fr
/Mokka/init/dbHost pollin4.in5p6.fr:3306
/Mokka/init/dbHost pollin7.in8p9.fr:0xFCE2

Choosing a different port can be useful if you have multiple MySQL servers
(differing in the assigned ports) running on the same machine. You can also
specify the reserved name "localhost" to connect to the local host via a
Unix socket file instead of TCP/IP. Use the form "localhost:socket" to
specify the filename of the socket file explicitly. If no filename is given,
a default name (depending on your MySQL version and settings) will be used.
Examples:

/Mokka/init/dbHost localhost
/Mokka/init/dbHost localhost:/tmp/mysql-5.0.21.sock
/Mokka/init/dbHost localhost:/afs/cern.ch/user/j/jdoe/mokka/mysql.sock

Be aware that MySQL may not be able to deal with extremely long filenames
in that context (e.g. automatically generated unique directories on some
batch systems).


V. Cooking the Model geometry at launch time

Since mokka-05-00 the user is already able to change at launch
time some geometric key parameters for the model being build,
thanks to the superdriver mechanism and the init command
/Mokka/init/globalModelParameter.

With this new Mokka release the user is able now to modify also the
geometry model composition at launch time, thanks to two new init
commands

/Mokka/init/EditGeometry/addSubDetector subdet build_order
/Mokka/init/EditGeometry/rmSubDetector subdet

where subdet is the subdetector name in the models03.sub_detector
table. Thanks to this facility the user is free to try different
model compositions without need of a cloned database.

Example, the following steering file

/Mokka/init/detectorModel LDC01
/Mokka/init/EditGeometry/rmSubDetector SEcal01
/Mokka/init/EditGeometry/addSubDetector ecal02

will let to a modified LDC01 model where the subdetector SEcal01
is replaced by the ecal02 one.

A simple way to create a new model from the scratch is to erase all the
ingredients for a given model, just inserting the line


/Mokka/init/EditGeometry/rmSubDetector all

in the steering file before adding the subdetectors which will
compose the new model.

Very important notes concerning Editing the geometry model:
===========================================================

1. The user can issue several EditGeometry commands on the
same steering file. The commands are applied in the same
order as found in the file.

2. The build_order parameter concerns only subdetectors build by
superdrivers. It's optional, default = 0.

3. You have to specify a build order when adding a subdetector
build by a superdriver, otherwise it'll take the default 0 value
which could let to bad results.
Please keep in mind that the superdrivers are written in such
way to propagate each inner device change to the immediatly outer
device, step by step. So when dealing with superdrivers the build
order is very important and can change completely the final model.
To work corretly the inner devices have to be build before the outer
devices.

4. To change the build order for an existing subdetector in a given
model the user has to delete it before to add it with the new value.

5. It's a user responsibility to be sure that the resulting
model doesn't have overlaps. Mokka doesn't warn about it.
Geometry overlaps probably will let to a crash when tracking
events. The above example is a bad one, as the old ecal02 subdetector
will overlap with the SHcal01 endcaps which is part of the LDC01 model.

6. Editing the geometry model should let to better results when
playing with subdetectors build by superdrivers, as these
subdetectors are able to adjust on the fly their key
parameters to avoid overlaps.

7. The global parameters which concern the world box size and
the tracker/calorimeter region boundaries come from the
given model. The default detector model currently is D09.
For this reason, even if you want to create a new test beam
model from the scratch, you have to choose a test beam model
as the model to edit, in such way to have the good global
parameters concerning the test beam models. In particular
the tracker/calorimeter region boundaries have to set to
zero for test beam models.

8. The tracker/calorimeter region boundaries are fixed on the fly when
using superdrivers IF AND ONLY IF the final values are bigger than
the model defaults. The user can modify these parameters via the init
command /Mokka/init/globalModelParameter.

9. Good luck...


VI. First version of "MokkaGear" - automatic creation of gear files

Optionally Mokka can be build against a recent version of GEAR (>= v00-03-beta) in order
to create a GEAR XML file containing the current detector description at every startup
of the Mokka application.

To enable this feature the GEAR enviroment variable should be set to your gear directory,
e.g. '/afs/desy.de/group/it/ilcsoft/gear/v00-03'

By default the data is written into 'GearOutput.xml'. The destination can be changed
to <destinationFile> in the steering file by using the init command:
'/Mokka/init/MokkaGearFileName <destinationFile>'
If the file already exists it will be overwritten.

Not all parameters can be obtained during construction. Also, users might want to change
parameters. Therefore two gear xml files can be merged. Using the steering file command
'/Mokka/init/MokkaGearMergeSource <mergeSourceFile>'
will merge the automatically generated file with <mergeSourceFile>.
The result will be in the file specified in '/Mokka/init/MokkaGearFileName'.

Currently only detectors using the drivers
'Ecal02', 'Hcal04', 'TPC02' and 'TPC04'
are supported.



VII. Changes and extensions of the Common Geometry Access (CGA) interface.

The CGA interface was modified and extended in order to allow the
implementation of distance and point properties in Gear (see
http://ilcsoft.desy.de/gear/). The changes and extensions are the
following:

- the content of the steering file was added as a (first) argument
of the CGAInit method. If not available, the empty string ("")
can be passed.
- the material names and the number of interaction lenghts are
additional informations that can be supplied by CGAGetSteps method,
and CGAGetVolumeData can also supply the total number of interaction
lengths.
- New methods for magnetic and electric field calculations:
- CGAGetB and CGAGetE return the magnetic and respectively the
electric field in a given point.
- CGAGetBdl and CGAGetEdl return the field integral along a
straight path between two given points.
- New methods for material properties in a given point: material name,
density, temperature, pressure, radiation length, interaction length.
- New methods for retrieving the list of logical and physical volumes
in the Geant4 hierarchy in a given point.
- New method for retrieving the name of the region corresponding to
a given point.
- New method for retrieving the position in the local coordinate frame
for a given point.
- New methods to check if a given point is located in tracker or
calorimeter region.

All these methods are available, as all CGA methods, for Fortran, C/C++
and Java applications. For the usage of these methods see examples
Ex01.c, Ex02.f and Ex03.java in directory Mokka/examples/CGA.

 Topic: Mokka Web site
icon14.gif  Mokka Web site [message #494] Thu, 01 June 2006 04:58
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Dear friends,

We are glad to announce the new Mokka Web address as being

mokka.in2p3.fr

All the old links should still work.

Cheers,
Paulo.
 Topic: MySQL server will be down on Monday, April 24
MySQL server will be down on Monday, April 24 [message #465] Thu, 20 April 2006 05:11
musat
Messages: 57
Registered: February 2004
Dear Mokka users,

We are finally going to upgrade our central MySQL server.
For this reason, it will be down next Monday, April 24, from
10:30 AM GMT + 2 Timezone, and it will be restarted during the
same day, as soon as all tests will run all right.

Please excuse us for the troubles that this may cause.

Cheers, Gabriel
 Topic: New Mokka release mokka-06-00
New Mokka release mokka-06-00 [message #450] Fri, 24 March 2006 09:04
musat
Messages: 57
Registered: February 2004
Dear friends,

We are happy to announce a new Mokka release, mokka-06-00.

From release notes:

What is new in this Mokka release
=================================


I. New visualisation commands
II. Fix to limit memory leak
III. New lStdHep library release
IV. Momentum information on tracker hits become optional
V. Optional path length information on tracker hits
VI. Given up on Geant4 patches
VII. User limits in PhysicsLists
VIII. New optional CellID encoding in two integers
IX. New convention for creating Ecal hits
X. New optional tracker layer in front of the Ecal prototype.
XI. Information on coordinates in calorimeter hits becomes optional.
XII. New Plugins for Mokka
XIII. New TPC driver with limited step length
XIV. New TPC subdetector
XV. Stand-alone driver and subdetector for the ETD
XVI. New driver for Hcal to correct sampling fraction
XVII. Revised driver for the magnet return yoke

============================================================ ========

Please note that:

1. This Mokka release co-works with geant4.8.0.p01, LCIO v01-05, v01-06
or v01-07, gcc 3.2.3, CLHEP 1.9.2.2 or 2.0.2.2

============================================================ ========

I. New visualisation commands

Several new commands to help developers to debug their
new sub detector drivers, built in the new
/Mokka/Visu/Detector/ command directory:

1) Mode * Set the rendering mode for a given sub detector and deep
2) Colour * Set the rendering color for a given sub detector deep
3) Daughters * Set the daughter's visibility for a given sub detector and deep
4) Visibility * Set the visibility for a given sub detector
5) ListGeometryTree * Prints the sub detector names, visibility and sub detector trees
6) ImmediateMode * Automatical refresh of the viewer after each command
7) Reset * Reset the vis attributes to the model default

The user can select the volume to have new visualisation attributes
giving a sub detector name (ecal, vxd, hcal, etc.), a deep level in the
geometry three and/or a logical volume name. For more information, please,
type help and follow the command path.


II. Fix to limit memory leak

The Control::drawFlag defaults now to false to avoid memory
leak with G4VisAttributes when running Mokka en batch.


III. New lStdHep library release

Thanks to Willy Langeveld and Norman Graf the new lStdHep library
release coming with lelaps V03-27-28 is able to read in a new
common block which gives the ability to process the whizdata
events.

IV. Momentum information on tracker hits become optional

By default the momentum information on the tracker hits are
not written on the lcio format to avoid huge files. The user
can change this default for a given sub detector thanks to
the new init command

/Mokka/init/lcioDetailedTRKHitMode sub_detector_name

For example, inserting the command

/Mokka/init/lcioDetailedTRKHitMode tpc

in the Mokka steering file lets to get the momentum information
for all hits from the tpc.

To know the generique sub detector names used in Mokka for a given
geometry model you can use the command

/Mokka/Visu/Detector/ListGeometryThree

at run time.

V. Optional path length information on tracker hits

As well as the momentum information on tracker hits described above,
the total path inside de sentive material for each hit will also be saved
into lcio files, if the Mokka was linked against lcio v01-07.


VI. Given up on Geant4 patches:

Both Geant4 patched classes G4PVDivision and G4Transportation are over
thanks to the Geant4 8.0.p01 release, so these files are no more
part of the normal Mokka distribution.


VII. User limits in PhysicsLists

The processes "G4StepLimiter" and "G4UserSpecialCuts" are now added to the
physics list for all long-lived charged particles. (The Geant 4 built-in
physics lists and LCPhys don't contain these processes by default.)

This way, the step limitation specified via "G4UserLimits" attached to
logical volumes becomes operational again in this Mokka release (it was
already operational before Geant 4.7.0). Adrian Vogel found the problem and
solved it.

VIII. New optional CellID encoding in two integers

In order to allow studies with Ecal having very small cells (3x3 mm2 or even
50 microns x 50 microns), but also in order to allow studies of energy deposit
in the Guard-Ring of the Ecal wafers, we introduced in these cases an encoding
of cell indices in two CellID's, both for ASCII and LCIO output. In all the
other cases (if the number of cells doesn't exceed 511) we use the old
encoding convention in one CellID. For the Hcal, the encoding convention was
not changed. This new encoding scheme applies both to the final detector Ecal
and to the Ecal prototype. There is a new index that was introduced in this
new convention: the guard-ring zone, that gives a measure of the distance
between the hit in the Guard-Ring and the border of the nearest cell. This
index is equal to zero if the hit is inside a cell, and is equal to the number of the
guard-ring zone that was hitted if the hit is in the guard-ring.

There is also a new definition of the CGA utility methods CGACellIndex and
CGAGetCellId: these methods use two CellID's now.

The usage of the calorimeter hit classes CellHit, ProtoHit, Proto_CellHit
was replaced with CalHit, and these three classes were removed because their
only purpose was to give a different encoding scheme. Now, the encoding is no
more a job of the hit classes, but is done by specialized encoder classes:
Encoder32 (the old scheme), EncoderTB (the scheme that was defined in class
Proto_CellHit) and Encoder64 (the new two CellID's scheme) which all inherit
from VEncoder.



IX. New convention for creating Ecal hits

For the final detector Ecal and for the Ecal prototype that have an
implementation of the silicon layer with Wafers and cells, two collections
are created: the old hits collection for the hits inside cells, and a new
collection for hits in the Guard-Ring. For hits in a guard-ring zone new
CalHits are created containing the total energy deposit in that Guard-Ring
zone, and the number of the guard-ring zone is coded in CellID0.

In the ASCII files, the hit lines of the Ecal prototype and Ecal Barrel that
are situated in the Guard-Ring begin with P = 15. The Guard-Ring hits that
are in the -Z Encap begin with P = 14, and in the +Z Endcap begin with P = 16.

X. New optional tracker layer in front of the Ecal prototype.

It was requested by Mokka users to have the momentum at the entrance of the
Ecal prototype saved in the output file. For this, a thin tracker layer (made
of air) was added in front of the Ecal prototype. This tracker layer is
optional, and one has to use the steering command:

/Mokka/init/globalModelParameter use_tracker true

in order to have this tracker built.

But also, since the momentum information on tracker hits becomes optional
with this new Mokka release, one should specify that he/she wants the
momentum to be saved, by using the steering command:

/Mokka/init/lcioDetailedTRKHitMode proto

In the ASCII files, the hit lines of this new tracker begin with P = 1.


XI. Information on coordinates in LCIO calorimeter hits becomes optional.

In order to reduce the size of the LCIO files, the information on the
coordinates of calorimeter hits is now optional, as they can be retrieved
(by the CGA interface for example) by using the CellID's. This information
can be saved in the LCIO output by using the new steering command:

/Mokka/init/lcioStoreCalHitPosition true


XII. New Plugins for Mokka

A few plugins have been added to the Mokka release. Please see the files

Mokka/source/Plugin/LogPlugin/Readme
Mokka/source/Plugin/MagPlugin/Readme
Mokka/source/Plugin/MarkerPlugin/Readme
Mokka/source/Plugin/MaterialPlugin/Readme

for more information.



XIII. New TPC driver with limited step length

A new TPC geometry driver named "tpc04" has been implemented. Unlike previous
TPC implementations, is does not use the approach of a fixed number of
"layers" in the chamber gas (each of which may contain exactly one hit), but
sets a limit to the maximum allowed step length in the sensitive TPC volume.
Each of the steps now creates a hit in the output file.

The reason for this change of design is that in previous implementations, the
distribution of hits got sparse on the far side of curling tracks.
Furthermore, low-energy tracks travelling in z-direction did not create an
appropriate number of hits - for example delta electrons could easily get
lost.

The new approach will give you hits which are distributed more evenly along
the track (but with varying amounts of energy deposition, of course): Two
hits belonging to the same track should have a maximum distance which is
equal to the maximum step length, but they can also sometimes be closer if
the steps are shorter (due to other physical processes).

An instance of "G4UserLimits" is attached to the sensitive TPC volume. This
class cannot only limit the maximum step length (enforced by the
pseudo-process "G4StepLimiter"), but also the maximum track length and time
as well as the minimum kinetic energy and remaining range (all managed by the
pseudo-process "G4UserSpecialCuts"). The TPC driver supports these other
limits, too.
The geometry which the driver will construct is very similar to that of
previous implementations. However, the TPC endplate does not consist of some
averaged material mixture anymore, but of many thin disks made of various
materials, thus modelling an approximately realistic composition of the
endplate. The resulting fraction of radiation lengths will be written to the
Mokka standard output. The field cage is still represented by a thin layer of
solid aluminium (equivalent to the realisitc field cage design with respect
to radiation lengths), but this is planned to be improved in the future.
Additionally, a thin cathode plane made of copper has been added in the
middle of the chamber. Please keep in mind that you may hit this when using
the particle gun with p_z = 0.

The driver is self-scaling, i.e. it does not need to be wrapped by a
superdriver which builds a temporary fake database on the fly. The model
parameters which are used by "tpc04" are:

TPC_inner_radius - inner radius of the inner field cage
TPC_outer_radius - outer radius of the outer field cage
TPC_inner_wall_thickness - equivalent thickness of the inner field cage
TPC_outer_wall_thickness - equivalent thickness of the outer field cage
TPC_Ecal_Hcal_barrel_halfZ - end of the chamber including the endplate
TPC_electronics_backend_thickness - thickness of the endplate

Note that the endplate does not have to be (and usually will not be) filled
with materials (other than air) along its full thickness. The driver will
adjust the global parameters "tracker_region_rmax" and "tracker_region_zmax"
such that they will enclose the whole TPC.

The sensitive volume reaches from the surface of the cathode plane up to the
surface of the endplate in the longitudinal direction. In the radial
direction, there are insensitive offsets from "TPC_inner_radius" and
"TPC_outer_radius". You will not get hits with energy deposits lower than 34
eV (limit of Argon ionisation), and you will not get hits from tracks with
kinetic energies lower than "TPCCut". The default value for this cut is
10 MeV, but you may want to decrease it using the steering command

/Mokka/init/TPCCut EKIN [UNIT]

in order to get a better description of delta electrons and other low-energy
particles.

If you're interested in track reconstruction, you should be aware that you
may have to process the hits created by this driver with a dedicated
digitiser, since the pseudo-digitisation which was enforced by the artificial
gas layers (representing the readout pad rows) is now gone. You should also
prepare for an increased number of low-energy particles (such as deltas)
which may make your life slightly harder.


XIV. New TPC subdetector

A new TPC subdetector has been implemented which uses the new geometry driver
described above. It is named "tpc06" and connects to the MySQL database of
the same name.

It features a cathode plane with a thickness of 0.1 mm (averaged
representation of a copper mesh), an endplate composed of various materials
adding up to approximately 20% of a radiation length, and a chamber volume
filled with TDR gas. It limits the step length in the sensitive volume to
5 mm, but does not set any other cuts. The actual size of the TPC depends on
the chosen geometry model since the driver is scalable, without built-in
default values.


XV. Stand-alone driver and subdetector for the ETD

There is now a stand-alone geometry driver for the ETD (Endcap Tracking
Disks), formerly known as FCH (Forward Chamber) or ECT (Endcap Tracker). The
driver called "etd00" is used by a subdetector of the same name. It is
basically equal to the FCH which was incorporated in earlier implementations
of the TPC driver and does not offer any improvements yet.

For now, the ETD consists simply of two thin sensitive silicon disks. The
geometry driver is self-scaling (not needing a superdriver) and uses the
following model parameters:

TPC_inner_radius - inner radius of the TPC
TPC_outer_radius - outer radius of the TPC
TPC_Ecal_Hcal_barrel_halfZ - end of the TPC including the endplate
FCH_thickness - thickness of the ETD silicon disks
Ecal_cables_gap - the space between the TPC and the Ecal endcaps

The disks are placed immediately before the Ecal endcaps. However, they can be
smaller than the TPC in the radial direction. In the current subdetector, TPC
and ETD share the same inner radius (inner gap is zero), but the outer radius
of the ETD is 90 mm smaller than that of the TPC. The driver will increase the
global parameter "tracker_region_zmax" to include the ETD.
"tracker_region_rmax" will not be changed since the ETD is typically not
larger than the TPC.
The driver will also increase the global parameter "Ecal_cables_gap" to
include the ETD if there is not enough space available. In this case the ECAL
endcaps will be pushed outside.


XVI. New driver for Hcal to correct sampling fraction

A new driver for the Hcal Hcal04 has been developed. It introduces a fiber gap
(filled with 'air' so far) to the scintillator version of the Hcal. New
subdetectors hcal04scint and SHcal02 use this driver.
The default sampling fraction for the Hcal with scinitllator option is changed
in the subdetector SHcal02 to be 38 layers of 20 mm steel, 5 mm scintillator
thickness and a 1.5 mm fiber gap (as specified in the TDR).
In principle the fiber gap can be changed in the steering file, e.g.
/Mokka/init/globalModelParameter Hcal_fiber_gap 1.8
Note that the chamber thickness is currently hard coded in the SHcal01 driver
to be 6.5 mm, so the scintillator thickness is (6.5 - fiber_gap)mm !


XVII. Revised driver for the magnet return yoke

The geometry driver for the yoke has been slightly revised. The new version
is called "yoke02" and is used by a subdetector of the same name which is
part of the new geometry models.

The rotational symmetry of the yoke is read from an entry in the associated
database. The subdetector "yoke02" will give you an octagonal yoke, i. e.
eightfold symmetry. Independent from this choice, the yoke will always rest
on a flat side. Like the previous geometry driver "SYoke01", "yoke02" will
not construct the magnet pole tips which were protruding into the inner part
of the coil in older geometries.

The driver is self-scaling (it does not need to be wrapped by a superdriver)
and uses the following global geometry parameters:

Yoke_barrel_inner_radius - inner radius of the barrel
(enclosing the magnet coil)
Yoke_endcap_inner_radius - inner radius of the endcaps
(enclosing the beam line)
Yoke_thickness - thickness of the barrel
Yoke_Z_start_endcaps - start of the endcaps in z-direction
Yoke_Barrel_half_z - end of the whole yoke in z-direction

Note that the radius is measured from the centre of the polygonal shape to
the middle of each side of the polygon - the distance from the centre to the
corners of the polygon is larger. Therefore, the total radius of the yoke is
actually larger than "Yoke_barrel_inner_radius + Yoke_thickness".

The yoke currently consists of solid iron. It does not contain a muon system
yet, even though it's planned to have a better description in the future.


 Topic: MySQL server
MySQL server [message #439] Fri, 17 March 2006 09:10
musat
Messages: 57
Registered: February 2004
Dear friends,

As we are still working for the next Mokka release,
we will need to have the server up all day next Monday,
so the upgrade will be postponed.

Please excuse us for the problems that this may cause.

Cheers, Gabriel
 Topic: Central MySQL server will be down on Monday, March 20
Central MySQL server will be down on Monday, March 20 [message #438] Wed, 15 March 2006 07:02
musat
Messages: 57
Registered: February 2004
Dear Mokka users,

We are going to upgrade our central MySQL server to MySQL 5.0.
For this reason, it will be down next Monday, March 20, from
10:30 AM GMT + 1 Timezone, and it will be restarted during the
same day, as soon as all tests will run all right.

Please excuse us for the troubles that this may cause.

Cheers, Gabriel
 Topic: LCDD and Mokka
LCDD and Mokka [message #433] Mon, 06 March 2006 10:16
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
I was just wondering if anyone has given any thought into including LCDD input support for Mokka.

It allows a pretty complete description of the detector geometry.
 Topic: CellID's encoding in Mokka
CellID's encoding in Mokka [message #430] Fri, 17 February 2006 04:33
musat
Messages: 57
Registered: February 2004
Dear friends,

We would like to inform you about our intention to change the
CellID's encoding in Mokka. We have two reasons to do that:

1. There are people who study Ecal versions with very small cells
(for example 3x3 mm2), and in this case, the values of the cell
indices are greater than the maximum allowed values by the
previuos encoding rules of the CellID.
2. There are people who study the energy deposit in the guard-ring
of the silicon wafers of the Ecal, and they need to store an
additional index of the guard-ring zone that was touched, as a
measure of the distance with respect to the cell border.

For these reasons, we need to use two integers to store all these
indices. So we started the implementation of this new scheme, by
using two CellID's, both in the ASCII and LCIO output. For the
LCIO output, we introduced a new steering command that specifies
to save or not the x, y, z, cell center coordinates, in order to
give the user the possibility to decrease the size of the LCIO
files.

The new encoding scheme is part of the CalHit class. There is an
exception that concerns the Test Beam Hcal Prototype, that will
continue to use it's own encoding scheme written by Roman
Poeschl, encoding scheme that is different from the new one in
CalHit. In this way, software having ganging code for this Hcal
prototype will not have to change it's decoding scheme of the
CellID.

We will have a VRVS meeting on February 23, during which we'll
talk about implications that this new encoding scheme could have
on other software that uses Mokka output.

So we strongly invite you to that VRVS meeting, so that we can
take the decision on the best way to proceed. One way, suggested
by Frank Gaede, in order to minimize the implications on other
software, could be to change the CellID encoding only for the
case of very small cells and for the Test Beam Ecal prototype
and Ecal detector that have implementations of wafer guard-rings.

Cheers, Gabriel

 Topic: new Mokka release mokka-05-05
new Mokka release mokka-05-05 [message #420] Mon, 23 January 2006 08:55
musat
Messages: 57
Registered: February 2004
Dear Friends,

We are glad to announce a new Mokka release, mokka-05-05. It's
available for download from the Mokka Web page at

http://polype.in2p3.fr/geant4/tesla/www/mokka/mokka.html


(from release notes:)

What is new in this Mokka release
=================================

This release is compliant with Geant4 release 8.0. For that several
small changes were necessary and a patch for this Geant4 release:

I. Changes in the PhysicsLists.
II. A patched G4PVDivision.cc.
III. A new patched G4Transportation for Geant4 8.0
IV. Fixes in visualisation


============================================================ ========

Please note that:

1. This Mokka release was tested with Geant4 8.0, LCIO v01-05
and v01-06, gcc 3.2.3, CLHEP 1.9.2.2 and 2.0.2.2

============================================================ ========


I. Changes in the PhysicsLists:

a) Gave up of the Mokka old PhysicsList.

It was the same as the official Geant4 LHEP one, so LHEP becomes the
default. The old PhysicsList is kept as "DummyPhysicsList" only for
the CGA or visualization usages, where it's used just for geometry
calculations.

b) Temporarilly suspended the PhysicsListNeutrons.
The time to adapt it to the new Geant4 physics list schema.

c) Gave up of the PhysicsLists LHEP_GN, LHEP_HP and QGSP_GN.
It doesn't exist anymore in the Geant4 release 8.0.

d) New PhisicsLists available from the Geant4 8.0 release.
LHEP_BERT_HP, LHEP_BIC, LHEP_BIC_HP, LHEP_EMV, QGSP_BERT_HP
and QGSP_EMV.

e) Kernel/GNUmakefile updated to take in account the PhysicsLists
changes.

II. A patched G4PVDivision.cc file :

A bug in the original G4PVDivision.cc file lets to a crash when
using the LumicalS, see the Geant4 problem report #829. This release
includes a patched G4PVDivision.cc file to work around this problem.
It's included directly in the Mokka.cc code so the user doesn't need
to to patch its own Geant4 installation.

III. A new patched G4Transportation for Geant4 8.0

Unfortunately Geant4 8.0 doesn't fix the problem #820 so
we provide for this Mokka release a special patch for the
G4Transportation process. Thanks to a new G4VProcess
interface, this new patched G4Transportation can be
included directly in the Mokka.cc, the user doesn't need
to patch its own Geant4 installation.

IV. Fixes in visualisation

1) Fix to CalHit to be able to reload calorimeter hits even when
it has gard ring information;
2) Using DummyPhysicsList when in visualisation mode.


 Topic: Central MySQL server while Christmas holidays
icon4.gif  Central MySQL server while Christmas holidays [message #410] Thu, 22 December 2005 05:31
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Dear Friends,

The L.L.R. will be closed for Christmas holidays from Friday, December 23 at 18 hours Western European Time, till Monday, 2 January morning. All the computer services will be kept on, except if a long electrical power or a hardware failure occurs. If the central MySQL server of Mokka comes down for any of these raisons perhaps you’ll have to wait till the Monday, 2 January morning, to get it operational.

Please excuse us for the troubles that this may cause, if any.

Cheers, Paulo Mora de Freitas.

 Topic: Central MySQL server will be stopped
Central MySQL server will be stopped [message #394] Tue, 29 November 2005 08:02
musat
Messages: 57
Registered: February 2004
Dear Friends,

For reasons of electrical power maintenance, the central
MySQL server of Mokka will be down from wednesday, November 30
at 20 hours Western European Time, and till Thursday morning.

Please excuse us for the troubles that this may cause.

Cheers, Gabriel
 Topic: new Mokka release mokka-05-03
new Mokka release mokka-05-03 [message #381] Thu, 10 November 2005 09:17
musat
Messages: 57
Registered: February 2004
Dear Friends,

We are glad to announce a new Mokka release, mokka-05-03. It's
available for download from the Mokka Web page at

http://polype.in2p3.fr/geant4/tesla/www/mokka/mokka.html


(from release notes:)


Thanks to people from DESY (gaede@mail.desy.de) we now have
available the folowing features:

I. Optional new treatment of the Monte Carlo truth information that is
stored in the LCIO file.

II. The complete steering file is writen to the LCIO outputfile.


III. Allow factor for B-field to be larger than one.

Thanks to Fabrizio Salvatore (p.salvatore@rhul.ac.uk) we now have available

IV. New detector model TB07.
------------------------------------------------------------ ------------------
We recommend to compile and link this new Mokka release mokka-05-03
with Geant 4 release 7.1.patch01

New materials database "materials01" is the default sincemokka-05-02 .
Users running a local database should download this new database from the
central MySQL server (pollin1.in2p3.fr) if they haven't done so.

If you wish to use the physics list "LCPhys", make sure you compiled your
Geant 4 installation with the "G4BERTINI_KAON" preprocessor flag defined.
------------------------------------------------------------ ------------------


I. Optional new treatment of the Monte Carlo truth information that is stored
in the LCIO file.
In this new mode the complete list of particles present in the stdhep file
will also be copied to the MCParticle list in the LCIO outputfile.
For all particles the original generator (HepEvt) status is preserved.
The dynamic attributes of the particles like four momentum, vertex and endpoint
are updated during the simulation, e.g. for predefined decays.
Particles that are created during simulation like decays in flight or nuclear
interactions in the tracker region are added to the list. The resulting list
of MCParticles is closer to what is expected in LCIO.
This feature only works in LCIO mode with stdhep input files and is activated
by simply setting WriteCompleteHepEvt to true in the steering file:

/Mokka/init/userInitBool WriteCompleteHepEvt true


II.The complete steering file is writen to the LCIO outputfile. It is written to the
(first) LCRunHeader parameter MOKKA_SteeringFile. This is particularly usefull if
one uses the superdrivers in Mokka and overwrites some of the parameters.


III. Allow factor for B-field to be larger than one. Now you can specify any factor > 0
for varying the B-field in the steering file or on the command line to study the B-field
dependence of the pflow algorithms.


IV. New detector model TB07.

Thanks to Fabrizio Salvatore (p.salvatore@rhul.ac.uk) we now have available
detector model TB07 that is detector model TB06 with the hodoscope added,
implementing the complete Test Beam setup.

 Topic: new release mokka-05-02
new release mokka-05-02 [message #378] Thu, 03 November 2005 07:47
musat
Messages: 57
Registered: February 2004
Dear Friends,

We are glad to announce a new Mokka release, the mokka-05-02. It's
available for download from the Mokka Web page at

http://polype.in2p3.fr/geant4/tesla/www/mokka/mokka.html


(from release notes:)


I. Range Cut per region implemented in the Calice Ecal
prototype
II. Bug fix in Geant 4 release 7.1.patch01

Thanks to Adrian Vogel from DESY (adrian.vogel@desy.de) we
now have the folowing new features in this Mokka release:
III. New Geometry Models "D13TDR", "D13Stahl", and "D13XStahl"
IV. Support for a Crossing Angle
V. New Physics List "PhysicsListNeutrons"
VI. New Commands for the Particle Gun
VII. Interface for Guinea Pig Files
VIII. Restructured Plugin Directory
IX. New Hooks for Plugins
X. Modified Definition of the Material "beam"
XI. Revision of the Makefiles
XII. A Comment on Possible Linking Problems
XIII. Miscellaneous
XIV. References

Thanks to Damien Grandjean from IRES, Strassbourg
(Damien.Grandjean@IReS.in2p3.fr), we now have the folowing
new feature in this Mokka release:

XV. New Geometry Models "D14" and "D14_CMOSVTX"
------------------------------------------------------------ ------------------
We recommend to compile and link this new Mokka release mokka-05-02
with Geant 4 release 7.1.patch01

New materials database "materials01" becomes the default. Users running a
local database should download this new database from the central MySQL
server (pollin1.in2p3.fr)

If you wish to use the physics list "LCPhys", make sure you compiled your
Geant 4 installation with the "G4BERTINI_KAON" preprocessor flag defined.
------------------------------------------------------------ ------------------


I. Range Cut per region implemented in the Calice Ecal prototype


Three separate regions were defined in the Ecal prototype (driver Proto03):
the Silicon Cells and Guard-Rings, the Tungsten and the G10 (PCB's).
One new command line option was defined for setting the Range Cut in
the Silicon: -C cut in mm. Three new steering init commands were introduced
to define the Range Cuts in the three regions mentionned above:

/Mokka/init/activeRangeCut - for the Silicon
/Mokka/init/radiatorRangeCut - for the Tungsten
/Mokka/init/pcbRangeCut - for the G10

This new feature is available with any Physics List.


II. Bug fix in Geant 4 release 7.1.patch01

While performing simulations at LLR - Ecole Polytechnique and at DESY,
it was noticed that while using Geant 4 release 7.0 and 7.1, Mokka sometimes
runs into an infinite loop, not processing any more events but still running.
Predrag Krstonosic from DESY saw that the cause of this trouble was
G4ChordFinder that had the end point of the chord set to (nan, nan, nan).
A series of tests was made to tune some parameters belonging, for example,
to G4FieldManager and G4ChordFinder, and to build G4ChordFinder with
different steppers (G4SimpleHeum, G4SimpleRunge, G4HelixSimpleRunge,
G4HelixExplicitEuler, G4HelixImplicitEuler). Every time, Mokka ended by
getting stuck.

According to John Apostolakis a solution was found and it was included in
Geant 4 release 7.1.patch01. Regarding the source of the problem, it has
been found in an electromagnetic process which caused the nan for the
direction. At LLR - Ecole Polytechnique a series of simulations were
performed with event files that caused the problem with previous Geant 4
releases, and it was noticed that with this last Geant 4 patch the infinite
loop didn't show up any more.


III. New Geometry Models "D13TDR", "D13Stahl", and "D13XStahl"

Three new geometry models named "D13TDR", "D13Stahl", and "D13XStahl" have
been added. They are derived from "D10" and offer an improved description of
the beam tube, the overall forward region and the magnetic fields. "D13TDR"
models the forward region as it was described in the TESLA Technical Design
Report [1] (featuring the LAT and LCAL forward detectors and a final focus
length L* of 3.00 m), "D13Stahl" follows a proposal made by Achim Stahl et
al. (LC-DET-2004-034) [2] (featuring the LumCal and BeamCal detectors and a
final focus length L* of 4.05 m), and "D13XStahl" is equal to the second
except that it has a beam crossing angle of 20 mrad.

The models make use of several new geometry drivers which support a crossing
angle, introduce the final focus quadrupoles, and are able to model the
solenoid field from a field map, including an optional "detector-integrated
dipole" (DID). Apart from the detector components which have simply been
inherited from "D10", the models introduce a couple of new subdetectors which
are shown below. Besides that, they use the subdetectors "ftd01" instead of
"ftd00" and "vxd01" instead of "vxd00".

tubeX00TDR, tubeX00Stahl, tubeX00XStahl (using the driver tubeX00)

The beam tube and the contained vacuum from the interaction point up to a
distance of z = 10 m.

maskX00TDR, maskX00Stahl, maskX00XStahl (using the driver maskX00)

The whole mask of the forward region, including a graphite absorber, the
main support tube, roughly-modelled electronics and vacuum installations,
the final focus magnets with their cryostats, and - for the time being -
also the forward calorimeters, implemented as non-sensitive solid blocks
of material. Note that the models do not make use of the more detailed
"LumiCalS" which was introduced with the model "D12".

fieldX00TDR, fieldX00Stahl, fieldX00XStahl (using the driver fieldX00)

The fields of the final focus quadrupoles as well as the main solenoid,
thereby using the solenoid field maps which have recently been published
by the SLAC magnet group (see the web page of the Beam Delivery Meeting,
2005-07-26) [3]. The superimposed DID field is currently not enabled, but
it is supported by the geometry driver and can be switched on by changing
one flag in the geometry database.

yoke01TDR, yoke01Stahl, yoke01XStahl (using the driver yoke01)

Modifications of the existing subdetector "yoke00", with an octagonal
shape and an adjusted inner diameter of the endcaps.

tpc05 (using the driver tpc03)

A modification of the existing subdetector tpc04, now reading the chamber
gas from its database and fixing a geometry overlap problem with the TPC
endplates. Together with this subdetector, a few gas mixtures have been
added to the Mokka materials database: "TDR_gas" (93% Ar, 5% CH4,
2% CO2), "P5_gas" (95% Ar, 5% CH4), and "P10_gas" (90% Ar, 10% CH4). The
chamber modelled by "tpc05" is currently filled with TDR gas.


IV. Support for a Crossing Angle

Since there is now a geometry model with a crossing angle available, a new
steering command has been added:

/Mokka/init/lorentzTransformationAngle

Sets the angle which is used to transform the momenta of all primary
particles (both from the particle gun and from generator files) from the
centre-of-mass frame (in which they are usually generated) into the
laboratory frame (in which they are detected). Parameters are a scalar
(initial value 0) and an optional unit (default mrad). Be aware that the
given angle is the angle between the incoming beams and the z-axis, i. e.
half the crossing angle between the two beams. This command is only
available in the pre-initialisation state, i. e. it may only appear in
your steering file.

The Lorentz transformation which will be applied acts in the following way:
If you select the angle stated above and then shoot a relativistic particle
straight in the z-direction (for example with the particle gun), its momentum
will actually have the given angle with respect to the z-axis. The energy of
the particle is slightly increased so that the simulated centre-of-mass
energy stays the same, because a small fraction of the particle energy gets
used up in order to boost the centre-of-mass frame with respect to the
laboratory frame. Particles flying in other directions and non-relativistic
particles will be transformed accordingly. Note that the positions of the
vertices will not be Lorentz-transformed.

Please note that it's your own responsibility to make sure you set the
transformation angle correctly - the angle will _not_ be set automatically
when the geometry gets constructed. You may want to select a model with a
head-on detector geometry and still use a small crossing angle such as
2 mrad, in which case there is no need for a second beam tube inside the
interaction region. You may also have a particle generator which already
accounts for the crossing angle - in that case no further transformation will
be needed.

V. New Physics List "PhysicsListNeutrons"

A new physics list named "PhysicsListNeutrons" has been added. It is a
variant of the existing "PhysicsList", intended for simulations including
neutrons (from background reactions). PhysicsListNeutrons enables
gamma-nuclear processes (i. e. neutron production in nuclear reactions) and
uses high-precision models for low-energy neutrons.

You can select PhysicsListNeutrons with the command
"/Mokka/init/physicsListName PhysicsListNeutrons" in your Mokka steering
file. Please note that you need to have the environment variable
"NeutronHPCrossSections" set correctly _at runtime_ - otherwise, Mokka will
be aborted at startup. You should also be aware that the startup of Mokka
will take _much_ longer than usual when you use PhysicsListNeutrons.

The Linear Collider Physics List "LCPhys" by Dennis Wright also enables
gamma-nuclear processes, but up to now it uses neutron models which become
rather poor at low energies (below approximately 20 MeV). LCPhys might
include the high-precision models at some time in the future - as soon as
this happens, PhysicsListNeutrons should be considered obsolete. For more
information on physics lists, have a look at the Geant 4 Hadronic Physics
Home Page [4] by Hans-Peter Wellisch, particularly the section on linear
collider neutron fluxes.

VI. New Commands for the Particle Gun

The commands to control the behaviour of the particle gun have been modified
and partially extended. The previously existing commands "/generator/scan",
"/generator/randomDirections", "/generator/gaussgun", and
"/generator/gaussgun/momentum" have been replaced by the following:

/gun/positionStep

Sets a step by which the position of the gun will be changed after each
shot. The parameters are an optional three vector (default 0 0 0) with an
optional unit (default cm). This command corresponds to the previous
"/generator/scan".

/gun/positionSmearing

Sets the uncertainties (i. e. gaussian sigmas) by which the three
coordinates of the position of the gun will be smeared in each shot. The
parameters are an optional three vector (default 0 0 0) with an optional
unit (default cm). Together with "/gun/position", this command
corresponds to the previous "/generator/gaussgun".

/gun/thetaStep

Sets a step by which the polar angle of the gun will be changed after
each shot. The parameters are an optional scalar (default 0) with an
optional unit (default deg). This functionality is new. Please note that
the polar angle will get stuck if it reaches the boundaries 0 deg or
180 deg.

/gun/thetaSmearing

Sets an uncertainty (see "/gun/directionSmearingMode") by which the polar
angle of the gun will be smeared in each shot. The parameters are an
optional scalar (default 0) with an optional unit (default deg). Together
with "/gun/phiSmearing", this command corresponds to the previous
"/generator/randomDirections" if "/gun/directionSmearingMode" is set to
"uniform".
/gun/phiStep

Sets a step by which the azimuthal angle of the gun will be changed after
each shot. The parameters are an optional scalar (default 0) with an
optional unit (default deg). This functionality is new.

/gun/phiSmearing

Sets an uncertainty (see "/gun/directionSmearingMode") by which the
azimuthal angle of the gun will be smeared in each shot. The parameters
are an optional scalar (default 0) with an optional unit (default deg).
Together with "/gun/thetaSmearing", this command corresponds to the
previous "/generator/randomDirections" if "/gun/directionSmearingMode" is
set to "uniform".

/gun/momentum

Sets the momentum of the particle gun, thus overwriting the kinetic
energy set by "/gun/energy". The parameters are a scalar (initial value
100.106 GeV) with an optional unit (default GeV). Together with
"/gun/momentumSmearing", this command corresponds to the previous
"/generator/gaussgun/momentum". Please note that this value will
implicitly change when you select a different particle type with
"/gun/particle": Whereas the kinetic energy is a basic property of the
Geant 4 particle gun, the momentum is only a derived property which is
calculated from mass and kinetic energy, so it will change when the mass
changes.

/gun/momentumStep

Sets a step by which the momentum of the particle gun will be changed
after each shot. The parameters are an optional scalar (default 0) with
an optional unit (default GeV). This functionality is new. Please note
that the momentum will get stuck if it reaches the boundary 0 GeV.


/gun/momentumSmearing

Sets an uncertainty (i. e. gaussian sigma) by which the momentum of the
particle gun will be smeared in each shot. The parameters are an optional
scalar (default 0) with an optional unit (default GeV). Together with
"/gun/momentum", this command corresponds to the previous
"/generator/gaussgun/momentum".

/gun/directionSmearingMode

Selects the random distribution which is used for the angular
uncertainties given by "/gun/thetaSmearing" and "/gun/phiSmearing". The
parameter is a string (candidates "gaussian" and "uniform", initial value
"gaussian"). A value of "gaussian" indicates that the angular
uncertainties are treated as gaussian sigmas, a value of "uniform"
indicates that the angular uncertainties are treated as half widths of a
uniform distribution. This functionality has been introduced for
compatibility with the previous "/generator/randomDirections".


/gun/info

Prints the particle type (including mass), nominal kinetic energy
(including momentum), nominal position, and nominal direction (including
theta and phi components) of the particle gun which will be used for the
next shot. Steps and uncertainties are not displayed. This command has no
parameters. It has been introduced to avoid confusion between
"/gun/energy" and "/gun/momentum".

The "step" and "smearing" commands are cumulative and permanent - their
effects add up and remain valid until the values are re-set. As opposed to
the previous implementation, none of the above commands actually fires the
gun - shots are now always fired by "/run/beamOn".

There have been suggestions to extend the existing single-particle gun in a
way that it can shoot two or even multiple particles with different
properties in a single event. However, for the sake of simplicity, these
ideas have been rejected for the time being. At some time in the future,
Mokka might include the "General Particle Source" which has much more
features than the standard Geant 4 particle gun.


VII. Interface for Guinea Pig Files

Mokka can now read files containing electron-positron pairs created by Guinea
Pig. These files must have names with the suffix ".pairs" (remember that a
symbolic link will do the job in case you're unable or unwilling to rename
your actual files) and can be accessed with the command
"/generator/generator".

Events are generated with the command "/run/beamOn". In the current
implementation, each event contains one single electron or positron because
one single bunch crossing can easily consist of more than 100,000 pairs.
Mokka will be aborted if you try to read past the end of the file, so you
should use a tool like "wc -l" to find out how many single particles (one per
line) are contained in your file.


Guinea Pig uses its own output format for the file "pairs.dat" which contains
the electrons and positrons created by the scattering of beamstrahlung in one
bunch crossing. Each line represents one particle and contains seven values:
the energy (in GeV, positive for electrons and negative for positrons), the
three components of the velocity (in units of the speed of light), and the
three components of the vertex position (in nanometres).


VIII. Restructured Plugin Directory

The contents of the directory "Mokka/source/Plugin" have been split up into
two subdirectories: One contains the "PluginManager" and the "Plugin" base
class, the other one contains all files for the "Checkplots" example plugin.
You may copy the whole directory "Mokka/source/Plugin/Checkplots" and use it
as a template for your own plugins. Make sure to include your plugins in the
top-level makefile "source/GNUmakefile" and in the main makefile
"source/Kernel/GNUmakefile" (just like it's done with the "Checkplots"
example) so that they get compiled and linked into the Mokka executable.


IX. New Hooks for Plugins

Up to now, plugins had the problem that it was not easy to control their
functionality with the help of steering parameters
("/Mokka/init/userInit..."): Plugins are realised as global static objects
(defined by the "INITPLUGIN(plugin, name)" preprocessor macro) and their
constructors - which usually perform the initialisation tasks - are called at
a very early stage of program initialisation. In particular, the steering
file has not yet been parsed for user parameters and UserInit therefore
cannot tell you any values. This problem could be worked around, but not very
elegantly.

For this reason, two hooks "void Plugin::Init(void)" and "void
Plugin::Exit(void)" have been added to the Plugin base class and also to the
PluginManager. These methods are called from main() immediately before the
user interface session is constructed and immediately after the session ends,
respectively. This way you can be sure that all managers are properly
initialised by the time the "Init()" method of your plugin is invoked. You
also know that all managers are still intact when the "Exit()" of your plugin
gets called. A further advantage is that "Init()" and "Exit()" will not be
called for inactive plugins, so your plugin won't do unnecessary work when
it's not activated via "/Mokka/init/registerPlugin" (constructors and
destructors will _always_ be called when your compiled plugin is linked into
the Mokka executable).

You can shift all your initialisation tasks from the constructor to the
"Init()" method and all clean-up tasks from the destructor to "Exit()".
However, you still have to provide a suitable constructor so that your plugin
can be registered with the PluginManager. This constructor doesn't have to
contain any actual statements, but it _must_ call the constructor of the base
class - otherwise your plugin won't be compiled:

MyPlugin::MyPlugin(const std::string &name): Plugin(name) {}


The internal management of the plugins has also been improved: The
PluginManager now checks whether all plugins have unique names and it will
print a warning message when you try to activate a plugin (via
"/Mokka/init/registerPlugin") which does not exist. Furthermore, the
performance of invoking the several hooks (which might have a significant
impact for the stepping and tracking actions) has been increased.


X. Modified Definition of the Material "beam"

The definition of the material "beam" has been modified. This material is
used to model the vacuum inside the beam pipe. Before, "beam" consisted of
air at a low density (1.0E-5 g/cm^3) and pressure (0.02 bar), but these
values were still too high and the material composition was not very
realistic either.


The estimated vacuum in the beam delivery system is described in a TESLA Note
(TESLA 2001-14) [5]. The main ingredients of the residual gas are CO/N2 (at a
pressure of 1.0E-8 mbar) and hydrogen (pressure approximately 5 times higher,
but not as relevant due to its small atomic number). The new "beam" material
definition uses 0.5E-8 mbar of CO, 0.5E-8 mbar of N2 (the actual ratio of
these two components is unknown), and 5.25E-8 mbar of H2, giving a total
pressure of 6.25E-11 bar and a density of approximately 1.7E-14 g/cm^3 at STP
temperature (0 deg C). The usage of such small values is made possible by the
recent removal of field width limits in the Mokka database.

Following Mokka's strict policy of backward compatibility, the modified
material definition has been put into a new MySQL database named
"materials01" which will be used by the CGAGeometryManager from now on.


XI. Revision of the Makefiles

The makefiles which belong to the Mokka source code have been revised and
partially shortened. Changes include:


* The variables "G4LIB" and "G4LIBDIR" are not set anymore because they can
be managed internally by the Geant 4 makefiles. As a result, your
"G4WORKDIR" doesn't get cluttered up by all kinds of directories anymore
- all dependencies, object files and object libraries are now put in
subdirectories of "$(G4WORKDIR)/tmp/$(G4SYSTEM)". The Mokka executable is
put in "$(G4WORKDIR)/bin/$(G4SYSTEM)", as before.

* The preprocessor flag "NDEBUG" (which you had to define if you did _not_
want debugging information, i. e. in the standard case) has been replaced
by "MOKKA_DEBUG", which you now have to define if you want additional
debugging information. The common makefile
"source/Kernel/GNUmakefile.common" looks for an environment variable of
the same name and sets the flag accordingly. The renaming also resolves
an overlap with low-level header files in which the same flag is used
(e. g. "assert.h"). In the same course, some assertions were replaced by
calls to "Control::Abort".

* The preprocessor flag "G4R4" is gone (both in the makefiles and in the
source code). It has become obsolete because there are other pieces of
code which need more recent versions of Geant 4 than just 4.0 and these
are not marked in any way. As always, you should use the latest release
of the software, which is Geant 4.7.1.patch01 as of November 2005.

* The support for a custom MYSQL_PATH has been moved to the common makefile
"source/Kernel/GNUmakefile.common". It is now handled in a similar way as
LCIO.

* The common makefile now contains only preprocessor flags which are
appended to the variable "CPPFLAGS". All library inclusions have been
moved to the main makefile "source/Kernel/GNUmakefile" and are appended
to the variable "EXTRALIBS" before "$(G4INSTALL)/config/binmake.gmk" is
read.


* The main makefile "source/Kernel/GNUmakefile" has been significantly
shortened: Many libraries could be left out because they are passed on to
the linker automatically by the Geant 4 makefiles. The options for the
different physics lists are now set by "$(foreach ...)" constructs. The
check for "G4LIB_BUILD_SHARED" has been removed because it is not needed
anymore. Multi-line statements (connected by backslashes) have been
transformed to multiple statements because it was difficult to comment
out one of the lines.

* The include preprocessor flags have been shortened to contain only those
paths which are actually needed for each module. The flags
"-I../../LHEP/include" and "-I../../Packaging/include" have been removed
completely because these modules have ceased to exist as a part of Mokka
- they are now provided by the Geant 4 framework.

* The file "$(G4INSTALL)/config/architecture.gmk" is not included
explicitly anymore because this is already done by
"$(G4INSTALL)/config/binmake.gmk".

* The variable "install" is not set anymore.


If you are not a developer, none of the above issues (except maybe the first)
should matter for you - simply type "make" and go to get some coffee.


XII. A Comment on Possible Linking Problems

If you are using granular Geant 4 libraries, you may want to note the
following: Each geometry driver and plugin is instantiated once as a global
static object by the preprocessor macros "INSTANTIATE" and "INITPLUGIN",
respectively, and then registers itself in a list of available code modules
which is kept by a manager. This technique has the advantage that it's
possible to add such modules without having to modify any part of the Mokka
kernel, but it also has the disadvantage of breaking the explicit chain of
dependencies between all the source files. The internal makefiles of Geant 4
rely on these dependencies and collect all libraries which are needed for the
process of linking the final Mokka executable (using the "liblist" tool). As
a result, Geant 4 does not know about the libraries which are _only_ referred
to by geometry drivers or plugins, so these libraries will have to be
included in the main makefile "Mokka/source/Kernel/GNUmakefile" by hand.


Currently this has to be done only for "libG4geomdivision" and
"libG4geomBoolean" because all other needed libraries are _also_ used by
pieces of code which are directly connected (via chains of "#include"
directives) to the top-level file "Mokka/source/Kernel/Mokka.cc". However,
this may change if future geometry drivers or plugins use other "exotic"
classes, and it will also change when you try to compile with special
settings such as the "G4VIS_NONE" flag, for example. (The kernel won't need
some graphics-related classes anymore, but the geometry drivers will still
refer to them.) To be able to link the Mokka executable in these cases,
you'll have to find out which classes cause the problem, which of the Geant 4
libraries contain them, and add these libraries to your main makefile by
hand. Keep in mind that their order matters to the linker because they may
again have depedencies among each other. In the example of "G4VIS_NONE",
appending "-lG4specsolids", "-lG4csg", and "-lG4graphics_reps" (in that
order) to the variable "EXTRALIBS" should currently be sufficient to build
Mokka successfully.

Please keep in mind that this is simply the price which has to be paid for
the flexible approach of geometry driver and plugin management.

XIII. Miscellaneous


* A problem with the geometry drivers "coil00" and "yoke00" has been fixed.
These drivers didn't close their database connections, i. e. they
didn't destroy the "Database" object which they created. This could
cause problems when many instances of Mokka were trying to access the
same database server because the number of MySQL connections is limited.
All driver developers should make sure that their own code doesn't
leave orphaned connections behind. See a related discussion [6] in the
Linear Collider Forum to find out more.

* A geometry overlap in the driver "tpc02" (constructing the subdetector
"tpc04") has been fixed: The overall mother volume of the TPC is now
large enough for the TPC endplates to fit inside. (Please note that this
fix might in principle affect backward compatibility.) Besides, the name
of the corresponding logical volume has been changed from
"TPCInnerShield" (obviously a typo) to "TPCMotherLog" and the copy number
of the second endplate (at z < 0) has been changed from 0 (already in
use) to 1.

* The file access permissions in the Mokka CVS repository have been changed
so that the files are not marked as "executable" anymore - as a
consequence, they won't show up in green in your favourite shell
when you unpack the Mokka tarball or checkout the sources via CVS.

* The width specifications for all fields of type "FLOAT" and "DOUBLE" have
been removed from the central MySQL geometry database. This solves a
problem with MySQL 4.1 which caused numerical values to be truncated when
they exceeded the maximum field width. See a related discussion [7] in
the Linear Collider Forum to find out more.

* The class "DchTbVisManager" and the method "DchTbHit::DrawWithVisM" have
been removed. They were not called from anywhere, but they caused trouble
when trying to compile with the preprocessor flag "G4VIS_NONE".

* A tiny bug in "CGAGeometryManager" has been fixed which caused a wrong
handling of LCIO versions x.0 and x.1 for x > 0.

* A new steering command "/Mokka/init/userInitBool" has been introduced to
define boolean variables cleanly. Possible values are "Y", "YES", "T",
"TRUE", or "1" on the one hand and "N", "NO", "F", "FALSE", or "0" on the
other hand, all case-insensitive.

* The existing commands "/Mokka/init/userInitDouble" and
"/Mokka/init/userInitInt" now do type-checking and will give you a
warning message at startup if they encounter invalid parameters.

* "UserInit" will now give you a warning when you try to define a user
variable twice - the second assignment will be ignored. "UserInit"
also checks whether a user variable has actually been defined when some
piece of code tries to get its value - if not, you'll get a default
return value (the empty string, zero, or "false") as before, but you'll
also get a warning message.

* The command "/generator/generator" will not abort Mokka anymore if a file
with the given name does not exist or cannot be opened.

* The "ControlMessenger" now makes use of the "G4Tokenizer" and the
conversion methods of "G4UImessenger" instead of handling string streams
by itself.


* You'll now get a warning message if "/Mokka/init/lcioWriteMode" has a
parameter value other than "WRITE_APPEND" or "WRITE_NEW".

* The "MySQLWrapper" now gets compiled without a warning message because it
uses standard functions from "stdlib.h" instead of the deprecated
"strstream" header.

* As you may already have noticed, all the release notes are now collected
in a subdirectory "Mokka/ReleaseNotes".


XIV. References

[1] http://tesla.desy.de/new_pages/TDR_CD/
[2] http://www-flc.desy.de/lcnotes/
[3] http://www-project.slac.stanford.edu/lc/bdir/Meetings/beamde livery/
2005-07-26/index.htm
[4] http://cmsdoc.cern.ch/~hpw/GHAD/HomePage/
[5] http://tesla.desy.de/new_pages/TESLA_Reports/2001/pdf_files/
tesla2001-14.pdf
[6] http://forum.linearcollider.org/index.php?t=tree&goto=33 7
[7] http://forum.linearcollider.org/index.php?t=tree&goto=34 2


XV. New Geometry Models "D14" and "D14_CMOSVTX"

Detector model D14 is same as D12 but contains new sub-detector VXD01 and
new beampipe TUBE02. VXD01 is the realistic geometry of the TESLA TDR vertex
detector. The 5 layers of the vertex detector are composed of ladders instead
simple cylinders used in previous version VXD00. The ladders are attached on
the beryllium support shell by beryllium annulus block. The first layer is
supported by beryllium disk placed directly on the beampipe. The description
of the beampipe TUBE02 is the same as TUBE01 but the radius of the beampipe
central part is 14 mm instead 10 mm to be consistent with the TESLA TDR.

The detector model D14_CMOSVTX is same as D12 but contains the new
subdetectors VXD02 and TUBE02. VXD02 is the realistic geometry of the CMOS
vertex detector concept.(see SNOWMASS 2005 presentations). The mecanical
support is the same as the VXD01 sub-detector.


For both new sub-detectors VXD01 and VXD02, the kapton strip line are still
modelled by cones as in the VXD00 sub-detector. This will be updated in the
next version.

These two new sub-detectors and the new beampipe are build with super
drivers: SVxd01 for the 2 vertex detector geometries and STube01 for the
beampipe. The 2 new super drivers have the following default values as
parameters:

1) SVxd01 - The user can change on fly few parameters of the VXD:
- The radius of the first layer and/or the fifth layer.
(the radius of the other layers are scaled and
the optimal number of ladders per layer is recalculated.)
- The thickess of the ladder support, the silicon active part and
the very front end electronics.
- The kind of material used for the ladder support
- The VXD is surounded by a cryostat or not.

+-------------------------------------+---------------+
| parameter | default_value |
+-------------------------------------+---------------+
| VXD_inner_radius | 15 |
| VXD_outer_radius | 60. |
| VXD_support_ladder_thickness | 0.28224 |
| VXD_active_silicon_thickness | 0.03744 |
| VXD_end_electronics_thickness | 0.19656 |
| VXD_cryostat_option | 1 |
| VXD_support_ladder_material | "beryllium" |
+-------------------------------------+---------------+

2) STube01 - The user can change the thickness of the central part of the
beampipe. The radius of the central part of the beampipe depends on the
radius of the first layer of the VXD. The beampipe will be placed always
at 0.5 mm of the first layer.

+-------------------------------------+---------------+
| parameter | default_value |
+-------------------------------------+---------------+
| TUBE_central_thickness | 0.5 |
+-------------------------------------+---------------+

exemple of steering commands :


/Mokka/init/globalModelParameter TUBE_central_thickness 0.2
/Mokka/init/globalModelParameter VXD_inner_radius 12
/Mokka/init/globalModelParameter VXD_outer_radius 80
/Mokka/init/globalModelParameter VXD_support_ladder_material "graphite"
/Mokka/init/globalModelParameter VXD_support_ladder_thickness 0.05
/Mokka/init/globalModelParameter VXD_active_silicon_thickness 0.05
/Mokka/init/globalModelParameter VXD_end_electronics_thickness 0.05
/Mokka/init/globalModelParameter VXD_cryostat_option 0
Pages (7): [ «    1  2  3  4  5  6  7    »]


Current Time: Mon Oct 14 12:07:21 Pacific Daylight Time 2019
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software