SSD offline status

Offline weekCERN, 7 July 2008

Enrico Fragiacomoon behalf of ALICE SSD

Run statisticsThe SSD was one of the detectors that participated in the majority of the global

runs (Panos). Calibration runs were extensively tested and used.

Many standalone runs to check:1. The DDL mapping2. The hardware/software adc map3. The output of the pedestal run

Global runs:1. In the same partition with the SPD, later with layer 3 and recently with part

of layer 4 of the SDD triggered by the SPD FastOR when SPD was able to provide it.

2. In the same partition with the TPC triggered by the combination ACORDE.OR.SCINTILLATOR

3. In the same partition with the rest of the ITS subsystems and TPC triggered by the combination FastOR.OR.ACORDE.OR.SCINTILLATOR

See https://twiki.cern.ch/twiki/bin/view/AliceSSD/WebHome

Top three debated items

Wrong coordinates on layer 6Overlaps in geometryMemory consumption of calibration objects

Wrong coordinates on lay6

The problem has shown up after reconstructing the cosmic data. No problem with simulations.

Recpoints coordinates on layer 6 were wrong! It looked like a local x->-x inversion but it was

in fact more entangled Due to a wrong assumption in the

segmentation (swapped stereo angles between lay5 and lay6) (see next slide)

How modules are installed in hw

LA

Y5 M

OD

UL

E

LA

Y6 M

OD

UL

E2. Moreover, readout from positive x!

Marco Bregant

1. Stereo angles (unlike in the sw) are the same but lay6 module is up-side-down!

AliRoot simulation modified according to the new local coordinates

Two classes modified: AliITSsimulationSSD, where the actual response simulation is

implemented: small changes -> stereo angles no longer swapped between lay5 and lay6

AliITSsegmentationSSD, where the details (e.g. stereo angle, width, pitch, ...) about the SSD module are plugged in GetPadTxz (which returns P and N strips for given local coordinates) has changed

Effective since trunk 26/06/08 and ported back to the v4-13-Release

Simulation and reconstruction are again compatible (see next slides)

Global x-y projection

Reconstructed pointGeant hits

Scale in cm

Simulated cosmic rays (muons) via AliGenCosmicParam class

Straight line fit through SPD points via AliEveCosmicRayFitter

Only SPD+SSD geometry shown

x

y

Note the many hits in y

Global x-z projection

x

z

Global z-y projection

z

y

Problems in the geometry

Volumes breaking the simulation! Due to volumes created with TGeoXTRU. Too many vertices gave unpredictable results (negative volumes)!

Overlaps (149) obtained with the “s” checking option. Many were repeated due to the hierarchy. Almost all of them have been fixed (see next slides), 13 remaining (see also Mario’s talk)

Many of the overlaps (39) due to a request of infinite precision

enrico.cattaruzza@ts.infn.it

Overlap Fixing Overlap between ITSssdSensor e Ladder

Segment

Replacement of Physical Mother Volumes withTGeoVolumeAssemblies (TGeoXtru Problem)

Overlap Fixing Overlaps between adiacent Ladder Segments:

fgkSSDTorelance variable has been introduced

Carbon Fiber Overlaps

Cooling Tube Overlaps

Overlap Fixing Overlaps between adiacent Ladder Segments and

EndLadder Segment: fgkSSDTorelance variable has been introduced

Cooling Tube Overlaps

Carbon Fiber Overlaps

Overlap Fixing Overlaps between adiacent ladders

Cooling Tube Overlaps

What Remains?

Overlap between Ladder Cables and Hybrid Flex

What Remains?

Overlap between LadderSupportAnd Layer

Top three debated

Wrong coordinates on layer 6 Overlaps in geometry Memory consumption of calibration

objects

Next-todo item

There are 1698 AliITSCalibrationSSD objects (one for each SSD module)

Each AliITSCalibrationSSD has pointers to the calibration objects AliITSNoiseSSD, AliITSGainSSD and AliITSBadChannelsSSD

Each of these objects has 2 TArrays of 768 values (as many as the strips on each side)

Simple implementation of the calibration scheme but memory consumption!

TArray to be replaced by arrays and one object for all the modules (in place of 1698)