Recent Changes - Search:

BookCrystal

InitFiles

NOT UPDATED to bookCRY

Book95: NA43 data reduction and translation program Book95's .ini files

Introduction

Init (.ini) files are meant to provide the Book95 program with all the needed constants. Almost none of the constants is defined in the fortran code (book95.F); instead the whole definition of the geometry and positioning of the drift chambers, and all the calibration constants are stored in these .ini files. This allows you to change things without having to recompile the program, and to make book95 use different calibration constants with different file sets. Furthermore, a reasonably simple method is provided to allow you to use the same method for the calculations that you may define in book95.F

Procedure

Here i just describe the order in which .ini files are read, and why. The content of the sections is detailed later.

Book95 - actually, dumread.c and book95.F - needs at least one initialization file. It will look for them in the following places:

   1. init directory, if any
      ( from --ini switch; no default)
   2. output directory
      ( from --out switch; default is ./ )
   3. input directory, if any
      (from input filename; no default )
   4. current directory
   5. default init directory, if any
      ( from [verbosity] inidir entry in an ini file; no default)
   6. book95's home directory
      ( from Makefile; defaults to the directory where it has been compiled)
   7. user's home directory 

Book95 will search a file with the name specified by the --ini switch or for the default one, called book95.ini. From this, before doing (almost) anything else, the section [verbosity] is read, by dumread.c; these values will not be changed anymore (most of these settings can be overridden by command-line switches) The other sections are read by d2n.c: [geometry] first, then [const] and [var].

NOTE that processing of any further .ini file can be disabled using the --noextraini option on book95 invocation.

Before starting to read the first dumle file, d2n.c looks for two ini files named after the "basename" of the dumle file(s), like aname.auto.ini and aname.ini for aname###.dml files. The aname.auto.ini file (that becomes .aut on a plain DOS partition) is created by the PAW macro calib.kumac. If any is found, d2n.c reads [geometry], [const] and [var] and from it. In case you want to put your run-specific constants, it's suggested that you don't modify the .auto.ini file but instead you create/modify the aname.ini, that is read after the .auto.ini , and so overrides its constants.

At this point, a check is made on the definition of Geometry constants, and a warning is issued if no Drift Chamber has been defined. Usually, the No Drift Chambers defined - get ready for a crash... is a correct guess...

Then, right before each dumle file is read, a file with its name, but .ini extension (like aname013.ini) is searched and, if existing, read, even if the corresponding .dml file is missing. Note, anyway, that only [const] is read from it - no changes in geometry, no changes in ntuple format.

Sections of an ini file

Now that comments (lines starting with #) are allowed in the ini files, there aren't anymore special reasons to comment the sections here. I'll only discuss things that are somewhat particular or long to explain.

[verbosity]

The lines here just describe how much printout you get when you run book95. You can override these settings using the command line options.

[var]

Contains things related to the content of the output ntuple, like pattern bits names, the selection of the raw and calculated variables to store, the flags for the special calculations.

  • pattern
    Pattern bits names: the order is (of course) very important.
    You could choose any name you like, but it must not collide with any other in the n-tuple: that's why, e.g., use plg1 instead of lg1.
  • raw
    selection on the "raw" part (plain ADCs and TDCs) of the ntuple: which of the readouts to include in the ntuple, and the names of the bits of the pattern.
    For the selection, the names are those that appear in the .dml file (defined in .cam file), removing spaces, underscores and dashes: dc4-x1 becomes dc4x1 (this because you would need to use quotes around them in PAW command lines, and this is really uncomfortable).
    You can use commas to separate entries; a + or nothing mean include, a - means exclude. Entries are processed in order, that means the second overcomes (if it is somehow conflicting) the first and so on: " *, -* " is like just the same as " -* "
    You can use the full GNU-regex syntax (like dc[34]x* : all the x of DCs 3 and 4 ). (do info regex for more info)
  • cal
    selection of which calculated variables you want to keep in the n-tuple;
    note that values can be discarded but there's no way to avoid them from be calculated - apart from modifying book95.F, of course.

[const]

This section contains values that are retrieved by the "user" code in book95.F Consequently, they are very much "free"; I'll only document those that are, by now, "standard":

  • B8_something
    are constants related to 1995's Bend 8, and are used in the calculation of electron momentum.
  • T6_something
    are constants related to 1995's Trim 6, and are used in the calculation of photon-generated electron-positron pair momentum.
  • calo_corr
    is the ratio between energy-Pe and calo. It is needed for the correction of bad DC4 ('95).
  • dc?_0
    are the constants ( that can be automatically calculated by calib.kumac) that specify a shift of the centre of the beam with respect to the nominal position. I suggest that you leave these undefined (=0) in the main init file, and you eventually override the values coming from the aname.auto.ini file using the aname.ini or the aname000.ini files.

A missing constant in the first ini file is considered equal to zero; this, if no check is present in user code, can lead to a crash of book95, p.e. for division-by-zero error. A missing constant in a non-first ini file just leaves the previous value. If you need to use/add/modify variables inside Book95.F, go to the Modifying Book95 chapter.

[Cuts]

Actually meant only to decrease file size of ntuples, not for the physics

  • declared in init files
  • all in AND
  • no expression

[geometry]

All the constants that regard the positioning and calibration of Drift Chambers are here.

The reference system is :

  • X -> Jura (~north)
  • Y -> up
  • Z -> downstream along the beam
  • origin usually chosen at intersection of beam centre with DC1

Global parameters:

  • ndc
    number of drift chambers
  • xdc_bits
    number of bits read out of ADCs and TDCs
  • wirex, wirey
    the positions of the physical wires with respect to the centre of drift chamber.
    Xa,Xb,Xc,Xd,Xe,Xf [cm]
  • signx, signy
    the drift directions (+1 or -1) for each of the physical wires.
  • dc1, dc2, ... , dc6
    positions of the centre of DCs in the absolute space:
    x,y,z [cm]
  • dc1cable, ...
    mapping of physical wires (a,b,c etc.) to the readout signals (dc#x1,dc#x2 etc.).
    The order decides the preferential order for hit search (first is stored in dc#x/dc#y, the others only in the multiple hit arrays).
    [letter][number], ... ;[letter][number]
    The ; (semicolon) separates the x and y series.

Drift Chamber parameters:

  • dc_cal_def
  • dc1_def, ...
    these define the defaults of the main parameters for Drift Chamber calibrations,
    globally or for the single DC. The order in unimportant: the "single DC" defaults always override the globals.
    <offset of 0>[cm],<drift velocity>[cm/channel]

Wire parameters:

  • wire_def
  • dc1_xA, ... , dc2_xA, ... ,dc1_yA , ... , dc6_yF
    These define the calibration parameters for the DC wires.
    <offset of 0>[cm], <linear term>[cm/channel] [see note], <quadratic term> [cm/channel^2], <min>, <max of window for accepting signal> [channel]
    NOTE: the first two parameter are NOT used for the global default .
Edit - History - Print - Recent Changes - Search
Page last modified on October 27, 2007, at 12:26 pm