Status of MC software

1. Status of MC software S.Dusini – INFN Padova Stefano Dusini

2. Beam File Simulation software structure Geant 4 VMC OpSim Detector simulation Geant 3 Fluka Particle Transportation Software OpDigit Simulation of detector response OpGeom Geometrical description of OPERA using ROOT geometrical package. All the package share the same geometry OpTriggerAfter this step MC should be undistinguishable from the Data Almost ready OpRec Stefano Dusini

3. Modification in the last (v3.1) software release • OpGeom • Updated the lead and emulsion geometry: Lead: 125 x 99.35 x 0.98 mm3, Emulsion: 124.6 x 99 x (0.044 + 0.205 + 0.044) mm3 • Inversion of the B field: (Bx, By, Bz)  (Bx, -By, -Bz) • OpSim • Interface to run with inverted magnetic field. • Updated the configuration file (ConfigMC.C) to use FLUKA to simulate hadronic interactions and to set properly all the Geant 3 parameters. • OpDigit • Corrected the RPC/XPC efficiency • Corrected TT fiber length (C.Cjollet) Stefano Dusini

4. Measurements • To check the geometry of the bricks I asked to Chiara to measure the size and the weight of lead plates. • She measure 50 lead plates using a caliper with a resolution of ± 5 μm, the thickness of the plates in 4 different points. The lead plates where weighed individually. • Other 50 lead plates has been weighed in groups of 10. Length in mm Weight in g.  Nominal size * 11.35 g/cm3 The difference in the x,y dimensions can be explain with deformation of the edge during the manipulation (cutting, bam operation….). But apparently there is a discrepancy between the weight loss and volume loss. Stefano Dusini

5. Possible interpretation • We can trust x,y measurements and absorb the additional 2% of weight loss in the Z dimension reducing the lead thickness by 20μm. • This means that 1.65 g are loss on the edge of the lead plate and 2.95 g from the surface. • The size of the lead plates are 125 x 99.35 x 0.98 mm3 • This new geometry has been implemented in OpGeom • The change in the lateral size has an impact on the acceptance which has to convolute with the emulsion acceptance (emulsion dim. 124.6 x 99.0 mm2) taking into account area that can be scanned with the microscope.  To be study with MC • The change in the thickness change the fraction of long tau decay and therefore has an impact of the sensitivity of OPERA. Stefano Dusini

6. The “saga” of the new MC production • A the begin of March we start the a new MC production at the Computing Centre in Lyon (see Elisabetta presentation at last Phys.Coord.) with OpRelease v3.1 and with new beamfile produced by Dario (/sps/opera/operap/beamfiles/march2009) • Simulation and digitalization run smoothly. OpRec was crashing on a method of OpGeom to calculate the amount of material between two point of a track. • This problem was not new and it was fixed with a trick which was working up to now. • Compiling OpGeom with a newer ROOT version (v5.23) I discovered ~160 illegal overlaps present in the geometry. Some where know and never corrected, but some where new and never detected by the production version of ROOT (v5.12). • Most of the illegal overlaps were involving dead material but the ones regarding the DriftTube need some mention due to the implication in the reconstruction. Stefano Dusini

7. Correction to the Drift Tube geometry • The volume which contain the last DT station of each SM was ovelapting with the volume which contain the magnet and the other DT stations. To the re-sizeing of the magnet volume I put back to the position prior OpRelease 3.0 • All the Drift Tubes were shifted by half tube radius to lower x values making half of the first tube of each layer was extruded from the mother volume. • These two changes have an impact on the reconstruction because the alignment files are correction to the MC geometry (and not true position). • The first and the second layer and thethird and forth layer have are staggeredby half tube and the distance in z less the radius of the tube. This was not properly implemented causing an illegal overlap between the DT layers. Stefano Dusini

8. The saga goes on… • After the correction of the geometry we found that OpSim was crashing simulating neutrino interactions in the bricks. Also this was a problem already found by myself one year ago and Lionel identify a possible source of the problem but didn’t how to correct. We fix it again with a trick. • In OpSim Lionel wrote a method in which he manipulate the “cache”, which is the in-memory run-time geometry to get a reference of the brick where the neutrino interaction took place in order to store only the emulsion hit of that and the neighboring bricks. • To me is not completely clear in what consist this “manipulation” but I rewrote the method to get the reference without the manipulation and now OpSim works. • I checked with 5000 numucc-DIS comparing the hit distributions with a old file and the distribution are reasonable. Full validation should be done by some one of the EmuRec WG. Stefano Dusini

9. The saga goes on… • Then I tested OpDigit on a small sample everything seems OK. • But OpRec was keeping crashing on the same method, the one to get the one to get the amount of material between two points. • After a short discussion with one of the author of the geometry package of ROOT he strongly suggest us to move to the latest ROOT release (v5.23). • Following the instructions of Dimitry Naumov, which did the same exercise with OpRelease3.0, I recompiled OpRelease3.1 (the latest) with ROOT v5.23. • The migration is not trivial and for the IO part because we use TRefArray to store the hit which have generated the digits and the use of these object has changed from ROOT v5.20. Andrey Sheshuk kindly provide me with two solutions we fix also this problem. I chose the easiest one although disfavored by Andrey. • With all these modification I succeeded to reconstruct two sample of 5000 numucc and taumu events without errors. I didn’t check yet the output. Stefano Dusini

10. Conclusions • In the last month we encounter several problems with the MC software. • In my view all these problems were pointing to a memory problem inside our software or the library which we use. • We first decide to look inside our code and fix what we think was necessary to fix. Then we decided to change the ROOT version and now all the problem seems to be fixed. • Unfortunately we do not have the “smoking gun” to understand who was the bad guy casing the problem. We have only indications that could be the ROOT library. • Some test are needed to settle this. • The jump from v5.12 to v5.23 is quite long but at the moment I do not see any other solution. Stefano Dusini

11. backup cm cm cm Stefano Dusini

12. backup Stefano Dusini