Status of MC software

S.Dusini – INFN Padova

2/4/2009 Stefano Dusini 1

Simulation software structure

OpGeomGeometrical description of OPERA using ROOT geometrical package.

Beam File

OpSimDetector simulationGeant 3Geant 3 FlukaFluka

Geant 4Geant 4VMC

Particle Transportation Software

OpDigitSimulation of detector response

OpTriggerAfter this step MC should be

undistinguishable from the Data

Almost ready

OpRec

All the package share the same geometry

2/4/2009 Stefano Dusini 2

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)

2/4/2009 Stefano Dusini 3

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. x y z

Nominal 125,55± 0,05 100,05± 0,05 1,00± 0,01Measured 125,0± 0,1 99,35± 0,04 1,02± 0,02Diff 0,59 0,5% 0,70 0,7% -0,02 -2% Average 1st batch 2nd batchNominal 142,6 ± 1,6 Measured 137,9 137,2 ± 0,8 138,5 ± 0,5Diff 4,7 3,3%

Length in mmWeight in g.

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.

Nominal size * 11.35 g/cm3

2/4/2009 Stefano Dusini 4

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.

2/4/2009 Stefano Dusini 5

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.

2/4/2009 Stefano Dusini 6

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.

2/4/2009 Stefano Dusini 7

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.

2/4/2009 Stefano Dusini 8

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.

2/4/2009 Stefano Dusini 9

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.

2/4/2009 Stefano Dusini 10

backup

cmcm

cm

2/4/2009 Stefano Dusini 11

backup

2/4/2009 Stefano Dusini 12