• AndreaElog

Ok, let's start to write something. For general porpuse subjects I should write separate pages.

NB: tilde minus xxx minus tilde changes font. this is a test end of the test.

CosmicNotePlots page for Cosmic Note

SepAndreaElog

Rest of August

A summary of the validation work is in ValidationAlignTag1202

A summary of the Monte Carlo work is in MonteCarloStudyOn1202

August 17 and following days....

Wouter released in cvs his code after polished it. Also we moved to 12.0.2 that has the correct MC and other small changes (in geometry and track reconstruction).

Info on how to check out and run the code here.

Actually I nedded to do these extra steps:

1) Some package were not in InstallArea even though I gmaked them.  
Packages to gmake by hand:
    TRT_ConditionsAlg
      (with at update cvs update -r TRT_ConditionsAlgs-00-00-49 and 
modification of version.cmt)
    TRT_AlignAlgs
    TRT_DriftCircleTool
    TRT_DriftFunctionTool

2) Update of   InDetCosmicRec_jobOptions.py  (to account 12.0.1 -> 
12.0.2 changes) with
     cvs update -r 1.40 InDetCosmicRec_jobOptions.py

3)  Add these two lines on the top_Option file:
    ToolSvc.TrackSummaryTool.doHolesOnTrack = False
    ToolSvc.TrackSummarytoolInDetHelper.ExtrapolatorInstance = 
CosmicsExtrapolator.instance()

We spent some time in validate the new code. The goal is to find the same results between 12.0.0 and 12.0.2. In particular check the convergence of the iterations (that didn't work at the first shot).

August 16: CERN Day 8

Talked with Wouter and Fido about survey data. It seems Doug may know better, but from a rough calculation the twist seen in the assembly phace are too large on what we have

..... add details here .......

Found an error in MC

Polished some macro, not in a satisfactory way though

August 15: CERN Day 7

This is Wouter answer about the drawing of the two module sides:

Looks cool! At this point it would be intersting to collect some of the 
survey data, the nubers that should tell us how the modules are 
twisted. Do you know who has that information?

I asked Jack for info on who did the survey. I got the name I will contact her later.

MonteCarlo Study

Unfortunately the MC on 12.0.0 is not correct. It has a resolution worse then the data (already noticed a long time ago), something that was not present in 11.5.0. The explanation is a change in the scintillator that was not proper correct in the software. This determined a change in the TOF between layers and a wrong calibration done by the digitalizer. There is no way to correct for it unless to produce a new set of MC files. Already sent the request.

Hi all,
as most of you know, there was a problem in 12.0.x with the TRT residuals
being far worse than those of the SR1 data. Residuals before 11.5.0 was fine,
agreeing quite well with SR1 data.

The source of this has now been found: the plane at which the CosmicGenerator
generated cosmic muons changed in the simulation, and this lead to longer
arrival times for the muons.
The R-t relations was tuned on the old setup, so when the arrival time offset
changed, the residuals did too.

This will be fixed in later releases, but for now, if you want to get nice
residuals from simulation in 12.0.x, you should put the line:

TRTDigitization.Override_overallT0Shift = 375.45

in the end of InDetCosmicDig_topOptions.py in InDetCosmicSimExample. This
gives residuals of 288 microns.

I will let you know once a more elegant solution to this exists!

cheers,
Ola

Hi Ola,

Do I understand correctly that you can apply this fix only if you rerun 
the digitization? In that case we should probably ask Sofia to rerun the 
digitization for us on the MC that already exist, right?

Thanks,
Wouter

Hi Ola,

> > yes, the files needs to be digitized again with the new setting. However, the
> > files simulated with 12.0.0 also contains the bug with the geometry clash
> > between ID and an unitialized scintillator, causing the loss in efficiency in
> > the bottom sector, so she will simulate a new sample with 12.0.2 anyway.
> > If its ok for you with the efficiency loss in the bottom sector, then Sophia
> > can probably digitize the 12.0.0 files before running the new 12.0.2?

I rather have the right simulation. Sofia, do you plan to generate the 
new MC data soon? For the TRT we need only 10k events or so ...

Thanks,
Wouter

Since it's difficult to disantangle all the possible source of misalignment and what can cause the pattern that we observe (it is real? is a bias of the method? is an internal mis. of the SCT?), one good approach is to use the Monte Carlo to artificially introduce misalignment/effects and study how they propagate to the observable we plot in the data.

Ideally we might be able to have a list of distortion effects and associate to each of them the resulting misalignment outcome. In this way, with this list or table at hand, once we find something in the data, we can look up there and have an idea on which effect could have been involved and which are not.

Preliminary excercise: First of all we have to check is if our procedure is biased. Starting from the nominal geometry without any misalignment we run our program. Since there is no misalignment all the parameters should give numbers compatible to zero (within errors).

Plot Comment: We can see that for x we get a fairly zero parameters(one or two sigma are not so bad). However for the phi we see a much bigger effect. The parameters are large and of the same size of the alignment constant we see in the data, altough the errors are big as well.

What happen if the global alignement in the data is worng? We introduced it to fix the TRT-SCT misalignment, but if we were wrong how this affect the final internal alignment? To have an hint on that we can introduce a rotation of 0.3mrad (as in the global alignment) along Y. This should give us a feeling of the pattern that we can expect if we made the global al. wrong.

Plot Comment: For the x it is what more or less we expect. We had no clue on the magnitude but such a rotation actually affect more inner layers and outer layers. Indeed the silicon is fixed, then the track si pulled away more by the outer layers, and therefore the residulals are worse for the inner layers. Also the left side and the right side give exactly opposite contribution.

Phi gives us an harder time to understand. Module 6 and 7 look different, no reason for them to be. Module 7 in particular is pretty bad.

What we can say is that this kind of misaligment cannot give the crazy pattern we see in the data, with layer 0 and 2 crossing by.

August 14: CERN Day 6

Full Rotation or Relative Rotation ?

Each iteration modifies the postion of a module in order to improve the residual mean. The change w.r.t. the previous iteration is recorded in trtalignlog.txt: these are the relative transformation.

However in the end what counts is the total transformation, defined as the sum of all the trasformation occurred at each iteration. That is the misalignment and that is what goes in the database. It is recorded in alignmentoutput.txt:these are the total trasformation

In the plot I made I used the relative trasformation. This is clear by looking at the whole-barrel points. They are basically zero because after 9 iterations we reached the stability, i.e. differences between the previous and the following iteration are negligible.

Now for the split points we get about 0.2mrad in relative rotation. This is almost the same magnitude of the entire rotation. Hence, if we combine the total rotation plus a comparable relative extra rotation we do not know where we end up with.

In fact from alignmentoutput.txt we have after 8 iteration:

/TRT/Align/TRT
-1 0 0 -0.29025 -1.71513e-05 8.44026e-06 -1.57099 0.000276638 1.57074
/TRT/Align/B0
-1 0 6 0.195352 -0.121521 0 -0.00022389 0 -0.00022389
-1 0 7 0.1279 -0.040627 0 -0.000130782 0 -0.000130782
-1 0 22 -0.39568 0.196793 0 -0.000361902 0 -0.000361902
-1 0 23 0.242776 -0.06498 0 0.000208076 0 0.000208076
/TRT/Align/B1
-1 1 ...
/TRT/Align/B2
-1 2 ...

This is the kind of file that goes in the database. It reports the total alignment parameters. There are 6 numbers:

There are of course 6 degree of freedom, 3 for traslation and 3 for rotation (Eulero's angles). All of them are respect to the center of the detector. For traslation doesn't matter but for rotation change the things quite a lot.

The first raw /TRT/Align/TRT gives the global transformation of the barrel. For instance now those numbers are calculated with a global alignment w.r.t. the SCT. It can be noticed that 90 degree. Now it's weird that the barrel is so misaligned to start with. In reality this is an example of why we should be very careful when reading the Eulero angles. In fact fot theta~0 we have phi_polar = -(phi+psi). In our case therefore phi_polar is very small (global correction of the TRT w.r.t. SCT), as it should be.

To transform from the Euler angles to the rotation around the cartesian axes (x,y,z):

void extractanglesfromeulerangles( double phi, double theta, double psi )
{
  TRotation r ;
  r.SetXEulerAngles( phi, theta, psi) ;
                                                                                                                                
  std::cout << "rotation about x-axis: " << asin( r.YZ() ) << std::endl ;
  std::cout << "rotation about y-axis: " << asin( r.XZ() ) << std::endl ;
  std::cout << "rotation about z-axis: " << asin( r.XY() ) << std::endl ;
                                                                                                                                
}

The other raws /TRT/Align/Bx refers to the layers.

Other patterns:

• At the moment we just align for local phi and translation along x. However a local rotation is defined as a (global rotation + translation). This is why we have dx different from zero. It has to compensate the global rotation to put the module back (but rotated!). If this is true it's clear that the global angle and the dx must be same signs. This is indeed true!! For the bottom sector instead just opposite signs.

• The same argument holds for dx, but it has also a real alignment included. If we want to know the actual dx displacement we need to disantangle the two components.

• If we call

Rotation of negative and positive side visualized

It's important to visualize the total rotation of the two sides because the relative rotation reported in the plot ... is almost of the same magnitude

I have modified the Wouter code to make the visual plot about misalligment. Now I can run multiple files in parallel and have them superimposed. The macro is drawmodulepositions.cxx.

Plot 1:

• green is the negative side

• red is the positive side

• black is the whole barrel

The bottom sector doesn't show any difference as expected (no instrumented on the negative side)

Zooming on the top sector we can appreciate the difference between the rotation of the two sides. For the layer 1 the two sides are actually rotated exactly of the same amount (and therefore the whole barrel as well). The yesterday plot on the relative rotation is translated now in a full rotation plot.

August 12: CERN Day 5

I probably have understood the weirdness reported yestarday about the whole-barrel points. The split points come from an interation that has as a input the output of the last whole-barrel iteration (n. 8 to be precise). Therefore the split points have an extra iteration. For a fairer comparison I should go on and make another iteration also for the whole-barrel points.

This is the new iteration plots with 9 iterations

The last points are the reference now. I took them and split in two positive and negative side (for the top sectors 6 and 7).

Now the whole barrel points (yellow) are in between the splitted points! Moreover the bottom sectors has the split and the whole-barrel points in the same position, as expected.

These plots are really funny, that's something strange going on here.I'm not sure if it's just a bug in the code or some real effect (difficult to believe). Since we set the alignment w.r.t. the silicon, it is possible that a SCT misalignment screw everything up for us. Emailed Wouter for advices, but he's on vacation....

August 11: CERN Day 4

Actually Wouter confirmed that half of the bottom sectors were not instrumented. Plus we made some comment just looking and the log file of the job (!!)

Hi Andrea,

That's very quick! Indeed, the bottom sector has only one half
instrumented. To present the result you could maybe plot 'dx-pos:dx-neg'
for each module. That way we'll see if there is any correlation at all ...  

That looks quite reasonable actually. It seems that for every module the
change in x and phi are more or less the same size but with opposite sign
(if significantly different from 0). This is what you would expect if the
existing alignment is the average of the two module halves. The
differences in x are significant but small compared to the hit resolution
(about 0.3 mm for the cosmics). The differences in phi seem significant
and large only for 7-0 and 7-2. (0.1 mrad is quite large; 0.01 is small.)

Cheers,
Wouter

Now the challange is to modify the macro and make the plot nice.

Here is the first attempt for the split barrel plot (for dx):

Note:__ These plots are for the dx displacement only. Each plot is a sector (6,7,22,23). For each sector the three layers are shown. For each layer there are the positive, negative and the whole-barrel alignment constant after the last iteration (iteration 8 in the iteration plot).

Unfortunately the whole-barrel points are not sandwiched between the pos and neg points !! That's weird...

August 10: CERN Day 3

Run over the code with the split option on. As input alignment I used the the last iteration I generated before without the split. Therefore the modules-as-a-whole are aligned (last point in the iteration plot below). Now with the split there are two possible scenario:

1. The resulting misallignment of the two halves of a module are inside (or close) to the misalligned error of the entire module. In that case we want to increase the statistic to reduce that error and see what happen.
2. The two-halves misallignment are far away (probably one on top and the other on the bottom of the whole-module point). In this case the first thing is to see if there is a pattern (all the modules present the same features or just few module are off and other modules are ok). In case all modules present a misallignemnt after the splitting, there is probably a bias on the method we use. We'll see...

Ok, first results on the splitting:

Not the best way to plot it but it gives an idea... There is no 'left'-half for the botton modules, not sure why yet (not instrumented?)

August 9: CERN Day 2

Spent all day basically to go trough Wouter code and try to make sense of the all routine flow of. In particular it is really difficult to follow which are the Algorithms used and in which order. For example I was puzzled by the fact that the main piece of code, the AlignAccumulator, has the execute() part missing. It is initialized at the beginning of the run and finilized at the end. So no event entry, in CDF jargon. The point is that all the routines are nestled. For instance: there is a member function of the AlignAccumulator package that is meant to run as event entry. But it is not called by the AlignAccumulator class. It is called by another class, AlignMgr. Therefore if you look only at the AlignAccumulator you wonder why that routine is there at all, since it is never called by AlignAccumulator. In other world it's a real mess until you don't get a clear broad picture of what it's going on. And you have to know all the package that are actually used and look at them all in parallel. That is what I did today.

Also I implemented the split option in the Wouter code. If that flag is on the barrel is treated as two separated halves. The main goal is to understand if there is a misalignment between the two. Or if we have the sensitivity to see that misalignment.

August 8: CERN Day 1

Back to CERN (fantastic flight, plane half full, lot of room, lot of sleep, nice movie... )

Talked with Wouter about future task list, but first of all he fixed the error on his macro running. To make the iteration plots (pag.26 ID week talk) he uses the macro drawconvergence.cxx. However I got

root [0] .L drawconvergence.cxx 
root [1] drawconvergence(1,8); 
Error: non class,struct,union object moduletransforms[id] used with . or -> drawconvergence.cxx:61:
*** Interpreter error recovered ***
root [2] 

The problem is the cint interpreter don't recognizing complex c++ code, like map that Wouter heavly uses. The fix is to compile the macro:

root [0] .L drawconvergence.cxx+
root [1] drawconvergence(1,8);     
Info in <TCanvas::Print>: eps file internalalignmentconvergence.eps has been created
Info in <TCanvas::Print>: ps file internalalignmentconvergence.ps has been created
Info in <TCanvas::Print>: GIF file internalalignmentconvergence.gif has been created
root [2] 

then from the second time just use the compiled library:

lxplus062:{16:37}:~/trt/Tracking2-12.0.0/InnerDetector/InDetExample/InDetCosmicRecExample/run>root
root [0] .L drawconvergence_cxx.so 
root [1] drawconvergence(1,8);     
Info in <TCanvas::Print>: eps file internalalignmentconvergence.eps has been created
Info in <TCanvas::Print>: ps file internalalignmentconvergence.ps has been created
Info in <TCanvas::Print>: GIF file internalalignmentconvergence.gif has been created
root [2] 

Here are the plots I got now:

They are not the same as Wouter ones. Reasons still to be understood. I just got a different set of alignment on the first iteration, actually on the first event. Two hypotesis:

1. Wouter has a different track selection (which he changed later before I copied the code)
2. I use the globalalignemnt parameters as input of the first iteration while Wouter on the first iteration runs the global and local alignment at the same time (to get the global that I instead have copied from him) and has dummy parameters as input.

TO DO: To rule out 2) I can run one iteration using as a input Wouter alignment output of iteration (n-1). If I obtain exactly the same output of his n iteration that would mean we have the same code (i.e. track selection)

Then we discussed how to proceed with the two-halves barrel study. The strategy should be something like this:

1. Double the number of modules in the code (changing the numbering scheme to let say 1_6_0,-1_6_0)
2. Assign the hits to the right half

3. Make one iteration using the full-barrel last iteration constants as input. In this way we are at the last point of the iteration-plot. If the two halves are consistenly aligned, the splitting should provide two new points inside the error of the full-barrel point. If they differ significantly, there is something to be understood.

• Note: in that case we cannot infer that there is a misalignment between the two halves. A silicon misalignment can mimic that effect. It has to be noted that at the moment the Geometry does not allow to modify the position of the two barrel halves separately. That means no iterations. Unless we rotate the whole barrel to allign just one half; the second half just follows the movement of the first half. In this case we should ignore the tracks on the second half (what about overlaps?)