Support #1439

Detector Geometry Validation

Added by Bayes, Ryan over 8 years ago. Updated over 6 years ago.

Target version:
Start date:
26 March 2014
Due date:
% Done:


Estimated time:
New Issue


The owners of the detectors must contribute to the geometry description to ensure that the most accurate description of MICE is available through CDB. This has already been undertaken at some level by the Tracker group, but has not yet been addressed by other groups. That said the EMR group and the Ckov group are both making changes to the implementations of their detectors in MAUS so it is understood that the GDML files currently in the CDB may look nothing like the final versions. Their feedback is still encouraged. The following steps should be taken by the detector owners to contribute to this validation.

- Download latest release of MAUS. Releases following (0.8.2) contain the geometry download, extraction, and fit algorithms. The software will need the latest python based MICE module extraction for the detector geometry and detector position fit.

- Use the "download_geometry'' with configuration options as described in geometry instructions. Please download the StepIV geometry corresponding to geometry ID 17 with the clean up GDML option set to false. The geometry_download_directory should contain a set of .dat files and a gdml directory.

- Review the contents of the gdml files. Confirm that
> the dimensions of the solids are correct
> all volumes appear in the detector definition as expected
> all volumes appear at the desired position in the detector coordinate system
> all the material definitions are correct.

- Review the MM files. Confirm that
> There are no obvious errors from translation
> There is a well defined module for every volume; every module is contained within braces "{}'' and has the correct positions.
> The detector materials in the MICE Modules are correct.
> All modules appear in the files as expected.

- Run the simulation with "'' or similar script with the simulation_geometry_filename flag pointing at ParentGeometryFile.dat under the geometry_download_directory. The purpose of this is to check for gross errors missed during the visual file inspection. The current release has been tested by R. Bayes and should run a simulation with the indicated geometry without problems.

The results of these checks should be reported to the geometry group in a reply to this issue. It is then the responsibility of either Ryan or Stefania (as deputy) to correct and respond to any noted problems and issue the corrected geometry to CDB. Further instructions for the download of the CDB geometry appears at


geometry_validation_materials_2d.root (1.67 MB) geometry_validation_materials_2d.root Rogers, Chris, 02 July 2015 11:40
geometry_validation_materials_1d.root (647 KB) geometry_validation_materials_1d.root Rogers, Chris, 02 July 2015 11:40
sigma_x.png (7.67 KB) sigma_x.png Rogers, Chris, 03 July 2015 12:53
sigma_xp.png (8.78 KB) sigma_xp.png Rogers, Chris, 03 July 2015 12:53
mean_energy.png (7.95 KB) mean_energy.png Rogers, Chris, 03 July 2015 12:53
Update.pdf (4.53 MB) Update.pdf update to detector geometry and positions Bayes, Ryan, 27 August 2015 12:36
Tracker1.gdml (28.8 KB) Tracker1.gdml Heidt, Christopher, 11 November 2015 19:48
Tracker0.gdml (28.1 KB) Tracker0.gdml Heidt, Christopher, 11 November 2015 19:48

Updated by Bayes, Ryan over 8 years ago

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.


Updated by Bayes, Ryan about 7 years ago

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.


Updated by Bayes, Ryan about 7 years ago

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.


Updated by Rogers, Chris about 7 years ago

  1. Step size
    • It looks like the step size is screwed up. Somehow the step size is set to
      some large value. How is this handled? I notice G4StepMax is set in some places,
      where is this set? (G4StepMax overrides configuration file max_step_length;
      if it is not working out, I can check for a bug there)
  2. Materials (See the geometry validation plots; note these are hard to read
    because the step size is screwed up.)
    • There is galactic upstream of the upstream tracker
    • There is galactic between the upstream tracker and the upstream tracker window
    • As an aside, the existing installation has not been pumped down, so should be
      filled with air; and the upstream and downstream trackers Helium system is
      leaking, I am not quite sure when and what happened with that but I understand
      that it is now filled with air (I can chase details for you, we should probably
      know if it was always air or if at some point there was Helium inside).
    • It looks like there are some windows in the absorber region. Are they supposed
      to be there (probably yes)? Not quite sure which geometry you are representing
      here, did you want two windows or four windows?
    • I can see two polycarbonate windows upstream and none downstream. Should there
      be only one downstream? Should there be only one upstream?
  3. Fields
    • Solenoid coil geometries are wrong - please refer to MICE note 464.
    • Could you please use the PropertyString FieldName to make it easier to read
      the coil geometries?

Updated by Bayes, Ryan about 7 years ago

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.

Updated by Rogers, Chris about 7 years ago

Thanks Ryan.

Step size is initially set in the ...

I tried taking this out; neither the 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?


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.


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).


Updated by Rogers, Chris about 7 years ago

I attach scattering and mean energy loss between the two trackers (pencil beam of 10k muons @ 200 MeV/c). Note that the fields are set to 0 (ScaleFactor 0 in ParentGeometryFile.dat). I was thinking about the tracker alignment study when I did it, but it brings up some questions...

  1. Looks like the absorber windows are two thin to come through the tracking. Probably Jason needs to do more segmentation here
  2. What causes the scattering at around 18300? geometry_validation_materials_2d.root makes me thing there shouldn't be any material there. Maybe a bug in my analysis (e.g. a particle decay?)
  3. Why is there more scattering in the downstream helium window than the upstream one?

I would like to force G4 to take smaller steps to see if it changes the result... e.g. G4 is screwing up finding the intersection of the track with the curved windows maybe.


Updated by Bayes, Ryan almost 7 years ago

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.


Updated by Drielsma, Fran├žois almost 7 years ago

  • 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">


<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"/>



As the EMRBar in (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 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.

Updated by Bayes, Ryan almost 7 years ago

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 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.


Updated by Drielsma, Fran├žois almost 7 years ago

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"/>


<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

Updated by Rogers, Chris almost 7 years ago

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!


Updated by Bayes, Ryan almost 7 years ago


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"/>

but I don't think your suggestion about "mod2[xp]" is correct.

"mod2" is an array (not a function) that consists of alternating 0s and 1s indexed from 1 to 60 such that mod21 = 0 and mod22 = 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.


Updated by Bayes, Ryan almost 7 years ago

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 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).


Updated by Rogers, Chris almost 7 years ago

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

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

Updated by Bayes, Ryan almost 7 years ago

Hi Chris,

The short answer is yes.

The long winded answer is that
  • "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.


Updated by Rogers, Chris almost 7 years ago

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


Updated by Bayes, Ryan almost 7 years ago

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 to make the behaviour of the code more predictable and enhance readability. I committed these changes to lp:~ryan-bayes/maus/1439.


Updated by Rajaram, Durga almost 7 years ago

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.


Updated by Rajaram, Durga almost 7 years ago

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.


Updated by Rajaram, Durga almost 7 years ago

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.


Updated by Bayes, Ryan almost 7 years ago

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.


Updated by Bayes, Ryan almost 7 years ago

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.


Updated by Bayes, Ryan almost 7 years ago

I now have a complete geometry with all of the detectors in their final forms. I have attached a set of slides summarizing the changes made to the detectors and the results of the fits of the detector positions to the surveys.

A set of changes for the Ckov was submitted yesterday and the geometry has been updated in the CDB. This is the last set of changes required for the production of the simulation in anticipation of the inclusion of the Cherenkov digitization.


Updated by Bayes, Ryan over 6 years ago

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.


Updated by Heidt, Christopher over 6 years ago

There are a few problems in the Tracker geometry. The biggest is that the tracker rotations are not propagating. I'm guessing that Maus_Information.gdml is responsible for creating the ParentGeometry.dat file. Tracker rotations are entered as:

            <Tracker0 gdml_posref="DEVICE-MOUNTED-DETECTORS_Part__Feature_pos">
          <physvol name="DEVICE-MOUNTED-DETECTORS_Part__Feature">
        <file name="Tracker0.gdml"/>
        <position name="DEVICE-MOUNTED-DETECTORS_Part__Feature_pos" unit="mm" x="0.107" y="2.132" z="14509.40"/>
        <rotation name="DEVICE-MOUNTED-DETECTORS_Part__Feature_rot" unit="degree" x="-0.1497" y="179.96797" z="0.0"/>
            <Tracker1 gdml_posref="DEVICE-MOUNTED-DETECTORS_Part__Feature001_pos">
          <physvol name="DEVICE-MOUNTED-DETECTORS_Part__Feature001">
        <file name="Tracker1.gdml"/>
        <position name="DEVICE-MOUNTED-DETECTORS_Part__Feature001_pos" unit="mm" x="-1.1727" y="5.6640" z="19405.72"/>
        <rotation name="DEVICE-MOUNTED-DETECTORS_Part__Feature001_rot" unit="degree" y="-0.0605" x="0.412" z="0.0"/>

Notice that the rotation is for the upstream tracker is:

<rotation name="DEVICE-MOUNTED-DETECTORS_Part__Feature_rot" unit="degree" x="-0.1497" y="179.96797" z="0.0"/>

While downstream tracker is

<rotation name="DEVICE-MOUNTED-DETECTORS_Part__Feature001_rot" unit="degree" y="-0.0605" x="0.412" z="0.0"/>

However in Parent Geometry the tracker rotations are 0,0,0. I'm not sure how this is meant to propagate, Ryan can you help?

also I've attached some files here that correct plane ordering in the downstream tracker and what should finally convert all our units from cm -> mm.

I also noticed we have a lot of tracker gdml files for the individual tracker fibers. This seems extremely unnecessary as that information is not used anywhere in the reconstruction or MC (unless someone has changed it). We could probably do away with that information.


Updated by Rajaram, Durga over 6 years ago

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



Updated by Heidt, Christopher over 6 years ago

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

# configuration database
cdb_upload_url = "" # target URL for configuration database uploads TestServer::
cdb_download_url = "" # target URL for configuration database downloads
cdb_cc_download_url = "" # "" # 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

Updated by Rajaram, Durga over 6 years ago

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


Updated by Heidt, Christopher over 6 years ago

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


Updated by Bayes, Ryan over 6 years ago

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.


Updated by Heidt, Christopher over 6 years ago

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.


Updated by Bayes, Ryan over 6 years ago

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.

Also available in: Atom PDF