Production branches of Arte

This page describes the "production" branches of Arte, i.e. executables and settings used for the major production-kind sets of Real Data or Monte Carlo reconstructed (generated) here on the desy online farms.

Please skim below the the versioning principles.

described branches

library ARTE-04-01-r3, mc generation
1. r3.mcgen.v0 | r3.mcgen.v0.1 | r3.mcgen.v0.2 | r3.mcgen.v0.3 | r3.mcgen.v0.3
library ARTE-04-01-r5, physics triggered mc reconstruction
library ARTE-04-01-r5, minimum bias mc reconstruction
1. r5.minbias.v0
2. r5.minbias.v1
library ARTE-04-01-r5, hard photon mc reconstruction
1. r5.hardphoton.v0
2. r5.hardphoton.v1
library ARTE-04-01-r5, mc generation
library ARTE-04-01-r5, Real Data reconstruction
1. r5.rd.v0 | r5.rd.v0.1
2. r5.rd.v1.0 | r5.rd.v1.1 | r5.rd.v1.2
library ARTE-04-01-r6, Real Data reconstruction
1. r6.rd.v0

library ARTE-04-01-r3

ARTE-04-01-r3 mc branch "physics"

The versions of the so-called 'repro-3' triggered reconstruction.

. . .

ARTE-04-01-r3 mc branch "mcgen"

r3.mcgen.v0

The first known to DG Monte Carlo generation version composed by His Brilliance Sr. José María Hernández Calama.

distinguishing features: unknown

executable built on 27/02/03
HBVERS=ARTE-04-01-r3
build directory: $HBROOT/RECO/mcgen
kumac: hb_mcgen.kumac.25_04_2003

r3.mcgen.v0.1

Standard r3 generation executable, hopefully reproducing r3.mcgen.v0 after the latter one was accidentally deleted...

executable built on 27/09/03
HBVERS=ARTE-04-01-r3
build directory: $HBROOT/RECO/mcgen
kumac: hb_mcgen.kumac.25_04_2003

r3.mcgen.v0.2

Arte-r3 with Hartmut's patch.

1 change w.r.t. r3.mcgen.v0.1

frit/fratleo.F patched by H.Rick to avoid an infinite loop

executable built on 17/10/03
HBVERS=ARTE-04-01-r3
build directory: $HBROOT/RECO/mcgen
kumac(s): hb_mcgen.kumac.25_04_2003,
	  hb_mcgen_dev.kumac.17_10_2003

r3.mcgen.v0.3

Arte-r3 with Hartmut's patch and moving wires

1 change w.r.t. r3.mcgen.v0.2

user/usevnt.C enabled to apply X,Y,Z offsets to the GTAR positions at initialization. The offsets are passed via environment, e.g.
```
  setenv W_1BOT_OFFSET_Y 0.1
  setenv W_1BOT_OFFSET_X 0.1
```
will shift the below1 wire position up and towards i2 by 1mm.
special treatment of processes like 9ABCDE -> ABCD0E in the kumac to distinguish mc samples produced with non-standard wire positions in this way

executable built on 26/05/05
HBVERS=ARTE-04-01-r3
build directory: $HBROOT/RECO/misc/at_21417
kumac(s): hb_mcgen_dev.kumac.17_10_2003
          hb_mcgen_dev.kumac.26_05_2005

Comment(s):

WARNINIG: The GEANT VOLUME corresponding to the wire is not shifted! This leads to an underestimation of multiple scattering inside the target, which is a visible effect for tungsten targets of ribbon shape wide along Z.
The bug fixed in r3.mcgen.v0.4

r3.mcgen.v0.4

Arte-r3 with Hartmut's patch and moving wires

1 change w.r.t. r3.mcgen.v0.2

bugfix in r3.mcgen.v0.3: apply the offset to GEANT wire volumes in addition to moving the GTAR/NTAR positions The offsets are passed via environment, e.g.
```
  setenv W_1BOT_OFFSET_Y 0.1
  setenv W_1BOT_OFFSET_X 0.1
```
shifts the below1 wire position up and towards i2 by 1mm.

executable built on 17/07/2006
HBVERS=ARTE-04-01-r3
build directory: $HBROOT/RECO/misc/at_9514
kumac(s): hb_mcgen_dev.kumac.26_05_2005

library ARTE-04-01-r5

ARTE-04-01-r5 mc branch "physics"

r5.physics.v2.0

formerly called 'MC test 3.75' with keybook 10 (with the nominal OTR efficiency)
(see also comments in the README: $HBROOT/RECO/misc/mc.20040314/mc.20040314.rm)

distinguishing features w.r.t. some older, repro-4 mc tests (to be described) ...

Muon pretrigger optical link-swapping (implemented in mprearte-00-02)
optical-link efficiency corrected by fudge-factors for November (Monte Carlo keybook 10).
a change of trigger efficiency definition (fltarte/trgsim.C) (eff == -1.) if the SLT not passed, otherwise it equals the value returned by the FLT.

executable built on 16/03/04 (reconstructs all events)
HBVERS=ARTE-04-01-r5
MUPRESIMVERS=mprearte-00-02
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p2
build directory: $HBROOT/RECO/misc/mc.20040314
kumac: hb_mctrig-rec.r5.kumac.19_03_2004
       hb_mctrig-rec.r5.kumac.02_04_2004 (write out DSLT)
keybook 10

r5.physics.v2.1

formerly called 'MC test 3.75' with keybook 10 (with the nominal OTR efficiency)

1 change w.r.t. r5.physics.v2.0

user/usevnt.C changed to reconstruct only events accepted by SLT

executable built on 31/03/04 (reconstructs only triggered events)
HBVERS=ARTE-04-01-r5
MUPRESIMVERS=mprearte-00-02
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p2
build directory: $HBROOT/RECO/misc/mc.20040314
kumac: hb_mctrig-rec.r5.kumac.19_03_2004
       hb_mctrig-rec.r5.kumac.02_04_2004 (write out DSLT)
keybook 10

r5.physics.v2.2

formerly called 'MC test 3.75' with updated FLT eff (keybook 11) and nominal OTR eff

1 change w.r.t. r5.physics.v2.0

use of keybook 11 (update of FLT efficiencies for 2002)

executable built on 16/03/04 (reconstructs all events)
HBVERS=ARTE-04-01-r5
MUPRESIMVERS=mprearte-00-02
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p2
build directory: $HBROOT/RECO/misc/mc.20040314
kumac: hb_mctrig-rec.r5.kumac.19_03_2004
       hb_mctrig-rec.r5.kumac.02_04_2004 (write out DSLT)
keybook 11

r5.physics.v2.3

formerly called 'MC test 3.75' with updated FLT eff (keybook 11) and nominal OTR eff

1 change w.r.t. r5.physics.v2.1

use of keybook 11 (update of FLT efficiencies for 2002)

executable built on 31/03/04 (reconstructs only triggered events)
HBVERS=ARTE-04-01-r5
MUPRESIMVERS=mprearte-00-02
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p2
build directory: $HBROOT/RECO/misc/mc.20040314
kumac: hb_mctrig-rec.r5.kumac.19_03_2004
       hb_mctrig-rec.r5.kumac.02_04_2004 (write out DSLT)
keybook 11

r5.physics.v3.0

formerly called 'MC test 3.75 with realistic OTR efficiency' (keybooks 11,12)
(see also comments in the README: $HBROOT/RECO/misc/mc.20040314/mc.20040314.rm)

2 changes w.r.t. r5.physics.v2.0

the realistic OTR efficiencies used of the MC keybook 11.
commented kumac command 'HBDIGI/OTRNOMINALEFFICIENCY 0.95'
which previously forced the 95% OTR officiency

executable built on 16/03/04 (reconstructs all events)
HBVERS=ARTE-04-01-r5
MUPRESIMVERS=mprearte-00-02
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p2
build directory: $HBROOT/RECO/misc/mc.20040314
kumac: hb_mctrig-rec.r5.kumac.19_03_2004
       hb_mctrig-rec.r5.kumac.04_04_2004 (write out DSLT)
keybook 11,12

r5.physics.v3.1

formerly called 'MC test 3.75 with realistic OTR efficiency' (keybooks 11,12)

1 change w.r.t. r5.physics.v3.0

user/usevnt.C changed to reconstruct only events accepted by SLT

executable built on 31/03/04 (reconstructs only triggered events)
HBVERS=ARTE-04-01-r5
MUPRESIMVERS=mprearte-00-02
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p2
build directory: $HBROOT/RECO/misc/mc.20040314
kumac: hb_mctrig-rec.r5.kumac.19_03_2004
       hb_mctrig-rec.r5.kumac.04_04_2004 (write out DSLT)
keybook 11,12

r5.physics.v4.0

This version of MC reco differs from the famous 'MC test v3.75 with realistic OTR' == r5.physics.v3.x by the update of muon pretrigger (the MUPRESIM-dev described in Ulrich's mail to hbanalysis from 21st Apr 2004).

db updates related to MUON efficiencies and optical link swapping see keybook 13
updated library MUPRESIMVERS=mprearte-00-02
either all or only SLT-accepted events are reconstructed depending on envariable $RECOALLEVENTS (user/usevnt.C)
DSLT table always included into the output files

executable built on 06/05/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mc.20040506
kumac: hb_mctrig-rec.r5.kumac.06_05_2004
keybook 13

r5.physics.v4.1

1 change w.r.t. r5.physics.v4.0:

geometrical acceptance (version from 24 May 2004 from Maaijke) written to xtri->bx .

executable built on 13/05/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mc.20040513
kumacs differ by the various sets of defined targetbox settings:
   hb_mctrig-rec.r5.kumac.08_05_2004   (i1-b1 November-only)
   hb_mctrig-rec.r5.kumac.24_05_2004   (b1-o2 yr 2003 before and after Jan 21st)
   hb_mctrig-rec.r5.kumac.27_05_2004   (b2-only November)
keybook 13

r5.physics.v4.2

1 change w.r.t. r5.physics.v4.1:

update of geometrical acceptance routine from Maaijke (the code received on 01/06/04).

executable built on 07/06/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mc.20040601
kumac: hb_mctrig-rec.r5.kumac.27_05_2004
keybook 13

r5.physics.v4.3

1 change w.r.t. r5.physics.v4.2:

a new feature added to the SLT:
now if an event was accepted by the refit-y, the targetbox simulation is perfomed 33 times! (for different combinations of the tbox offsets). The result of the first 32 tries is saved into the DSLT (the tbox accept mask (actually the time word in L2IO_EVENT)), and afterwards the 'nominal' targetbox is simulated. An example of how to access the tbox accept mask can be found in: /hb/slt/medinnis/chkmask/user/usevnt.C:
```
...
  int tmask;
  if( SLTTrigMask(&tmask) != SLT_OK) {
    cout << "SLTTrigMask returned an error" << endl;
  }
...
```
Under Linux4 all the necessary functions are available from the latest compile of the SLTVERS=Rev0606 library.

executable built on 03/06/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mc.20040603
kumac: hb_mctrig-rec.r5.kumac.27_05_2004
keybook 13

r5.physics.v5.0

1 change w.r.t. r5.physics.v4.3:

a new SLT executable as of 17/06/2004 (correction in the l2magnet)

executable built on 03/06/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mc.20040603
kumac: hb_mctrig-rec.r5.kumac.17_06_2004
keybook 13
Comment:

 the kumac effectively is hb_mctrig-rec.r5.kumac.27_05_2004 with

  /SLT/SIM/path /hb/scratch/month/medinnis/gut/Linux_intel_glibc/bin
  /SLT/SIM/file gut_test_mc

 the sources were later collected in
  $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p4




r5.physics.v6.0
1 changes w.r.t. r5.physics.v5.0:

 use mc keybook 14 with updated FLT efficiencies for 2003

executable built on 03/06/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p4
build directory: $HBROOT/RECO/misc/mc.20040603
kumac: hb_mctrig-rec.r5.kumac.07_08_2004
keybook 14

Comments:

 in 2002 (Nov, Dec) r5.physics.v6.0 does not differ from v5.0
 in 2003 the MC already reconstructed with v5.0 (old FLT maps) can be
     "upgraded" to v6.0 by applying the FLT maps of mc keybook 14
     on mc MINIs and using Antonello's patch as described in
 the flt analysis page.
 also see related Maaijke's mail from 06 Aug 2004




r5.physics.v7.0
5 changes w.r.t. r5.physics.v6.0:

MUON database updates from mc keybook 15
new muon pretrigger library MUPRESIMVERS=mprearte-00-03
updated murec/MuMCPadHit2Digi.C according to Uli's mail from 11/08/04
Shower-shape variables introduced by Mauro into care (taken from r5.RD.v1.1)
harmless update of $HB/dev/gean (read_dat.C,medmain.C,phevnt.C also from r5.RD.v1.1)

executable built on 15/08/04
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20040811
kumac: hb_mctrig-rec.r5.kumac.07_08_2004
keybook 15

Comment:
The main changes are those in MUON according to the mail of Ulrich to hbanalysis from 11/08/04
and introduction of the shower-shape variables which first appeared in the real data branch r5.RD.v1.1.





r5.physics.v8.0
also known as "try 0" MC
8 changes w.r.t. r5.physics.v7.0:

target box numbers refined (see the kumac),
new MUON digitization (see VIK's 2004/10/07 charmonium talk),
implement NRQCD kinematical weights per default (see Ulrich Husemann's mail to hbanalysis from 12 Sept 2004),
handle bad FEDs,
Misalign SLT
    (for OTR only) by repro3-repro5 alignment difference in each calibration period
VDS nominal geo (do not apply alignments to the VDS geo)
marvin++ (admixing extra-events
    in addition to the marvin bug fix in the SLT VDS sparsification)
target box mask disabled

executable built on 11/10/04
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20041011 -> at_19746
kumac: hb_mctrig-rec.r5.kumac.11_10_2004
keybook 15

Comment(s):
WARNINIG: The NRQCD kinematic weights are always zero for Ti.






r5.physics.v9.0
6 changes w.r.t. r5.physics.v8.0:

  keybook 16 with updated target box link to L2TARG_0 [4:0] wich features:
  more accurate averaging of target box settings (weighting of runs with
      corresponding number events input to the second level trigger)
     
 agreement of the internal target box run table which is used in the
      averaging with the analysis runlist (Uli's charmonium analysis runlist)
 
 
 partial fix of the "b1" target box problems in november and january
 
 enable back the target box mask to work together with the marvin bugfix
 
 possibility to learn the run number according to which the target box
      of the given mc event was simulated (e.g. one can select specific runs
      or discard those not on the bbbar list or some missing quadrants, a.s.o.)
 
 Filippo's and Benedetto's chi_c weights written to MCME::bpos .

executable built on 29/10/04
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20041029
kumac: hb_mctrig-rec.r5.kumac.29_10_2004
keybook 16
SLT executable sltsim42

Comment(s):
Not all of the target box-related "below-target" problems in
 November and end of January were fixed in keybok 16 (see v10.0).
    
The target box settins in keybook 16 for October b1b2 run 20233 were
    noticeably bad. Fortunately this is a small run, but it may be worth to
    exclude the mc events simulated according to this run from the analysis.
    
WARNINIG: The NRQCD kinematic weights are always zero for Ti.
    
Note, that A.Spiridonov reports that according to the cross-check
    of DQ done by Ilija, in the so-called 'Missing Quadrant' November runs the
    problematic quadrant was OFF during most of the run, and its efficiency
    should be close to zero. In the default r5.physics.v9.0 the 'MQ' is simulated
    with some reduced muon pretrigger optical link efficiency for the problematic
    quadrant. It is more appropriate to use 'Fully MQ' mc where the efficiency of
    the problematic quadrant is set to exactly zero.
    
 For r5.physics.v9.0 version such mc was reconstructed for the muon channel
    using /key_table_TEST, RUN2CNAKEY -211211; KEYBOOK 2004120500 .






r5.physics.v10.0
1 changes w.r.t. r5.physics.v9.0:

 keybook 17 with updated target box link to L2TARG_0 [5:0] wich 
  improved the overall precision of the target box settings
     
 fixed all remaining in mc keybook 16 target box-related
     "below-target" problems in November and January 
 

executable built on 29/10/04
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20041029
kumac: hb_mctrig-rec.r5.kumac.04_11_2004
keybook 17
SLT executable sltsim42

Comment(s):
WARNINIG: The NRQCD kinematic weight are always zero for Ti,
  they are broken, broken, broken!!






r5.physics.v11.0
2 changes w.r.t. r5.physics.v10.0:
	bugfix in the target box initialization affecting X(Xo2) wire
	configurations,
	
the long awaited for same NRQCD kinematic weights implemented for Ti as for C.

executable built on 08/11/04
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20041108
kumac: hb_mctrig-rec.r5.kumac.04_11_2004
keybook 17
SLT executable sltsim42

Comment(s):
The bug in initialization of the X(Xo2) wire configurations set up
 the target box as for single wire runs when outer2 was meant to be in as a
 "spectator". It's been that way all along, i.e. in all earlier
 r5.physics.vX.Y versions.






r5.physics.v12.0
3 change(s) w.r.t. r5.physics.v11.0:
	use keybook 18 with updated link to the SLT target box table ([6:0])
	in which:
		the flt-seeded runs were deleted (see the email of Maaijke to hbanalysis from 22 Nov 2004)
		
a bug was repaired which caused the target box to be
		significantly off for runs 21243, 21244, 21297, 21298.
		These four runs are all b1o2 configuration.
	
	
change of the slt executable which however only affects simulation
	on raw data. For the record, the changes (neither of which affect mc):
		 adjust  z position of wires depending on run number
		
 allow reading of l2targ table for comparison with data
	
	
a bug correction in the flt code which generates roi's for the slt
	(/hb/slt/medinnis/patch3/fltarte/FltSim2ndTdu.C as of 01/12/04).
	The bug affected the initialization of the width of the slt roi's
	produced from electron pretriggers.

executable built on 01/12/04
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20041201 -> at_394
kumac: hb_mctrig-rec.r5.kumac.10_12_2004
       hb_mctrig-rec.r5.kumac.12_01_2005
keybook 18
SLT executable sltsim43







r5.physics.v12.1
1 change(s) w.r.t. r5.physics.v12.0:
	 user/usevnt.C enabled to apply X,Y,Z offsets to the GTAR positions
             at initialization. The offsets are passed via environment, e.g.
  setenv W_1BOT_OFFSET_Y 0.1
  setenv W_1BOT_OFFSET_X 0.1

 will shift the below1 wire position up and towards i2 by 1mm.

executable built on 08/06/05
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20050608
kumac: hb_mctrig-rec.r5.kumac.10_12_2004
       hb_mctrig-rec.r5.kumac.12_01_2005
keybook 18
SLT executable sltsim43







r5.physics.v12.2
1 change(s) w.r.t. r5.physics.v12.1:
	 reco/Geo_accept.C slightly modified in order to set the
	geometrical acceptance flag XTRI->bx for psi(2s)-ll in addition
	to J/psi-ll

executable built on 22/06/05
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/mc.20050622
kumac: hb_mctrig-rec.r5.kumac.10_12_2004
       hb_mctrig-rec.r5.kumac.12_01_2005
keybook 18
SLT executable sltsim43








ARTE-04-01-r5 mc branch "minbias"
r5.minbias.v0.
 The set of patches used on top of Arte-r5 correspond to the
 r5 mc branch physics v3.
 Note however, that this is my first try since 'repro-4' mc to run
 the minbias with a set of patches developped for triggered MC...

executable built on 11/04/04
HBVERS=ARTE-04-01-r5
reco-patch: lobotomized $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mb.20040411
kumac: hb_mcrec.kumac.11_04_2004
keybook 12


DG,20040121: sorry, we found a mistake in non-December minbias CnAkeys
   of mc keybook 12 with which r5.minbias.v0 usually was used, see the
   comments to mc keybook 12.




r5.minbias.v1
corrected non-December VDS masking.

1 change(s) w.r.t. r5.minbias.v0:
	The executable is that of r5.minbias.v0 - that's no change, but
	
use keybook 18 with corrected links to the VDS
masking tables, i.e. no HELIX mask as it was used for minbias runs in repro 5.

executable built on 11/04/04
HBVERS=ARTE-04-01-r5
reco-patch: lobotomized $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mb.20040411
kumac: hb_mcrec.kumac.21_01_2005
keybook: 18





ARTE-04-01-r5 mc branch "hardphoton"
r5.hardphoton.v0
Corresponds to r5 minbias vX.X with ITR enabled by
  
/RECON/SUBD ITR  ON

executable built on 11/04/04
HBVERS=ARTE-04-01-r5
reco-patch: lobotomized $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mb.20040411
kumac: hb_mcphot.kumac.10_09_2004




r5.hardphoton.v1
corrected non-December VDS masking.

1 change(s) w.r.t. r5.hardphoton.v0:
	use keybook 18 with corrected links to the VDS
masking tables, i.e. no VDS HELIX masks should be applied as it was used for real data minbias (as well as hardphoton) runs in repro 5.

executable built on 11/04/04
HBVERS=ARTE-04-01-r5
reco-patch: lobotomized $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p3
build directory: $HBROOT/RECO/misc/mb.20040411
kumac: hb_mcphot.kumac.21_01_2005
keybook: 18







ARTE-04-01-r5 mc branch "mcgen"

r5.mcgen.v-2.0
Arte-r5 with old table of branching ratios
executable built on 28/06/03
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/mcgen
kumac(s): hb_mcgen.kumac.13_06_2003.b1,
          hb_mcgen_D.kumac.16_06_2003.b2,
          hb_mcgen_dev.kumac.17_10_2003




r5.mcgen.v-1.0
Arte-r5 with updated branchings
at least 1 change(s) w.r.t. r5.mcgen.v-2.0:
masses and branching fractions updated, see mail from Achim to hbanalysis from 03 Jul 03
...

executable built on 23/07/03
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/mcgen
kumac(s): hb_mcgen.kumac.13_06_2003.b1,
	  hb_mcgen_D.kumac.16_06_2003.b2,
	  hb_mcgen_dev.kumac.17_10_2003




r5.mcgen.v-0.1
Arte-r5 with Hartmut's patch
at least 2 change(s) w.r.t. r5.mcgen.v-1.0:
Hartmut's patch to frit/fratleo.F compiled in
 bugfix by U.Husemann in J/psi and Upsilon mcme.wgth calculation (arte/alonia.F)
 ...

executable built on 18/10/03
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/mcgen
kumac(s): hb_mcgen_dev.kumac.17_10_2003
          hb_mctrace.kumac.03_09_2004 (for GEANT tracing)




r5.mcgen.v0.1
1 change w.r.t. r5.mcgen.v-0.1:
Kumac from Samo Kupper (~spengler/public/hb_mcgen_D.kumac.30_08_2005.b1)
 to be used for D_s generation.

executable built on 20/09/05
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/gen.20050920
kumac(s): hb_mcgen_D.kumac.30_08_2005.b1
          hb_mcgen_dev.kumac.25_09_2005




r5.mcgen.v1.0
2.5 changes w.r.t. r5.mcgen.v0.1:
a bugfix in arte/alpyth.F to reenable Rutherford parton scattering in
 the underlying event simulated by Fritiof (the Fritiof parameter KFR(7) gets
 reset to 0 internally by fritiof (in frit/frqprob.F) once the collision c.m.
 energy W becomes less than PARP(2) = 10.0GeV).
Implemented in an updated base kumac Samo's corrections (of r5.mcgen.v0.1)
 of the treatment of the decay matrix elements of vectors K*. and phi produced
 in decays of (pseudo)scalars and added a new process 245XX (D_s->K+ K0_S).
 Originally Samo corrected an old template kumac
 $HBROOT/RECO/mcgen/hb_mcgen_D.kumac.16_06_2003.b2 used for
 the opencharm mc generation in 2003. Here i only reimplemented his changes
 in a newer kumac template hb_mcgen_dev.kumac.17_10_2003 (which has more
 defined processes and updated branching ratios) which i called
 hb_mcgen_dev.kumac.25_09_2005.
 As Samo kindly explained to me (DG),
...In decays, where a (pseudo)scalar particle decays into a vector and a
scalar particle, like D_s -->phi pi, due to angular momentum conservation
the vector particle is generated in a state |S,Sz>=|1,0> for z-axis aligned
with the direction on of the pion (and the D-meson) in the vector�s rest
frame. For such a polarization the angular distribution of the vector�s
decay products - in respect to this z-axis - is proportional to cos^2 .
For directly produced vector particles, like in our case the D*, we can not 
determine this polarization axis. So it should not make any difference if we 
generate a flat angular distribution or a cos^2 distribution in respect to an 
unknown (and arbitrary distributed) axis...

And as Achim further clarifies about the decas of the promptly produced D*,
... The cos**2 distribution is produced in decays like
P0 --> P1 + V0 --> P1 + P2 + P3 because the vector particle V0 is polarized
in such a decay. In the decay of a D* the spin of the D+ results in an
angular momentum of the D pi pair, therefore there is nothing special in
such a decay. In case you are not satisfied with this answer, we have to ask  
Hermann; he is the real expert in these games...

(half a change): it was decided to use the half-string fragmentation mode
 (MODEFRAG = 2) as the default fragmentation for minbias opencharm mc
 generation. It was shown that this fragmentation mode gives larger average
 multiplicities which better match the data.

executable built on 25/09/05
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/gen.20050925
kumac(s): hb_mcgen_dev.kumac.25_09_2005


1 small known bug
In fact, as Sergey Shuvalov pointed out, the Pythia parameter PARP(2)
 gets also changed to PARP(2) = 0.9*W in frit/frqprob.F together with KFR(7)
 (see the 1st change of r5.mcgen.v1.0 w.r.t. r5.mcgen.v0.1 above).
 
According to the PYTHIA manual, PARP(2) (D = 10. GeV) is the lowest
 c.m. energy for the event as a whole that the program will accept to simulate.
 
Hopefully this bug is really very-very small for most cases.




r5.mcgen.v1.1
2 small changes w.r.t. r5.mcgen.v1.0:
Reset Pythia parameter PARP(2) after the Fritiof call for underlying event,
    this significantly improves the speed of generation by avoiding the cases when
    Arte hangs deep inside pythia called from fritiof.
    
Since it is expected by DG that the effect of the PARP(2) bugfix
        on physics is negligable, let's call this version r5.mcgen.v1.1.
    
Lam_c+ branchings added in the hb_mcgen_dev.kumac.28_10_2005 (taken from the default Pytyhia branchings of ARTE-04-01-r5)

executable built on 30/10/05
HBVERS=ARTE-04-01-r5
build directory: $HBROOT/RECO/misc/gen.20051030
kumac(s): hb_mcgen_dev.kumac.25_09_2005
          hb_mcgen_dev.kumac.28_10_2005


1 known bug PRESENT IN ALL MC GENERATED ON THE DESY ONLINE FARM!
During mc generation on the DESY online farm several nodes could get initialized
  with the same random seeds since the random number generator initialization routine arte/alrini.F
  relies just on timing and process PID and does not use e.g. the node IP number.
  
The complete table of the percentage of duplicated events in the generated and reconstructed MC sets can
  be found here.
  
The problem has been fixed for MCGEN runs >= 657 by improving the event logging software; also the duplicated
  events are removed during reconstruction for MCREC runs starting from run >= 1768.
  
Note, that this problem only causes a small underestimation of the MC stat. error: for a sample of N observed
  MC events with k*N duplicates, the MC stat. error should be sqrt(N/(1-k)) instead of sqrt(N). For majority
  of samples this is absolutely negligible since the fraction of duplicates k is on a few per cent level.












ARTE-04-01-r5 Real Data branch
r5.rd.v0.
The repro 5 real data reconstruction:
executable built on 09/01/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p0
build directory: $HBROOT/RECO/rp0005/src.20040105/
kumacs: rp0005_JulyMiBi.kumac
        rp0005_MiBi.kumac
        rp0005_star.kumac
keybook 30


r5.rd.v0.1

The reconstruction corresponding to repro 5 (loose online MUON masking)
  with MUON HITBs.
build directory: $HBROOT/RECO/misc/rd.20040212
  (ARTE-04-01-r5
   + patches from $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p0
   + changes in usevnt.C to drop all but MUON HITBs)
kumac: $HBROOT/RECO/misc/rd.20040212/rp0100_star.kumac
keybook 30





r5.rd.v1.0

Repro 501 reconstruction: repro 5 executable run with corrected ECAL calibrations in 2003 of keybook 31;
  
old wrong name: "r5 RD v0. with keybook 31".
executable built on 09/01/04
HBVERS=ARTE-04-01-r5
reco-patch: $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p0
build directory: $HBROOT/RECO/rp0005/src.20040105/
kumac:	rp0501_star.kumac
keybook 31

The 1 change w.r.t. the pure repro 5 version r5.rd.v0.:

  usage of keybook 31 with corrected ECAL calibrations in 2003.





r5.rd.v1.1

Reconstruction with the shower shape variables
   (not masking out the MC-dead muon channels from the RD...);
  
old wrong name: "r5 RD v0.2 with keybook 31"
build directory: $HBROOT/RECO/misc/rd.20040727
  (ARTE-04-01-r5
   + patches from $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p4
   + the new stuff from ARTE-dev)
kumac: $HBROOT/RECO/misc/rd.20040727/rp0102_star.kumac

build date: 28/07/04
build directory: $HBROOT/RECO/misc/rd.20040727/
kumac: rp0102_star.kumac
       rp0502_star.kumac, rp0502_MiBi.kumac.11_12_2005
keybook 31
The 3 changes w.r.t. the previous version r5.RD.v1.0:
 1) introduce the shower shape variables from Mauro and Sergey
 2) the triggered mc reconstruction patches from r5.physics.v5.0/v4.3
    misc/mc.20040603 or $HBROOT/ANALYSIS/reco-patches/ARTE-04-01-r5/p4
    excluding the murec (still questionable, moved back into murec-mc-rd-patch)
 3) harmless updates from $HB/dev/gean (read_dat.C,medmain.C,phevnt.C)


 The new e/gamma PID variables can be accessed through the utility
  functions from ARTE-dev/care (CareUtil.C and include/CareUtil.hh)
  // return the r value for PID purposed          1)
  float rValue(ArtePointer rccl);
  
  // return the c4 value for PID purposed         2)
  float c4Value(ArtePointer rccl);
  
  // return the c4Care value for PID purposed     3)
  float c4CareValue(ArtePointer rccl);




r5.rd.v1.2

Arte-r5 real data reconstruction with the RICH deutron ID
  
corresponding to rp0503 for Marko

build date: 22/12/04
build directory: $HBROOT/RECO/misc/rd.20041221
kumac: rp0503_MiBi.kumac
keybook 31

The 2 changes w.r.t. the previous version r5.RD.v1.1:
 1) Marko Staric introduced calculation of deutron id into RITER
 2) all the triggered mc reconstruction patches added from r5.physics.v12.0
    which should not cause any differences for reconstructing the real data.


 Comment by Marko on the deutron identification:

 ... The new code is runnig by default from Riter - no changes in kumac
  are necessary. The results are stored in the RTRA fields cer, txr and tyr, 
  which use to be filled by Rise. ...



r6.rd.v0

Arte-r6 real data reconstruction
  
corresponding to rp0006

build date: 29/03/05
build directory: $HBROOT/RECO/misc/mb.20050329
kumac: rp0006_MiBi.kumac
       rp0006_JulyMiBi.kumac
keybook 31


 Comment by Marko on the deutron identification (one of the major changes w.r.t. r5.rd.v1.2):

 ... The information is stored in:
(ARTE-04-01-r6)
  rtra->cer   cerenkov angle [radians]
  rtra->ecer  error on cerenkov angle [radians]
  rtra->lcer  significance of the signal (log likelihood difference)
  rtra->phcer number of photons in the signal

 ...






Production versioning principles

A 'version' is cooked physically up from the combination of all the sources,
the actual contents of all the libraries as of the date of build, the kumac,
the environment variables, and the set of calibration constants
(the keybook).

The present version classification is aimed to identify the few
'checked and approved' production versions and allow the analyst to
decide about the usability of the various data or mc samples
(and compatibility between them).

Production version classification is based on the following ideas:


The most well-defined point of the executable history obviously is
 the fixed Arte-release.
On practice the development and testing of the code and
 calibration constants is closely connected with the certain analysis tasks
 and can not be immediately validated for all the other analyses.
 Let's call in our classification scheme those separate developments
 the Arte production branches.
  All the branches start from the well-known Arte release;
     
 version numbering is done independently within each branch;
     
 branch version is a simple float number, the integer part of which
          identifying any significant changes, while the fractional part
          is used to enumerate features which may not cause
          inconsistencies for the analysis.
 
The version of calibration constans happily is our keybook and its
 classification from the user point of view fits well into the
 production-branch numbering described above (nevertheless please pay
 attention to the keybooks to be on the safe side!).



The description of a version consists of a short explanation, the list of
 the deliberately introduced differences w.r.t. some other known version,
 and the expert info (which should provide sufficient information for
 reproducing or judgement about the given sample by an expert) including the
 following items:


the number of the Arte release
the build date
the build directory with sources and README files
  (paths are absolute or relative to $HBROOT/RECO/)
the keybook number
the kumac template


Remark: the classification covers only the stable, 'production'-type
 Monte Carlo generation and reconstruction or real data reconstruction
 usable for the physics analysis; in case of the
 numerous tests no simple classification is often possible;
 for tests the issue of versioning hopefully is less important though.