GSI Helmholtzzentrum für Schwerionenforschung
Dear all, in SVN you can find almost all the EMC directory updated, in order to include the forward calorimeter (now module 5). Even the macros in macro/emc were updated. Now the geometry can be loaded with the fsc.dat file (only forward calorimeter), or emc_module12345.dat (with all the EMC modules). The macro to create the geometry file is macro/fsc/createDatGeometryFile.C . Digitization and clusterization are working such as in the target spectrometer. The energy in the cluster is quite low (photons at 1GeV -> 300 MeV), it seems in the forward part we have a high energy leak (g3), I do not know if it is correct or not (maybe some wrong media definition?). I would be happy if some fsc expert could take a look into what is happening, to check if everything is fine or not. Best regards
Dear Stefano Spataro, the forward calorimeter is a sampling calorimeter, so 300MeV sounds ok. Jan
Hi Stefano, I looked up in the TPR and ca. 300 MeV is exactly what's expected for a 1 GeV particle. It is due to the lead layers, which are dead material (as Jan wrote, fsc is a sampling calorimeter). I'll have a closer look at things beginning of next week. Thanks for merging fsc with emc! cheers, ola
Hi, I found the plot. I would like to chech if the correction factors of figure 8.88 are still valid for us or not. Where can I find the a b c d parameters of that curve? Could somebody write the values of those parameters?
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.
Just to show the differences. This is the actual geometry inside svn: This is what I have, reducing the hole: (grees in the fsc, magenta il the pipe in the target region, yellow is the pipe in the forward (fsc) and backward region).
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
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.
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
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.
Hello, I updated the fast construction of the forward calorimeter. Now the asymmetric design is there. The parameterts are at the moment hardcoded. I show you one picture with the meanings of the important parameters. The pipe is the "straight" one. It seems it does not overlap. One comment, to show all the pads one needs a visibility level of 6. Enjoy, from my side this is complete (hopefully).