The survey locations should also be checked by the detector groups against internal surveys of the detector as built. The details required to coordinate the fit are located in the "Maus_Information.gdml" file contained in the CDB entry. In the "Detector_Information" field there is a list of the detectors to be used in the simulation. Each entry contains the reference to the ideal position of the detector according to the CAD geometry and a list of the corresponding survey nests. Each entry in the list of survey nest contains the reference to the position of the nest in the CAD-based geometry ("gdml_posref") and the position of the nest with respect to the centre of the detector as it is defined in the GEANT geometry description. I have based a subset of the TOF information on the positions derived from an internal measurement conducted in 2010 (prior to the application of the current survey nests) and the rest of the data are based on the surveys conducted since the summer of 2013, with the consequence that the current fits are in essence tests of the hypothesis that the fit introduces no change in the detector position.

Better numbers should be entered into this field.

This item needs to be dusted off and reviewed within the next week. The goal is to have an "official" geometry ready next week.

To review, the tasks that must be completed by the designated detector experts

• Download and install the latest version of MAUS (0.9.6)
• Download the latest geometry (id 53) using the instructions given here
• Check the .dat files generated from the geometry.
  • Compare the file to the expectations of the detector dimensions.
  • Report any deviations to RB.
  • Note that this geometry has no absorber. LiH absorber can be found in id 52, and the lH2 absorber is used in id 51.
  • The experts of the EMR and the Ckov should double check the GDML files.
• Run a simulation of some significance to test the output of your detector.
  • Check that the reconstruction "looks" right. This could include energy deposition, clustering, or reconstruction
  • Not applicable to the Ckov
  • You should use the option "simulation_geometry_filename = <download directory>/ParentGeometryFile.dat"
  • Note that the origin for the geometry is inside D2 --- the default spill starting point will not enter the beam line so the starting point must be changed.

A report should be posted to this issue.

Mariyan has already pointed out some issues with the KL geometry. His issues were with module names (some of which were changed or expanded to allow for the use of the GDML) and material definitions. He says that the legacy files are correct and I should be able to find the differences. Looking at the files myself, I note that the top level file for the KL in the legacy geometry does not have any material defined, and the KL Fibres and KL Glue have their materials defined explicitly (BC600 and polystyrene respectively) where I had defined these volumes to be filled with air as well (there is a reason for this; let me get to it).

I defined the top level volume to be filled with air, because I needed to define something for the GDML file. I suppose that in the MICE modules the default is "galactic" by whereas the default should be "air" about the KL.

For the Glue and Fibre volumes, I first of all note that the simulation uses the GDML to define the geometry --- not the MICE modules. This is especially significant for the KL, EMR and Trackers which have historically used the G4Detector volumes, but now use the definitions contained entirely in the GDML. The definition for the Glue and Fibre materials are contained in subfiles that are called by the main GDML file for the KL, but are not translated into MICE modules. The use of "air" in the base files was done mainly to ensure that the glue and fibre volumes did not interfere with each other while occupying the same volume. In other words this is a solution to a technical problem of rewriting the module using GDML compliant objects. What is required is a comparison of the energy loss and deposition of the two implementations of the KL to ensure that the technical solution did not make a mess of the physical properties of the detector.

This is a direct response to Chris' note. I would remind people that I did not generate these geometries as a final "as built" geometry --- the data has not yet been provided for that. Rather I wanted help validating the detectors.

1. Step size is initially set in the ParentGeometryFile (which is written using the ParentFileCreation.xsl style file in src/common_py/geometry/xslt) but some of the other step sizes may be defined locally (I will double check).
2. Materials ** The galactic upstream of the tracker is due to the default material in the channel volumes being galactic. The volume between the tracker and the diffuser is poorly defined and so I have neglected to fill it with He gas to date. It is possible to create a simple volume to fill this region, but I am wary of introducing potentially overlapping volumes.
   • The galactic between the upstream tracker and the tracker window is filled with galactic for the same reason.
   • This geometry was meant to reproduce a non-specific Step IV geometry which fills the tracker with helium.
   • best as I can determine, the windows come from the CAD geometry so I think they are supposed to be there.
   • I will have to look at these windows. I do not know about these windows.
3. Fields
   • Solenoid coil geometries are drawn from engineering drawings generated last year. I have been promised the updated CAD files but they have not yet come.
   • Okay.

Thanks Ryan.

Step size is initially set in the ...

I tried taking this out; neither the configuration.py or the G4StepMax seems to be being used. Does this means that stuff in src/common_cpp/Simulation/DetectorConstruction is not being propagated down into the GDML? Things like production thresholds and so forth as well?

Materials

Does that mean we are missing the Helium window between diffuser and tracker? Otherwise I think it is clear, it should be Helium on the inside of the window and Air on the outside.

Fields

I think fields should be treated as "special", like the detectors are. We are trying to figure out e.g. coil dimensions when cold, scaling factors due to the PRY, etc. I don't particularly care about where the material is, but the actual field maps I don't think should come from the CAD - I think they should come from Victoria (who talks to Jaroslaw et al).

I have looked into some of the outstanding issues raised by Chris;

1. Maximum step size: The only place where this was set was in when sensitive detectors were defined. I changed the algorithm which parses the auxiliary information from the GDML files to catch the Maximum Step Size (and a few other things) and apply those qualities to the associated logical volumes. The default value for these values are taken from the configuration file, not the ParentGeometryFile. I produced a new maus branch (lp:~ryan-bayes/maus/1439) containing the changes I have made to the code.
2. Materials: Based on discussions that I have had recently there is no window between the diffuser and the tracker. I still need to put a helium volume between the tracker and the diffuser and an air volume outside of the diffuser.
3. Fields: I misspoke; the coil positions were taken from an early draft of Victoria's as built geometry from last summer. The coil dimensions, however are wrong, and I have corrected them in a draft geometry.

The outstanding issue is the KL. Marian tells me that the KL is not producing hits. This may be my fault because I had to extrapolate from his detector description somewhat to make something that worked in the GDML. I need to do some debugging (if not me then who) to figure out how to fix this.

I am very sure that the Tracker and TOF descriptions are correct, and I think Francois gave his approval of the EMR description (I haven't looked at the digits myself). The Ckov digitization is of course still in progress but the GDML description matches what exists in the legacy.

• So far I believe that I have noticed one issue with the GDML file for the EMR geometry in the following loop:

<loop for="xp" step="1" to="48">

<physvol>

<volumeref ref="EMRPlane"/>
<position name="Plane_pos" unit="cm" x="0.0" y="0.0" z="xp * (1.7 + 0.05) - 42.0"/>
<rotation name="Plane_rot" unit="degree" x="0.0" y="0.0" z="mod2[xp + 1] * 90.0"/>

</physvol>

</loop>

As the EMRBar in EMRBar.cc (DetModel) is defined along the X axis, it would mean that the first plane would have the bars parallel the X axis, hence providing the Y coordinate, which is incorrect. If the loop was from 0 to 47, that would be correct (see BarParameterisation.cc in the DetModel files). I haven't gotten a chance to look at the hits yet but if nothing major has changed to should be ok. I will look into it.

• Regarding KL, Mariyan told me that, if he put the EMR further downstream, he would get hit in it. Apparently, if both detectors are in their correct positions, he gets hits in Galactic for the EMR, which makes sense as the EMR box (defined in EMR.dat) overlaps the KL. I am not an expert, but how are overlaps between detector boxes handled? The EMR box size could be reduced to around 120 cm in z, preventing the overlap.

I changed the loop to go from 0 to 47 in the EMR file. For a reference on how the loop type is supposed to work see page 32 of http://gdml.web.cern.ch/GDML/doc/GDMLmanual.pdf. I presume that this also means

To correct the plane rotation it should be enough to replace "mod2[xp + 1]" (which will return 0) with "mod2[xp + 2]" (which should return 1).

Finally, I will try reducing the z dimension of the EMR to 120 as suggested.

All of these changes will go into a test geometry that I will put into the preproduction database tonight.

Thank you Ryan.

• Other minor correction, to have the origin of z exactly in the centre of the detector, this line needs to be changed too:

<position name="Plane_pos" unit="cm" x="0.0" y="0.0" z="xp * (1.7 + 0.05) - 42.0"/>

to

<position name="Plane_pos" unit="cm" x="0.0" y="0.0" z="xp * (1.7 + 0.05) - 41.125"/>

With the previous configuration, one of the plane would be perfectly centred at the origin of z, which is impossible as there is an even number of them.

• You can also change it to "mod2[xp]" for that matter, but that would alter the position in z. In order to have the first plane at -41.125 cm, please keep mod[xp+1] and loop over xp from 0 to 47, which is also more consistent with BarParameterisation.cc.

Will you let us know when you have made a new release so we can look at it again? Thanks for all your hard work!

Francois

I agree with this suggestion

<position name="Plane_pos" unit="cm" x="0.0" y="0.0" z="xp * (1.7 + 0.05) - 41.125"/>

"mod2" is an array (not a function) that consists of alternating 0s and 1s indexed from 1 to 60 such that mod2¹ = 0 and mod2² = 1 (which looks funny I know, and I appologize). To start with a plane producing an x-coordinate the first plane needs to be rotated 90 degrees about z and we need to introduce a multiplier of 1 to the rotation angle, which can be produced using mod2[xp+2]=1 when (xp=0). The subsequent plane has no rotation because it measures the y coordinate which can be achieved by setting mod2[xp+2]=mod2[xp]=0 when xp=1.

I know this is a little confusing, but I did work this through before. I could make it a little less confusing, but then I would have to change the bar rotation in the plane because it uses a similar mechanism.

I have made a new geometry on the pre-production database that contains all of the recommended changes to the detectors. If people have some time to look at it, the geometry is posted as id 608 on preprodcdb.mice.rl.ac.uk. Problems with the KL, EMR, and filling various volumes have been addressed. To make some of the changes work (primarily anything pertaining to G4 step size limits) a fix to MAUS contained in lp:~ryan-bayes/maus/1439 that allows the step size to be read from the GDML (and sets the step maximum to a value specified in data cards otherwise).

Thanks Ryan, I will have a look. Just for my clarity, do you support all of the following datacards/geometry things in the GDML?

everything_special_virtual
fine_grained_production_threshold

G4StepMax vs max_step_length
G4TimeMax vs max_track_time
G4KinMin vs kinetic_energy_threshold
G4TrackMax vs max_track_length

Hi Chris,

The short answer is yes.

• "everything_special_virtual" is used in the "BuildSensitiveDetector" method in "DetectorConstruction" that is used for the definition of the sensitive detectors in the GDML so that carried over without anything new.
• "fine_grained_production_threshold" is defined in the physics list definition which is not affected by the adoption of GDML.
• G4StepMax, G4TimeMax, G4KinMax, and G4TrackMax were all defined at the build phase for the objects in the "DetectorConstruction" which is now only invoked for the sensitive detectors with adoption of the GDML. The associated data card variables are now read in from auxiliary nodes in the GDML. This was precisely the change that I needed to make in the update contained in lp:~ryan-bayes/maus/1439.

Again sorry it took so long to full test the above changes. I have been a little pre-occupied.

Anyone would think you've been running an experiment or something :)

Poking around some more (always a little dangerous) I found an intermittent segmentation fault that appeared depending on the order of detector objects scanned for auxiliary information when the GDML geometry is loaded. This was the result of an attempt to associate a special virtual detector with the top level MICE Module object --- which only happens for TOF0 and KL. I rewrote the geometry so that this will never happen and made some minor corrections to TOF1 and TOF2 to complete the removal of the TOF shielding (which clearly does not exist).

The new geometry has been written to the preproduction database as geometry id 618.

I also made a minor correction to the code in MAUSGeant4Manager.cc to make the behaviour of the code more predictable and enhance readability. I committed these changes to lp:~ryan-bayes/maus/1439.

Ah.
I've been struggling with the intermittent failure for the last day or so. Would fail on a different aux each time..
Kept failing in one branch, and on my machine was failing ~50% of the time.
Was going to revert to the 'old' MAUSGeant4Manager.
Will try your update from the 1439 branch and see if that's more stable.

Specifically the flakiness I'm seeing is with the 'latest' geometry ID 53 -- test_latest_geometry is failing ~25% of the time from the trunk.

No joy.
I got the same intermittent errors after taking the 1439 branch. Maybe it requires the 'new' geometry as well to get past the instability?
In order to get the release stable, I have reverted back to the previous versions of MAUSGeant4Manager.hh,cc in the release & trunk.

Yes the new geometry for TOF0 (i.e. prepared id 618) is required to remove the instability.

The changes introduced on Friday will make the program crash in 100% of cases if the "old" TOF0 geometry is used.

I will get the new TOF0 into the production CDB as soon as possible. I still have a few checks to do to make sure that everything else works correctly.

I think I have now confirmed that all of the detectors are working in the simulation the was that they are supposed to. The last detector was the KL and while I still haven't seen the KL digitized hits in the root output per se, I have had the digitizer print out the energy deposition (etc) to confirm that there are indeed hits in the KL and that they are being turned into digits. Once I have confirmed that one last set of changes to the KL does not break things, I will post four new preliminary geometries to the data base with no absorber, a LiH absorber, an empty lH2 absorber, and a full lH2 absorber. This upload will be completed this evening following the completion of a long validation test of the geometry that I have already uploaded to the preproduction database (id 634).

In the meantime, I have received the new geometry files from Jason and I have successfully converted the CAD files to GDML independent of FastRAD. I intend to post or otherwise make the conversion method available once I have cleaned it up and figured out how to do it in Linux. The remaining issues are the placement and rotation of the Trackers (which I think I can infer from MICE note 469 in a first pass), the identification of the detector element that is meant to represent the Ckovs (there are three different objects that I think are meant to represent two different volumes) and the positions of the survey nests in the detector coordinate system (which launched this issue in the first place). MICE notes 470, 471, and 472 can be used to infer the positions of the survey nests in the detector coordinates.

The validation has been continuing the hard way.

The EMR was found not to produce hits in the CDB geometry. I need to make a change to the MAUSGeant4Manager to apply sensitive detectors to the EMR daughter volumes in a manner analogous to the Tracker and the KL. To make the EMR GDML compliant with the EMRSD::ProcessHits method I needed to refactor the EMR definition somewhat. Note that the EMR, like the KL and the Tracker, geometry needs to be defined explicitly in the GDML because the G4Detector definitions cannot be used with the GDML. I now have a EMR geometry that produces hits and behaves exactly like the legacy geometry. This new geometry will go in parallel with the corrections to the Tracker (to deal with the flip) and refinements to the solenoid field alignments.

Chris,
Which geometry are you looking at?
For geometry ID 72, from the CDB, I do see the rotation in ParentGeometryFile.dat

..
                            Module /home/mice/MAUS/geo72-nofield/Tracker0.dat
                                    {
                                    Position 0.107 2.132 14509.40 mm
                                    Rotation -0.1497 179.96797 0.0 deg
                                    }

                            Module /home/mice/MAUS/geo72-nofield/Tracker1.dat
                                    {
                                    Position -1.1727 5.6640 19405.72 mm
                                    Rotation 0.412 -0.0605 0.0 deg
                                    }

Mine doesn't read that way. I have no idea why, my configuration file used for the download used:

# configuration database
cdb_upload_url = "http://cdb.mice.rl.ac.uk/cdb/" # target URL for configuration database uploads TestServer::http://rgma19.pp.rl.ac.uk:8080/cdb/
cdb_download_url = "http://cdb.mice.rl.ac.uk/cdb/" # target URL for configuration database downloads
cdb_cc_download_url = "" # "http://preprodcdb.mice.rl.ac.uk" # target URL for cooling channel configuration database downloads.

# geometry download
geometry_download_wsdl = "geometry?wsdl" # name of the web service used for downloads
geometry_download_directory   = "%s/files/geometry/download" % os.environ.get("MAUS_ROOT_DIR") # name of the local directory where downloads will be placed
geometry_download_by = 'id' # choose 'run_number' to download by run number, 'current' to use
                                    # the currently valid geometry or 'id' to use the cdb internal id
                                    # (e.g. if it is desired to access an old version of a particular
                                    # geometry)
geometry_download_beamline_for_run = 0
geometry_download_beamline_tag = ''
geometry_download_coolingchannel_tag = ''
geometry_download_run_number = 0
geometry_download_id = 72
geometry_download_cleanup = False # set to True to clean up after download

You will need MAUS v >= 1.1.1 -- there was a bug in the Parent file creation which Ryan fixed prior to release 1.1.1

I'll try that, however, the changes to the other files still stand.

Hi Chris,

Thanks for the correction to the plane ordering.

The files listing the fibres are necessary for the same reason as the bar definitions in the EMR.gdml file --- the MC requires the fibres to represent the active material in the process hits method; the G4Detector definition usually covers this but those definitions are not compatible with the GDML so the fibres need to be reproduced explicitly. you are right this information is not needed in the reconstruction so it is not reproduced in the MICEModules.

The MAUS version is the right catch by Durga. Cheers.

I've just ran some DAQ data using the tracker gdml files I posted, looks like they cause something to break in the doublet layer files, I don't know what is doing it just yet. I'll continue to poke around, but you should probably hold off on uploading those files I sent about.

Is it the references to the files or is there something wrong with the reconstruction?

I had to sort through two sets of errors with the uploaded files --- the fibre doublet references in Tracker0.gdml did not have absolute file reference to the fibre doublet planes, and Tracker1.gdml had absolute references to a directory on your personal system. I will have to fix the file references in Tracker1.gdml to remove the leading directory, and to run the files as is on my system I had to change the absolute paths to something pertinent for my system before they would run.