Home » PANDA » PandaRoot » EMC » Forward calorimeter
|
|
|
|
|
|
|
|
| Hole geometry [message #4496 is a reply to message #4488] |
Thu, 14 June 2007 17:49   |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Hello,
I found maybe one "bug" in the createGeometry.C, thus in the geometry of the fsc.
I suppose the geometry is defined as the "Chicane" option. Here the position of the hole along X is centred at hole_xpos = -120.0 [mm] and not at 0.
But when the "crystals" belonging to the hole are rejected, I found:
if(TMath::Abs(curShift.X ()-hole_xpos)<hole_xsize/2+cellxsize/2 && ...
In this case the rejected area is from -12 cm to +12 cm, thus we reject 6X2 pads. This is not so clear to me, maybe the TMath is not needed there.
In each case, actually in PandaRoot we have the "straight" pipe, so the "hole" is the fsc region should be around 2X2 cm^2, thus only 2X2 pad missing.
I created one geometry file with this kind of setup, but before committing it I would like to ask confirmation from the experts.
|
|
|
|
|
|
| Re: Hole geometry [message #4501 is a reply to message #4496] |
Fri, 15 June 2007 12:20 |
Aleksandra Wronska
Messages: 38
Registered: May 2006
Location: Cracow
|
continuous participant |
From: *if.uj.edu.pl
|
|
Hi Stefano,
as for the fig. 8.88, it was produced by Piotr Hawranek some time ago. Unfortunately, he is unable to find the coefficients anymore. I see now three ways out in order to get a calibration:
1) take a ruler, measure the points coordinates and refit them,
2) more sophisticated: use g3data to get points coordinates, then refit them,
3) repeat simulations and recompute the correction factors.
If you can wait until Monday, I'll do 2) for you.
However, I see that you've started doing things which I wanted to do for Dubna. Can we split the tasks somehow? Any suggestions concerning things which need to be looked at?
As for the geometry, in particular the location and the dimensions of the hole, I still believe that my implementation was right.
I looked into the geometry created mith my old macro (still in the release 785). The picture looks differently from what you were showing, because the hole was not central!
Moreover, the rejected area is not, as you write, from -12 cm to +12 cm! The formula suggests that the gap in X is hole_xsize/2 ( because 2*cellxsize/2 is occupied by crystals adjacent to the hole) and is centred in hole_xpos. I do not see what is wrong with it.
The number of rejected crystals depends on the hole position and its size, which were the macro parameters. If you set the hole_xsize=200 and hole_xpos=0 you should get exactly the picture which you are showing as the second one. I assumed the chicane option because I wasn't aware that we only have the straight beam pipe implemented. However, as the chicane is the default solution right now, we'll have to work on implementation of it, too.
I created one geometry file with this kind of setup, but before committing it I would like to ask confirmation...
whatever you do to the geo file, if you retain the possibility to easily change the basic parameters (see above), it's fine for me.
...from the experts.
Whom do you exactly mean...? 
cheers,
ola
|
|
|
|
| Re: Hole geometry [message #4503 is a reply to message #4501] |
Fri, 15 June 2007 14:00 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Hi,
I was just trying to understand if the response in energy is OK or not, I have the feeling something is going wrong somewhere in the energy reconstruction, even because I am not so confident on the media.
In each case the reason of my large hole is quite simple. In order to have everything a bit faster and to follow the same code style of the endcups, I created 1/4 of the fsc and then refeclect it three times. So what was an asymmetric hole became something simmetric and larger, in the fsc.dat and emc_module12345.dat.
If the detector is asymmetric, I think one should think about something else.
In each case in PandaRoot the definition of the beampipe is coming from the file PndGeom/beamtargetpipe.xml of the fast reco framework, and there it is straight. If there is somewhere the tilted beampipe defnizion (xml file) then I can implement even that design, but I was not able to find it in the repository.
About the fsc geometry, it is too slow at the moment and one cannot plot it in a fast way. The reason is that each crystal corresponds to 300 layers, then 600 volumes (one per absorber, one per scintillator), and this number has to be multiplied by the number of crystals (28 X 14) -> 235.200 volumes. This is very heavy to load and to plot. I discussed with Mohammad and there is a way to increase the speed. Maybe we can discuss about it in Dubna.
In each case, at the moment the clusterization algorythm works with a symmetric design of the fsc->large hole, and putting the asymmetric one will require a bit of time (a complete redesign of the Mapper functions). For the moment I would prefer to not touch it, or at least before having also the other beampipe.
So, at the moment for the merged code we can use only the large hole symmetric hole, or I could reduce it and put the smaller one, or I could even close everything. Just tell me what do you prefer.
|
|
|
|
| Re: Forward calorimeter [message #4510 is a reply to message #4495] |
Tue, 19 June 2007 10:56 |
Aleksandra Wronska
Messages: 38
Registered: May 2006
Location: Cracow
|
continuous participant |
From: *if.uj.edu.pl
|
|
Hi Stefano,
I fitted the calibration points from TPR with a combination of 2 exponents and got the following parameter values:
TF1* fun = new TF1("fun","[0]*exp([1]*x)+[2]*exp([3]*x)",0.01,3.0);
fun->SetParameter(0,3.45);
fun->SetParameter(1,-4.82e-03);
fun->SetParameter(2,2.52e-01 );
fun->SetParameter(3,-5.1914);
The function is different that that in TPR, but is not worse to describe the data.
cheers,
ola
|
|
|
|
| Re: Forward calorimeter [message #4514 is a reply to message #4510] |
Tue, 19 June 2007 19:26 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Hello,
new changes in svn.
First of all, I corrected one bug: the absorber was defined as FscScint and not as lead. I corrected this error (of mine!).
Second, I implemented the "fast" forward calorimeter.
By usinmg the "usual" lines in the sim_emc.C:
CbmDetector *Emc = new CbmEmc("EMC",kTRUE);
Emc->SetGeometryFileName("emc_module12345.dat");
fRun->AddModule(Emc);
the geometry is loaded in the full (and heavy) way.
But one can turn on the fast option, with the following constructor:
CbmDetector *Emc = new CbmEmc("EMC",kTRUE,kTRUE);
Emc->SetGeometryFileName("emc_module12345.dat");
fRun->AddModule(Emc);
and everything should be faster, in particular for the geometry visualization.
The fast option seems to work but it is not fully checked, so probably it is better to use it only for "plots for presentations" at the moment (in theory even the clusterization should work, but I would not swear on it before testing, and now I am tired).
Under the fast option the geometry is hardcoded at the moment, it is symmetric and the hole is 2X2. The pad number is calculated converting the MC X/Y position. Changes will be done in order to be more realistic, but I do not think before Dubna (and before setting the Chicane beam pipe).
Plese try and tell me if everthing runs or not.
REMEMBER: Before the absorber material was wrong, so all the results could be misleading.
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 27 19:15:32 CEST 2024
Total time taken to generate the page: 0.00677 seconds
|
GSI Forum
Search
Help
Members
Login
Home
