Linear Collider Forum

Home » Analysis and Reconstruction » Tracking & Vertexing » Conditons Data for MarlinTPC
Conditons Data for MarlinTPC [message #1458] Fri, 02 May 2008 04:48 Go to previous message
Messages: 125
Registered: July 2005
Location: CERN
In preparation for data taking with the large prototype (LP) TPC I would like to present the current status of the TPCCondData (lccd/lcio conditions data objects in the MarlinTPC package) and discuss what has to be changed/implemented.

Current status (MarlinTPC r1076):
  • ADCChannelMapping
    Mapping of H/W channles to GEAR pad indices
    • ChannelID
    • PadID
    • Type
  • ChannelCorrection
    Per channel calibration
    • Quality flags (broken, noisy)
    • Calibration factors
    • Time offset
  • Pedestal
    Per channel
    • Value
    • Width
  • TPCConditions
    Calibrated TPC Parameters
    • DriftVelocity
    • Diffusion (trans/long)
    • "Defocussing"
    • Amplification
  • GasConditions
    • Mixture
    • Pressure
    • Temperature
    • OxygenContent
    • WaterContent
  • FieldSettings
    • Nominal drift field
    • Nominal B-Field
    Especiall for GEMs
    • GEM voltages
    • Transfer fields
  • WeatherConditions
    • Temperature
    • Humidity
    • Pressure
  • TimePixPixelMode
    • Mode
    • Status (broken/noisy)

Results from the LP software meeting on 2008-04-30 fId=2692:

  • The readout specific items ADCChannelMapping, ChannelCorrection, Pedestal and FieldSettings need a ModuleID to be able to handle multiple modules
  • The FieldSettings need information whether GEMs or Micromegas have been used, and store the Micromegas voltage.
  • The FieldSettings will be replaced by VoltageSettings, which is the more basic information. A handler implemented as LCCDChangeListener will provide the field settings and can recalibrate the fields in case improved information on the cathode position or GEM spacing is available.
  • Data objects for TriggerConditions (cosmic or beam trigger, which scintillator slab has fired) and BeamConditions (particle typ, particle energy) have to be defined
  • The magnetic field map and the map with electric field distortions are stored as conditions data (detailes description see below). There is a B-Field in GEAR, but it is only a homogeneous field. Especially the E-field can change due to ion backdrift, so it cannot be stored in the geometry description.

The magnetic and electric field consist of a simple conditionsdata class to
store the field on a 3D grid
  • 3 ints (x, y, z) for the voxel index
  • 3 floats for the field in x, y ,z

The grid infomation (coordinate of voxel 0,0,0 and bin width in x, y, z) are
stored as collection parameters.

Handler classes allow simple access to the fields (for instance
MagneticFieldHandler::getMagneticField(float *position)). These handlers
update the fields and perform the overlay e. g. of static electric field and
field distortions from ion backdrift. As an example the proposed class
structure for the magnetic field is attached. Actually the design has already
been improved wrt. this image: getMagneticField returns a struct with the three
values instead of a pointer to simplify the memory management.

Proposal: The E-field and B-field classes and the handlers should not be
stored together with the other conditions data but have a separate section, so
one does not always have to link the whole, rather large field-handler package.

Martin Killenberg

Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic:Fitting scheme
Next Topic:Hit errors in MarlinTPC
Goto Forum:

Current Time: Sat Feb 22 08:18:26 Pacific Standard Time 2020
.:: Contact :: Home ::.

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