Geometry

Next Mu2e Geometry Meeting: TBA

Introduction

This page is still Under Construction, but is nonetheless functional.

This page contains two sections. The top is the "Working Area." This includes contact information, a to-do list, and pointers to the relevant documentation describing the various requirement and implementation documents. The bottom is the big picture philosophy, based on the original version of this Geometry page.

NOTE: If you are planning to change the software description of some part of the Mu2e geometry, or if you have approved changes to the geometry that need to get into the Offline software, please first contact the Geometry Czar.

Contacts

Geometry Czar	David Brown	david.brown@louisville.edu
G4Beamline	Dave Hedin	hedin@niu.edu
MARS	Vitaly Pronskikh	vspron@fnal.gov
Computing	Rob Kutschke	kutschke@fnal.gov

To Do

Current To-Do List: See Mu2e-doc-8378

• Update geometry for calorimeter backplanes, etc - Echenard?
• Add support for stopping target
• Add upper/outer walls of building
• Update geometry of tracker, support - DNB (LBL)?
• Update stands in PS/TS/DS - DNB, D.Cox (Lou)
• Add cables,racks, and pipes - B. Fagan, DNB,
• Detailed number comparison G4Beamline/Offline
• Evaluate simulation model vs. actual construction
• Check earth density, add backfill (partially complete)- A. Hill
• Add degrader
• Decouple construct functions from direct SimpleConfig use
• Take proton beampipe further upstream
• Add the ability to create sub-volumes for MARS use
• Check details of TS cryostat and coils
• Better representation of vacuum?
• Improve geometry hierarchy
• Improve directory structure?

Recently completed tasks

When	What	Who	Notes
27 Jan 2016	Text files	R. Kutschke	Rob prepared set of geom_common files for large second passes of stages 3 and 4 for CD3c
26 Jan 2016	TTracker name changes	K. Genser	More TTracker-related variable name changes.
20 Jan 2016	Muon Stopping	A. Palladino	Anthony added an absorber in the axial hole in the MBS and modified dimensions slightly in preparation for the STM development
17 Jan 2016	Added virtual detectors	D. No. Brown	Added virtual detectors in the bends of TS for B-field alignment studies
24 Dec 2016	IPA fix	D. No. Brown	Fixed an overlap in new IPA code
22 Dec 2016	New IPA	A. Edmonds	Andy added a new cylindrical IPA
8,14 Dec 2015	TTracker updates	K. Genser	Renamed TTracker geometry elements in accordance with latest naming standards and removed no longer relevant elements
6-7 Dec 2015	Pbar window support	D. No. Brown	Added support structure for the upstream Pbar window
24 Nov 2015	Widen penetration	D. No. Brown	Widened the penetration in the downstream right side to accomodate 14 inch rather than 12 inch pipe
20 Nov 2015	Remove obsolete package	R. Kutschke	Rob removed several obsolete packages, including the old Mu2eBuildingGeom
17 Nov 2015	Add version 2 of MBS	D. No. Brown	Add option to build MBS as specified in Mu2e-doc-1351 v7
13 Nov 2015	Move all Makers to GeometryService	Rob Kutschke	As part of a project to reduce dependency loops and generally clean up linking, Rob moved all Maker classes to GeometryService
12 Nov 2015	Update External Shielding blocks	Yuri Oksuzian	Update material and placement of some shield blocks (barite becomes boron carbide, some blocks removed)
29 Sept 2015	Removed verbose debugging text	Dustin Cox	Removed some verbose debugging text that was no longer necessary in Geometry software
29 Sept 2015	Fix shapes of some odd shielding blocks	D. No. Brown	Several corner blocks needed their shapes and dimensions fixed based on new information on shielding plans
01 Sept 2015	Fix straw numbering	K. Genser	Renumber tracker straws according to DocDB 888 v7
20 Aug 2015	Add Hall Accessor fn	D.N. Brown (Lou)	An accessor function for z-component of a surface of a a hall wall, getWallExtentz(string& bldg, int side), where bldg is the particular hall area ("dsArea" for example) and side is an integer: 2=east surface of east wall, 1=west surface of east wall, -1=east surface of west wall, -2=west surface of west wall. Helpful for placing geometry relative to walls without having to hard-code numbers. Requested by A. Palladino.
14 Aug 2015	Update Stopping Target	Markus Roehrken	Implement new design with 100 thin Al foils, no taper. Not for use in cosmic ray studies
23 Jul 2015	Update External Shielding	D.N. Brown (Lou)	Modify positions of barite blocks near Stopping Target

Component documentation

Overview

• Geometry Issues for CD-3c
• The Mu2e Apparatus
• Tutorial (2016) on Geometry Browsing

In the following table, "Requirements Documents" describe the requirements on the actual pieces of geometry and are generally not software-specific. "Implementation Documents" describe how the software model of the geometry was designed, how it works, and/or how it performs.

Please forward information about missing items to the Geometry Czar.

Component	Requirements	Implementation	Notes
External Shielding	Docdb-1506 - WBS 5.4 Upstream Docdb-1371 - WBS 5.9 Downstream	External Shielding Geometry Documentation	Produced by David (Louisville) Brown, modular and generic
Muon Beam Stop	Docdb-1351 - WBS 5.8 Docdb-1383 - WBS 5.10 (supports)	Docdb-1519: Initial Implementation	Krzysztof Genser initial implementation, D. No Brown update
Conventional Construction (Building walls, dirt, etc)	Docdb-3494 Docdb-5382 Docdb-5490 Docdb-5680 Docdb-5743	Docdb-4507 Docdb-5121 Docdb-6449	Initial implementation by Kyle Knoepfel

PS Area

PS External Shielding Slide

General Documentation

Geometry Images

Tarball of tiff images using default geom_common.txt)

• Current Geometry (Sept 2015)

GDML's

To make your own gdml file of the Offline geometry model, edit the file Mu2eG4/fcl/prolog.fcl and change the writeGDML parameter from false to true. Run art using any standard fcl config file (Mu2eG4/fcl/g4test_01.fcl, for example).

• Current Geometry (Sept 2016 - Offline v5_7_9) gdml file

Coordinate translation

As a reminder to developers:

x(mu2e)	=	x(g4bl) + 3904 mm
y(mu2e)	=	y(g4bl)
z(mu2e)	=	z(g4bl) - 7929 mm

Notes on Geometry Files

To specify a Mu2e geometry in the Mu2e Offline you put the following in the services table of your fcl file:

GeometryService : { inputFile : <filename> }

where <filename> is the name of a geometry file. A typical services table will contain configuration for other services. To choose the currently recommended geometry, use the file:

Mu2eG4/geom/geom_common.txt

where the path is relative to a base release of Mu2e Offline. If you look at this file, you will see that it contains only one line: it includes one of the named geometries. As of July 2016, there five supported named geometries:

Mu2eG4/geom/geom_common_cd3_s4p2.txt
Mu2eG4/geom/geom_common_cd3_s4p2_backgroundSim.txt
Mu2eG4/geom/geom_common_cd3_s3p2.txt
Mu2eG4/geom/geom_common_cd3_p1.txt
Mu2eG4/geom/geom_common_tdr.txt

The current default is the first in this list.

If you wish to override the choice of the geometry file, the recommended procedure is to add the following at the bottom of your fcl file:

services.GeometryService.inputFile : <filename>

Some comments on each of these follows:

geom_common_cd3_s4p2_backgroundSim.txt

Relative to geom_common_cd3_s4p2.txt there is one change: the tracker has all 20 stations (not 18 - see the comment in the description of geom_common_cd3_s4p2.txt). This file is used to generate, but not to reconstruct, events in stage 4 pass 2. The strategy is to run g4 on a 20 station tracker. When we make hits we skip straws from the missing stations. In this way we can study trackers with 18, 19 or 20 stations without having to rerun G4.

geom_common_cd3_s4p2.txt

This file should be used to analyze files produced by the second pass of stage 4 onward. It is the current default (July 2016). Relative to geom_common_cd3_s3p2.txt this has the following changes:

• Update the tracker from the TDR to the CD3 geometry
• Update the calorimeter from the BaF (TDR) design to the CsI (CD3) design.
• Add an electronics rack in the hall beside the DS.

In this geometry the tracker design has slots for 20 stations but only 18 stations are present. In the CD3 design we only have money to build 18 stations. Should the finanacial situation improve, we will build one or two more stations and install them in the available slots.

geom_common_cd3_s3p2.txt

This file was used for the second pass of stage 3 and for the first pass of stage 4. Relative to geom_common_cd3_p1.txt it has the following changes:

• Use the GA05 field maps instead of the Mau9 field maps.
• Use the cylindrical proton absorber, not the conical one.
• Add some service pipes on the west wall of the DS hall.

geom_common_cd3_p1.txt

This is the geometry file used to run passes 1 and 2 of the beam simulations in the CD3 simulation campaign. It was also used for the first pass of stage 3. It has TDR era descriptions of the tracker and calorimeter but in these stages those detectors are hidden.

geom_common_tdr.txt

With this geometry file, one can use modern code to analyze the tracker information from TDR era event-data files; be aware when you make hits from the StepPointMCs you will use modern code for hit making - you will not get TDR era hits. You can also do some limited analysis with the calorimeter information from TDR era files; when you make hits you may use code that loads CsI properties by default - you may also need to modify conditions information to get properties of BaF2. Check this out before using this code to look at calorimeter information. If you need to look at other information from TDR era files, you should use code from that era.

See also some history on geometry files

Rob Kutschke's Notes on Geometry Philosophy, circa 2010

This note describes the main ideas behind the geometry system used by the Mu2e software.

Mu2e has three major clients for its geometry description:

1. Reconstruction
2. Simulation
3. Event display ( also called visualization).

Here reconstruction should be broadly construed to include software triggers/filters, online in general, calibration and so on. Simulation includes Geant4 and perhaps one or more fast simulation packages. And there might be several event displays, one optimized for visualizing the geometry and another optimized for visualizing hits and tracks.

These three clients place very different demands on the geometry system and past experience has shown that, for tracking detectors, it is not possible to build a single representation of the geometry information that works well for all three clients. This is discussed further in Appendix I . This leads to the situation that we must build and maintain distinct geometry representations that are optimized separately for each purpose. With this constraint, the critical problem is to ensure that all of the different representations derive their information from a single authoritative source.

The nominal Mu2e detector can be described by a few hundred numbers. By the "nominal detector", I mean the detector that would exist if we could build it without any misalignments. Most of the work in the next few years will focus on variations of the nominal geometry, perhaps with some heuristic treatments of misalignment. We have planned how real alignment information will eventually plug into the system; this is described later.

Some constraints on the single authoritative geometry are:

1. For the nominal detector we would like the single authoritative source to be stored as a few human readable text files so that it is easy to compare two candidate detectors without requiring a tool more complicated than the UNIX diff command.
2. We would like to be able to run an instance of the offline software as the lowest non-real-time level of the online system; this includes use f or software triggers and filters.
3. We would like to use the same reconstruction geometry in the online system that we use in all other reconstruction steps.
4. The online system must not have a dependence on Geant4; we do not want the Geant4 memory footprint or the Geant4 startup delays.

I am told that it is possible to write GDML files that satisfy the first requirement but I have yet to see a successful demonstration; therefore we have decided not to make a GDML file our single authoritative source. That said, it would be perfectly OK to construct a GDML file from the single authoritative source and use it elsewhere. Requirements 2 through 4 argue that the reconstruction geometry must have no run-time dependence on Geant4; therefore the Geant4 geometry must not be the the single authoritative source.

The solution adopted by Mu2e, that satisfies the above constraints, is:

1. There is a framework service named GeometryService. Any element of the geometry that is used by reconstruction code must be described by classes within the GeometryService.
2. The GeometryService will get its information from the geometry database and the ConditionsData database.
   • These databases are ultimately the single authoritative source.
   • For the time being, we do not have these databases and the information is held in flat files; as of May 2010, there is a one such file, Mu2G4/test/geom_01.txt.
3. Reconstruction code must get its geometry information from the GeometryService. It must not directly access the databases.
4. If it is convenient, elements of the geometry that are not needed by reconstruction may also be described by the GeometryService but they need not be. For example the reconstruction code does not need to know about the earthen overburden or the concrete shielding blocks. So there is no requirement to represent these within the GeometryService and the code that instantiates these G4 volumes may get its information directly from the databases.
5. The code that instantiates the Geant4 geometry for elements that are used by reconstruction code must get its information from the GeometryService. It must not directly access the geometry or conditions databases. The classes in the GeometryService should have special accessors that present the information required by Geant4 in a convenient form. As much as possible the computation required to convert from the Geometry Service representation to the G4 represenation, should be done in the geometry service.
6. The magnetic field map will be owned and managed by the GeometryService and the G4 magnetic field routines should contact the geometry service to access the field.
7. The GeometryService has a "front-end" and "back end". The front end is the classes that are seen by the clients; these classes are "mostly dumb data" and must be persistable. These classes will be written to the run-data segment of the event-data file. The front end classes do not know how to populate their own information; that is the job of the back-end classes. A more complete discussion follows.
8. As we develop visualization packages, they should get their information via the geometry service. As needed, we should add functionality to the geometry service to support this.

As mentioned earlier, the GeometryService has a front end and a back end; the front end is the part seen by the clients and our goal is to make this interface stable in time. For example, client code can ask the GeometryService for an LTracker; it can then ask the LTracker for the properties of a straw such as the position of the mid-point of the straw, a unit vector in the direction of the straw, the outer radius of the straw, the material(s) of which the straw is made and so on. A key feature of the design is that the LTracker class is "mostly dumb data"; that is, the LTracker knows the position of each straw but it has no idea where that information came from; it just knows. There is a companion class, the LTrackerMaker, that knows how to create an LTracker fully populated with the correct information. The LTracker class is only "mostly" dumb-data since it may do simple computations on its own member data; for example it may have an accessor that returns a diameter when the relevant data member is a radius.

Why two classes, the LTracker and the LTrackerMaker? The main reason is that the LTracker needs to be persistable while the LTrackerMaker has no reason to be persisted and might be very, very difficult to persist. The difficulty arises because the LTrackerMaker will someday need to know how to interface with databases. To avoid this complication the parts that need to be persistable were kept simple and moved into separate classes.

The existing classes in the Geometry service, LTracker, TTracker an so on should be considered as prototypes. When reconstruction algorithms require that new features be added to these classes, then those features should be added. Presumably this will happen many times in the coming months; when possible we should add to the interface, rather than changing the interface but there may we be times when we need to change interface and, therefore, change client code that depends on it. There is not yet so much client code that it justifies compromises in the design of the geometry classes.

The existing geometry classes currently contain some pointers; they also contain the indices that are necessary to restore the pointers after persistency. We do not yet have a solution to automatically restore the pointers after persistency but we will soon.

Appendix I: Examples of different demands

When doing tracking finding and fitting we will want to know things like: a unit vector that is tangent to the wire catenary at a given position along the wire; the unit normals to each face of support materials. Moreover we will want this information given in one coordinate system for all straws, presumably one with the origin at the nominal center of the tracker. In the Geant4 geometry system the above are derived quantities that are not naturally available and are difficult to compute. A Geant4 geometry object only knows about its position and orientation within its immediate mother volume; it knows nothing about its position and orientation within its grandmother or great-grandmother volumes. Those transformations are computed by Geant4 as needed. There is no point within the execution of G4 that one could write a loop over all straws and find their locations within the coordinate system of the Tracker mother volume.

In the mid to late 1990's there were several spectacular failures in which groups tried to write a track reconstruction and visualization code by deriving classes from the Geant4 geometry classes. The main issue was that it was necessary to carry around the full machinery of Geant4, which requires both a large memory footprint and large CPU time for initialization. This burden was too big to bear in environments like software based high-level triggers on machines with limited memory and otherwise-light-weight graphics applications.