MagneticFieldMaps

From Mu2eWiki
Jump to navigation Jump to search

Introduction

The Mu2e magnetic field maps are found in 

/cvmfs/mu2e.opensciencegrid.org/DataFiles/BFieldMaps

The cvmfs location is visible on the interactive nodes and all grid worker nodes. All Mu2e code, including Offline, G4beamline and MARS should use these magnetic field maps and not field maps stored in private disk space.

The Mu2e cvmfs partition is mounted on all OSG worker nodes, including off-site nodes. You may mount the Mu2e cvmfs partition at remote sites such as your home institution or your laptap. For details see the Mu2e cvmfs page .

As of August December 2015, the recommended magnetic field maps are in: 

/grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau9
/cvmfs/mu2e.opensciencegrid.org/DataFiles/BFieldMaps/Mau9

What's up with the "b"? What happened to plain old Mau7? The answer is that the field map .txt files in Mau7b are identical to those in Mau7. However there has been a change in the format of the binary files that are dervied from the .txt files; these issues are described in Appendix II and Appendix III .


The Mau7 (and Mau7b) field maps are the first maps computed after the removal of the return yoke and the tilting of the coils around the y axis to compensate for the absence of the iron. The other magnetic field maps are of historical interest and will be described below . The Mau series of maps are named after Mauricio Lopes from Fermilab Technical Division (TD) who computed them using Opera3D.

Within the Mau7b subdirectory there are ten .txt files, each of which contains a magnetic field map for some region of the Mu2e detector or hall. These files are organized into three groups. The first group includes the files: 

   Mu2e_DSMap.txt
   Mu2e_PSMap.txt
   Mu2e_TSdMap.txt
   Mu2e_TSuMap.txt

Each of these files contains a field map consisting of field values specified on a 3D grid; each map describes the field in a region of the muon beamline encoded in the name of the file; these regions of validity include the vacuum volume, the surrounding coils and a small amount of the space surrounding that. The four field map regions touch each other but do not overlap. These files are written in a format defined by G4beamline but all Mu2e code is capable of reading this format.

The second group of files includes, 

   ProtonDumpAreaMap.txt
   PStoDumpAreaMap.txt

These files are also touching but not overlapping with the other four files and with each other; they extend the field map from the PS to the proton dump and extinction monitor areas. Together these six files should be viewed as making a continguous map with an odd shaped outer boundary. The last two files specify the field on a coarser grid than do the first four files; in these regions the fields have shallow gradients so a coarser map is adequate.

The third group of files includes, 

  BFieldMaps/Mau7b/ExtMonUCIInternal1AreaMap.txt
  BFieldMaps/Mau7b/ExtMonUCIInternal2AreaMap.txt
  BFieldMaps/Mau7b/ExtMonUCIAreaMap.txt
  BFieldMaps/Mau7b/PSAreaMap.txt

These four field maps may overlap, both with each other and with the field maps in the first two groups. The first two of these four maps are used in the region of the extinction monitor that is being designed by the UC Irvine group; these files use a fine grid. The last two files are used to track cosmic rays and to look up the field in regions of the hall where electronics or photosensors may be located; these files use a coarse grid.

The file ExtMonUCIAreaMap.txt does not overlap any of the maps in groups 1 or 2; it does, however, overlap the two ExtMonUCIInternal maps. Therefore, when the two UCI internal maps are present, ExtMonUCIAreaMap belongs in group 3, not group 2.

Additional information about these field maps, including drawings of the regions of validity, is available in Mu2e-doc-2072 .

These .txt files are the single authoritative source for our magnetic field maps and they are used by all of our software, Offline, G4beamlnie and MARS.

Starting with version Mau10, the UCI field maps will no longer be made because they are no longer needed. There will never be UCI field maps in the GA series of maps.


Definition: Inner and Outer Maps

The Mu2e code and run-time configuration uses the notation "inner" and "outer" maps. By defintion, an inner map does not overlap with any other inner map while an outer map may overlap both with other outer maps and with any inner map. Therefore the first six maps listed above are inner maps while the last four maps listed above are outer maps.

This distinction of inner and outer maps is important in the algorithm used to look up the magnetic field at a given point. The Mu2e code first checks the inner maps to see if the point is inside one of those maps; if the code finds the point within a map, it computes the field value and returns it. By definition, the code will find the requested point in either none or exactly one of the inner maps. If the Mu2e code does not find the point inside one of the inner maps, it will then search the outer maps. While it is possible for the point to be inside more than one outer map, the Mu2e code will accept the first positive result and will return the field computed from that map.

When looking up the field value in the inner maps, the Mu2e code first checks the most recently used inner map and, if that fails, the code tries the remaining inner maps in the order specified in the run-time configuration file. Almost always the code will find the point in the most recently used map.

Variants on the Standard Field Maps

As of August 2012, there are five variants on the Mau7b magnetic field maps. There are found in the following directories, 

   /grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau7b/4T
                                            Mau7b/5T
                                            Mau7b/DS_70Percent
                                            Mau7_NegativeGradient_v1
                                            Mau7b/ExtMonUCIInternal1

The files in these directories were created as needed for particular studies; only the maps needed for those studies were recreated. The directories 4T and 5T each contain a subset of the Mau7b field maps, recomputed with magnet currents such that the peak field in the PS is, respectively, 4 Tesla or 5 Tesla; these field maps are used to study the change in the stopped muon yield if we can run the PS at higher than design field or if we are forced to run it at lower than design field. According to Mau, the DS field map from the standard Mau7b area can be used with either the 4T or 5T files; the PS coils are too far from the DS to significantly affect the field in the DS.

The directory DS_70Percent contains a subset of the Mau7b field maps, recomputed with the currents such that the field in the uniform-field region DS is 70 percent of its nominal value. This field map is used to study calibration of the absolute momentum scale of the detector using the monoenergetic positrons produced from pi+ decay at rest from pi+ that range out in the foils of the stopping target. According to May, the PS field map from the standard Mau7b area can be used with these maps.

The directory Mau7_NegativeGradient_v1 contains a map of the DS field in which the coil currents have been changed to create a small negative gradient in the region of the DS that has a nominally uniform field. This field has been used in a study to see if the adding a small negative gradient signifcantly reduces the incidence of particles that become trapped in the (very shallow) wells in Bz.

The files in the subdirectory Mau7b/ExtMonUCIInternal1 are used by the extinction monitor group at UC Irvine. See Zhengyun You for details.



File Formats

Text Format

The G4beamline defined format is an all text format that consists of a header, terminated by a line that contains only the word "data", followed by a series of lines in the format 

x y z Bx By Bz

where the positions are given in mm and the field values in T. Starting with Mau7, the positions are given in the Mu2e coordinate system. Previously they were given in the Mu2e G4beamline coordinate system, whose origin, specified in the Mu2e Coordinate system is at (3904.,0.,-7929) mm. These coordinate system have parallel axes. For all files, the magnetic field components have they same meaning ( since the axes of the two coordinate systems are parallel ).


In the header, comments begin with a # sign in the first column. The comment 

# Origin shift for Mu2e: 0. 0. 0.

is meaningful for the Offline but not for G4beamline. I don't know if it is meaningful for MARS. This comment informs the Mu2e Offline program that space point in the map are specified in a coordinate system whose origin, as specified in the Mu2e system, is the value indicated.

If this structured comment is absent, the Mu2e Offline software uses a default value of (3904,0.,-7929.). In versions of the field maps prior to Mau7, the comment is absent and the space points are specified in the Mu2e G4beamline system. The convention defined here allows the old field map files to be usable, without modification, by both old and new versions of Offline.

In the header, I don't know the meaning of the line that begins with "param"; it is used to control aspects of G4Beamline that Mu2e does not use. The line that begins with "grid" defines the grid points. The grid spacing is regular and the points form a box with no missing points. The line that begins "extendY" says that the grid points are given only for values of y greater than or equal to 0.; to compute the field at -y, the algorithm is to compute the field at +y and flip the sign of By. Both Offline and G4beamline understand this convention; I don't know how MARS manages this.

A footnote: prior to August 19, 2015 all of the magnetic field maps had this symmetry and, in Offline, the sign flip was hardcoded. During August 2019 we received the first GA files that did not have this symmetry and the code was modified so that it's behaviour was controlled by the extendY parameter.


When the field map files are delivered by Mau they only contain the grid points and field values. We insert the headers by hand.

Binary Format

For Mu2e Offline there is a second file format, the binary format. This format is useful because reading the text files takes about one minute of CPU time while reading the binary format files takes seconds. The .txt files remain the authoritative format and the binary files are derived from them.

For each .txt file, the binary format consists of two files that have the same base name as the .txt file, for example from the Mau7 maps: 

Mu2e_PSMap.bin Mu2e_PSMap.header

The file Mu2e_PSMap.header is simply a copy of the header information from Mu2e_PSMap.txt, up to and including the "data" line. The .bin file contains the field values at the grid points in binary format; it is simply an image of these numbers in memory. The details of the binary file format are given in Appendix II .

BZipped Format

The Offline code is also capable of reading bzipped text files. For example, from the Mau5 maps: 

Mu2e_DSMap.txt.bz2 Mu2e_PSMap.txt.bz2 Mu2e_TSdMap.txt.bz2 Mu2e_TSuMap.txt.bz2

These files were made by bzipping the .txt files. Compared to the .txt files, it takes much longer to read these files; however they could be useful in the event of a slow network connection.

As of Mau7, we no longer routinely make the .bz2 files. We can make them on request. We reserve the right to delete the existing .bz2 files without notice should we need to recover disk space.

Details of the Binary Files

Starting with the Mau7b field maps, the in-memory representation of each field map is: 

mu2e::Container3D<CLHEP::Hep3Vector> _field;

where mu2e::Container3D is a very crude 3D-array class template. Internally mu2e::Container3D<T> holds its information as 

std::vector<T>

and it has accessors/modifers to manage the transformation between a 3D index and a location in the 1D std::vector.

The binary files are written using 2 calls to cstdio write. The first write is the 4 bytes: 

unsigned int deadbeef(0XDEADBEEF);

This serves as an endian marker. The second call writes out all of the _field std::vector in a single call to cstdio write.

On readback, the code first reads the endian marker and checks it. If the check fails, the job stops with an appropriate error message. The code then allocates an object of type mu2e::Container3D<CLHEP::Hep3Vector> with the internal std::vector sized correctly. It then uses a calls to cstdio read to move the contents of the disk file into memory. There is no attempt to dynamically correct wrong-endian-ness; we can add that if it becomes necessary.

There is no attempt to detector correct the following problem: the binary files are written on one machine that has a particular representation of the built-in type double but are read on a second machine that uses a different representation for double. Here "different representation" refers to more than just an endian difference. Should this become an issue, we will deal with it at that time.

The Old Binary Format

Up to and including the Mau7 field maps, the in-memory representation of each field map contained contained both the field value and the associated grid point: 

mu2e::Container3D<CLHEP::Hep3Vector> _gridPoint;
mu2e::Container3D<CLHEP::Hep3Vector> _fieldValue;

This representation is wasteful of memory: because the grid is regular and has no holes, the postion of any grid point can always be computed using the parameters of the grid and the 3-integer index of the point. The code was changed to exploit this feature and to remove the need for the array of grid points.

Binary files of this format are written with 3 calls to stdio write: one for the endian marker, one for the array of grid point positions and one for the array of field values. The readback is done as above with the addition of one extra call to stdio read to read in the positions of the grid points.



Selecting Field Maps

Selecting Field Maps in Mu2e Offline

The following fragment from Mu2eG4/test/geom_01.txt shows the default choice of magnetic field maps: 

string bfield.format  = "G4BL";

vector<string> bfield.innerMaps = {
  "BFieldMaps/Mau7b/Mu2e_DSMap.header",
  "BFieldMaps/Mau7b/Mu2e_PSMap.header",
  "BFieldMaps/Mau7b/Mu2e_TSuMap.header",
  "BFieldMaps/Mau7b/Mu2e_TSdMap.header",
  "BFieldMaps/Mau7b/PStoDumpAreaMap.header",
  "BFieldMaps/Mau7b/ProtonDumpAreaMap.header"
};

vector<string> bfield.outerMaps = {
  "BFieldMaps/Mau7b/ExtMonUCIInternal1AreaMap.header",
  "BFieldMaps/Mau7b/ExtMonUCIInternal2AreaMap.header",
  "BFieldMaps/Mau7b/ExtMonUCIAreaMap.header",
  "BFieldMaps/Mau7b/PSAreaMap.header"
};

The bfield.format variable says that the field is given in the G4beamline format; this includes all three of the text, binary and bzipped representations. The alternative value is obsolete and selects an ancient MECO binary format ( which is very different from our binary format ).

The bfield.innerMaps and bfield.outerMaps variables specify the list of field map files to read; the meaning of inner and outer maps is defined above. In principal one need only include the field maps for the spatial regions of interest for a particular job; however the present recommendation is to always read all maps.

The Mu2e Offline program searches for the map files in the path defined by the environment variable [FileSearchPaths.shtml MU2E_SEARCH_PATH] .

If a filename ends in .txt, then the code will simply open the .txt file, read it and build the in-memory map. If a filename ends in .header, then the code will open the file and read it to extract the meta data; it will then reserve enough space to hold the in-memory map and read the corresponding .bin file directly into the reserved memory. If a filename ends in .bz2, then the code will decompress the file memory and read it to build the in-memory map.

By far the fastest method is to chose the binary files by specifying the header file in the above lists.


Selecting Field Maps in G4beamline

See the Mu2e G4beamline Manual .

Selecting Field Maps in MARS

Contact Vitaly Pronskikh.



Installing New Files and Making the Binary Files

Do not delete or overwrite old versions of the field maps: disk space is cheap and the ability to reproduce previous results is critical. Always add new files following the version pattern that is already present.

  1. If Mau sends us a variant on an existing field, make a subdirectory and put the new files in there. For example, Mau7b/4T and Mau7b/5T.
  2. If Mau sends us a new field, increment the counter in the name, Mau4, Mau4, Mau7 and so on.
  3. If we produce variants of our derived file formats, increment the version character, Mau7b, Mau7c and so on.


To install a new field map, and to make the binary files for that map, follow these steps:

  1. Get the .txt files from Mau.
  2. If necessary, construct the headers and insert them at the start of the .txt files. Don't blindly copy the headers from previous files: check to see whether or not they actually describe the new file correctly.
  3. Put the .txt files in /grid/fermiapp/mu2e/DataFiles/BFieldMaps/XXXX, where XXXX is the directory name for the new map.
  4. Edit geom_01.txt
    • Specify the new .txt files.
    • Add the parameter: bool bfield.writeG4BLBinaries = true;
  5. Run mu2e using the modified geom_01.txt. It will write the .bin files to the local directory. You should use one of the standard test jobs, such as Mu2eG4/test/g4test_03.fcl and check that the output makes sense.
  6. Move the .bin files to /grid/fermiapp/mu2e/DataFiles/BFieldMaps/XXXX.
  7. Extract the header information from each .txt file to make the corresponding .header files.
  8. Edit geom_01.txt to replace .txt with .header for the files listed in bfield.innerMaps and bfield.outerMaps.
  9. Test that mu2e runs correctly with the binary files. You can do this by comparing the output of this step with the output of step 5.
  10. Commit geom_01.txt and announce to mu2e-sim.



Field Calculation Tools

The standard software for calculating magnetic field maps in Mu2e is Opera. However, alternative tools have been developed in Python. The primary purpose of these additional tools is for continuing to improve the magnetic field model that will be supplied by the Field Mapping System (FMS), but may see utility in other areas (e.g. studying effects of PS coil misalignment).

OPERA

OPERA calculations are run by Hank Glass. These calculations so far have incorporated the following conductor geometries (solved by Biot-Savart law): ideal solenoids, 20 node bricks (for helical solenoids), circular arcs & longitudinal bars (for bus bars). OPERA has the advantage that it also includes FEA, so magnetic materials can be added to the system.

A drawback to OPERA is that the 20 node bricks are constructed with parabolic curves, despite a helical solenoid being circular. This introduces small node-like structures to the field, at 10 azimuthal points, reflecting the fact that 10 bricks are used per loop of the helical coil. This feature was one strong motivation for developing additional calculation tools.

The helicalc Python package

The alternative to OPERA is the helicalc package, which includes Biot-Savart integration of helical solenoids (helicalc.coil), bus bars (helicalc.busbar), and ideal solenoids (helicalc.solcalc). Note that the ideal solenoid routine is an extension of Mau's Matlab based SolCalc routine. The helicalc mathematical formalism was developed by Hank Glass [1].

All routines in helicalc use 2D or 3D trapezoidal integration. In some cases this allows for GPU parallelization to greatly reduce computation time.

Using helicalc has the following benefits:

  • No parabolic approximation for helical solenoids
  • Integrations are save on a "per conductor" basis and combined in a final processing step. This allows for modifications of individual conductors without the need to recalculate the field from all conductors in the system. This also allows for changing the current in conductors without redoing the costly integrations.

The helicalc package is available on GitHub, and technical documentation can be found here -- under construction.

Any requests for field calculations with helicalc, as well as questions/suggestions for the helicalc package can be directed to Cole Kampa.

Available helicalc Field Maps

As of February 28, 2022, the following field maps are available on CVMFS. The listed directories are subdirectories of 

 /cvmfs/mu2e.opensciencegrid.org/DataFiles/BFieldMaps/
Map Name / Directory Available Regions Comments
Mau13/PSRot0mr/ PSMap, TSuMap, TSdMap, DSMap, PStoDumpAreaMap, ProtonDumpAreaMap Nominal coil configuration (e.g. Mau13). All coils ideal solenoids.
Mau13/PSRot7mr/ PSMap, TSuMap, TSdMap, DSMap, PStoDumpAreaMap, ProtonDumpAreaMap PS cold mass rotated (pitch) about center point by 7 mrad. All coils ideal solenoids.
Mau13/PSRot16mr/ PSMap, TSuMap, TSdMap, DSMap, PStoDumpAreaMap, ProtonDumpAreaMap PS cold mass rotated (pitch) about center point by 16 mrad. All coils ideal solenoids.
Mau13/PSRot23mr/ PSMap, TSuMap, TSdMap, DSMap, PStoDumpAreaMap, ProtonDumpAreaMap PS cold mass rotated (pitch) about center point by 23 mrad. All coils ideal solenoids.

Appendix I: Ancient History

This section describes obsolete BField maps. They are arranged in chronological order of their creation. The names below are subdirectories within /grid/fermiapp/mu2e/DataFiles/BFieldMaps


MECO

These files are the GMC field maps taken from MECO in June 2009. They are in a MECO defined format that is used by no other set of Mu2e field maps.

These files have B_z along the -z direction; this is the opposite of all other Mu2e field maps. Also the bend radius of the TS is 2926 mm for these maps but 2929 mm for all other maps.

To read these files, you need to use the geometry file: 

   Mu2eG4/test/geom_mecofield.txt

This file includes the standard geom_01.txt and makes the changes necessary to use the MECO field maps. The comments in the file explain which changes need to be made and why.

These files are also specified on a box-shaped grid but not every grid point in the box is present in the map. In each file the grid points define a box but only the stepped approximation to the inside of a cylinder has grid points present; the outer parts are missing.

There is no additional documentation about the format of these files, other than that found in the code itself.


G4BL_v0

These files are G4beamline format files that were created by Mike Martens in 2007 or 2008. The field was computed by Mike from the MECO coil placements and currents. There is no iron in this field model.

In this model, and all subsequent models, B_z is along the +z direction and the bend radius of the TS is 2929 mm.


MECO_RotatedCoils

This might be the short PS version? The DS map is identical to the G4BL_v0 version. Check with Rick Coleman to be sure.


Mau3, Mau4 and Mau5

Various versions of the field calculations by Mau. Contact Mau, or perhaps Rick Coleman, for details. I know that the variations include the shorter PS, different coil positions and fewer coilse. I believe that all versions have some iron present.

There is no Mau6 map; before it was finalized, the decision was made to remove the return yoke. So that calculation was suspended and the version with no return yoke is Mau7 (and Mau7b).


Appendix II GA Maps

The vendor who is making the DS and PS is General Atomics (GA). This section discusses magnetic field maps that we have received from GA.

Intorduction

The table below gives a summary of the magnetic field maps that we have received from GA; the table is precede by a description of some of the terms used in the table and is followed by a more complete description of each map.

This section defines some nomenclature that will be used below.


GA Name

In the <a href=#table>summary table</a>, the column labeled "GA Name" contains the name of the field map as delivered from GA. We felt that a numbering system that had 0.1 and 1.0, sometimes written as 01 and 10, might be too confusing. So we switched to a simple increasing number system. The GA numbers come from the Mu2e docdb document.

Usable

In the summary table the column labeled "Usable" says whether or not this map is usable for physics studies.

Map GA00 is usable for physics studies but it is not interesting to do so because, in the fiducial region, it is identical to Mau9.

The maps GA01, GA02 and GA03 use non-standard positions for the TSd coils; the fringe field of the TSd is significant inside the fiducial volume of the DS so these maps are not interesting to use for physics. In addition we believe that these maps do not contain fringe field from either the TSu or the PS. This is probably not important inside the DS but it is important near the upstream end of the TSd.


Format

The summary table has a column labeled "Format"; this can take one of two values, "Half" or "Full". If the column is labeled "Half" then the grid points are only specified for y>=0 and the field for y<=0 is given by the symmetry: 

  B_x(x,-y,z) =  B_x(x,y,z)
  B_y(x,-y,z) = -B_y(x,y,z)
  B_z(x,-y,z) =  B_z(x,y,z)

Maps with this format are variously refered to as an "upper half map" or a "half azimuth map".

If the column is labeled "Full" then the grid points cover the interval: ymin <= y <= ymax, where ymax is the same as for the upper half maps and where ymin=-ymax. Maps with this format are sometimes referred to as "full azimuth maps", "complete azimuth maps" or as simply "full maps".


Planar Coils vs Helical Winding

In the Mau9 field maps, and in all earlier field maps, the solenoids were modeled as "ideal solenoids". This means that they were modeled as a collection of planar current loops with a pitch of zero (here pitch is used in the sense of pitch, roll and yaw, with the forward direction being the nominal symmetry axis of the solenoids ). It is because all coils have a pitch of zero that these maps have the up-down symmetry discussed in the previous section. The current loops were modeled as ideal line currents; ie there is no transverse extent to the current density and no notion of boundary conditions at the surface of the conductor.

One of the innovations introduced by GA is to model each coil as helical winding. This is a more realistic model of the magnetic field but it breaks the up-down symmetry discussed in the previous section. Any map modeled with helical windings needs to be available in the Full format.

Some of the maps delivered by GA use the planar coil model and some use the helical winding model. The maps with a planar coil model were delivered for comparison purposes to help us test whether or not we understand what they are doing. The maps with a helical winding model are the maps that are intended to represent their actual desgin.

GA DS Coil Positions

The Mau9 DS design delivered to GA was not a 100% complete mechanical design. When their engineers completed the design, mechanical constraints required that they make small changes to some of the coil positions. There are two versions of the GA DS coil positions:

  • v1: used in GA03, GA04
  • v2: used in GA05

Some of the early maps delivered by GA use the orginal Mau9 DS coil positions while the other maps use their positions calculated by their engineers. The maps with the Mau9 coil positions were delivered for comparison purposes to help us test whether or not we understand what they are doing.

GA is responsible for the construction of the PS and at some later date will also give us field maps in which they have updated PS coil positions. For the time being (September 2015) this only affects the DS coil positions. GA is not responsible for construction of the TS and will always use TS coil positions that we give them.


Non-standard Positions for the TSd Coils

Early in our interactions with GA we gave them a set of coil positions for the DS and TSd. The coil positions for the DS were the same as those for Mau9 but the coil positions for the TSd were not the same as for Mau9; nor were they the same as for Mau10, which is still under development as of mid-september 2015 and has not yet been released. The coil positions for the TSd captured some point in the development between Mau9 and Mau10 and do not correspond to any official Mu2e field.

These non-standard TSd coil positions were used by GA to compute the maps GA01, GA02 and GA03.

Summary table

Name DocDB GA Name Usable Format Files Description
Name DocDB GA Name Usable Format Map Files Brief Description
GA00 5936 GA_0.3 Yes Full PS, TSu, TSd, DS GA's version of Mau9; used for the null test.
GA01 5826 GA0.1 No Half TSd, DS Non-standard placement of TSd coils; planar coils
GA02 5827 GA0.2 No Full TSd, DS Full azimuth version of GA01
GA03 5864 GA1.0 No Full TSd, DS Non-standard placement of TSd coils; helical winding and GA v1 placement for DS coils.
GA04 5985 GA 2.0 Yes Full PS, TSu, TSd, DS helical winding and GA v1 placement for DS coils; Mau9 version of the PS, TSu and TSd coils. Known issues: positive gradient at large z extends to radii that are less than 300 mm. fixed in GA05.
GA05 6297 GA 4.0 Yes Full PS, TSu, TSd, DS helical winding and GA v2 placement for DS coils; Non-standard placement of TSd coils; Mau9 version of the PS and TSu coils. Start from GA04; modifiy some coil positions at large z ensure negative gradient to larger radii. Known issues: none.

Details

GA00

This field map is GA's calculation of the Mau9 field starting from coil positions and currents; in ths model all coils are modeled as planar current loops. The reason for asking for this map is to verify that both Mau and GA get the same answer when starting from the same input.

Why might they get different answers with the same input?

Both Mau and GA use the program OPERA to convert coil positions and currents to field values on a grid. In this caculation OPERA needs to do numerical integrals and any numerical integral has accuracy vs speed tradeoffs. By comparing the GA00 maps to Mau9 we can check if Mau9 and GA are making compatible choices for these tradeoffs.

We refer to the comparison of GA00 to Mau9 as the "null test".

GA01

This map was the original GA attempt at producing a map to use for the null test; all DS coils were modeled as planar current loops. However it has several issues that make it unsuitable for physics: it was produced using <a href=#nonstandard>non-standard placement of TSd coils</a>; it does not include fringe field from either the PS or the TSu.

The output format is the upper half map.


GA02

This map was produced using a coil configuration identical to that used for GA01. The only difference is the output format, which is the full map, not the upper half map.

As for GA01, this map is not suitable for physics use. The one use that it does have is to compare with GA01 to verify that the modifications to our code that read the full format maps works correctly.

GA03

This was the first attempt at GA to provide a map that has their best model of the DS, using the <a href=#coilpositions>GA DS coil positions</a> and the <a href=#coilmodel>helical winding model for the DS coils</a>.

This map is not suitable for physics because it was produced using <a href=#nonstandard>non-standard placement of TSd coils</a>.

GA04

This is the first map that was released for doing physics calculations. It uses the Mau9 coil positions for the PS, TSu and TSd. It uses GA DS coil positions the helical winding model for the DS coils.

It was later discovered that, in the DS, at values of z near the calorimeter, the field has a positive gradient at radii as low as 300 mm; see pages 15 and 16 of Mu2e-doc-6025, Gradient Comparison on a Zoomed Scale.


GA05

This map can be used for physics calculations. The map starts from the model of GA04; the placement of some coils are large z was modified in order to push the region of negative gradient to larger values of radius.


Appendix III: Mau7 vs Mau7b

The four core authoritative files 

   Mu2e_DSMap.txt
   Mu2e_PSMap.txt
   Mu2e_TSdMap.txt
   Mu2e_TSuMap.txt

are identical in Mau7 and Mau7b. The binary file format was updated between Mau7 and Mau7b; see Appendix II .

We have kept both Mau7 and Mau7b so that it is possible to reproduce results that used the Mau7 field without having to produce a hacked version of the old code that allows it to read the new binary field map format.


Appendix IV: Variants on Mau7

Mau has prepared several variants on the Mau7 field. These are stored in: 

 /grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau7_NegativeGradient_v1
 /grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau7_NegativeGradient_v2
 /grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau7b/4T/
 /grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau7b/5T/
 /grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau7b/DS_70Percent

In all cases, the binary files are in the same format as Mau7b.

In the first two cases, only the DSMap is present, in both text and binary formats. The changes to the other maps are small enough that there is no reason to recompute them. It is legal to load the DSMap from one of these two areas and all other files from Mau7b.

In the region of the tracker and calorimeter, the standard Mau7 field is designed to be as close to uniform as possible. In the variant v1, the field is designed to have a negative gradient in Bz of approximately 2%. In the variant v2, the field is designed to have a negative gradient in Bz of approximately 5%.

The last three files have complete sets of DS, PS, TSu and TSd maps. The 4T (5T) files describe a PS in which the peak field is 4T (5T); the DS_70Percent files describe a DS in which the uniform region of the field is 0.7T. If you load either the 4T or 5T files, it probably does not make much sense to load the other 6 files from Mau7b.


Appendix V: Mau8

This field was released in January 2013 and has been available for use since January 18, 2013. It is similar to the Mau7 field but has approximately a 4% gradient across the nominal uniform region of the DS. All 10 maps are present. 

It has not yet been made the

default in any of our codes. It will become the default after it has been tested more thoroughly and after people who need to continue to use the older field are told how to do so.


Appendix VI: Mau8a

This release fixes a small bug in Mau8.


Appendix VII: Mau9

This field map was release on July 5, 2013:

Mau's release notes: 

We have just updated the mu2e magnetic design. In this new release
(version 9) we modified the angle of 16 coils of the second curve
to have the beam better centered with respect to the DS axis, per request
of Jim Miller.

The details of the coils geometries as well as the Lorentz forces under
different power scenarios can be found in docdb#2632.

The field maps can be found in docdb#1760. Rob Kutschke will make those
field maps available in the framework.

If you have any question, please let me know.

The available variants on Mau9 are:

  1. DS coils powered at 50% strength: BFieldMaps/Mau9/50Percent
  2. DS coils powered at 70% strength: BFieldMaps/Mau9/DS_70Percent
  3. DS coils powered at 85% strength: BFieldMaps/Mau9/DS_70Percent
  4. Mau did a study in which he randomized DS coil locations (and currents?) within nominal tolerances. He computed the DS field maps for 100 trials and looked for examples that had extreme gradients. He chose 3 maps as representative of the exteme cases: one that with a maximum gradiant and two with a minimum gradient. These maps are:
    • BFieldMaps/Mau9/MisAlignedCoils/Mu2e_DSMap_MaxGradient.txt
    • BFieldMaps/Mau9/MisAlignedCoils/Mu2e_DSMap_MinGradient_1.txt
    • BFieldMaps/Mau9/MisAlignedCoils/Mu2e_DSMap_MinGradient_2.txt


Appendix VIII: Mau10

This field map was made available Dec 17, 2015. Mau's statement about the physics content of Mau10 is: 

The magnetic design V10 had a slightly change in geometry and position of a
few coils in TS1, TS3 and TS5 region to conform with mechanical aspects of
the housing supports or the interference with the cryostat.

No changes in any other magnets!

Attention: V10 does not include any of the on-going modification proposed by
General Atomics on the DS coils. The maps were generated using ideal solenoids.


The files can be found at: 

/grid/fermiapp/mu2e/DataFiles/BFieldMaps/Mau10
/cvmfs/mu2e.opensciencegrid.org/DataFiles/BFieldMaps/Mau10

For Mau10 the three field maps used by the UCI design of the extinction monitor are no longer needed and have not been provided.

There has been a small reorganization of the Mau10 field map directory. All of the standard maps have been moved into the subdirectory: 

BFieldMaps/Mau10/Standard_Maps

These include: 

Standard_Maps/Mu2e_DSMap.txt
Standard_Maps/Mu2e_PSMap.txt
Standard_Maps/Mu2e_TSdMap.txt
Standard_Maps/Mu2e_TSuMap.txt
Standard_Maps/DSExtension.txt
Standard_Maps/PSAreaMap.txt
Standard_Maps/ProtonDumpAreaMap.txt
Standard_Maps/PStoDumpAreaMap.txt

The variants of Mau10 that have been provided are:

  1. DS coils powered at 50% strength: Mau10/Calibration/DS_at_50_percent/
  2. DS coils powered at 70% strength: Mau10/Calibration/DS_at_70_percent/
  3. DS coils powered at 85% strength: Mau10/Calibration/DS_at_85_percent/
  4. Coils off - see below for description:
    • Mau10/Coils_Off/DS_OFF
    • Mau10/Coils_Off/PS_OFF
    • Mau10/Coils_Off/TS_OFF
    • Mau10/Coils_Off/TS_and_DS_OFF
    • Mau10/Coils_Off/TS_and_PS_OFF
  5. Random points - see below

The coils off maps are most easily described by an example. To compute the DS_Off maps, the current in all DS coils was set to zero and 4 maps were computed: DS, PS, TSu and TSd. We will ask General Atomics to provide the same 4 maps but with the PS, and TS currents set to zero. This will allow us to combine the Mau10 DS_Off maps with the GA maps to form complete maps that have contributions from two sources. This allows designers of the different subsystems to work independently, without knowledge of the details of the other subsystems. Hopefully the directory names are self descriptive; in some directories, not all maps are provided because some are the field values are so low as to be uninteresting.

In order to test interpolation algorithms Mau has provided a file with the BField evaluated at 10,000 random points within the vaccum volume of the DS. This file is intended to be used to tool up these tests. Additional files can be provided upon request.

In January, 2017, Hank Glass succeeded Mau as the provider of magnetic field maps for Mu2e. The following appendix describes maps produced since that time.

Appendix IX: Helical Coil Maps Mau11, Mau12, and Mau13

While modeling the magnet coils as ideal solenoids leads to reasonably good approximations of the fields for the PS and TS, greater accuracy is required for the DS field map. Two major advances make this possible. The first is to represent the coils as helical windings. This introduces a non-zero azimuthal field component B_phi. The second advance is to include a model of the bus work, which produces an appreciable contribution to the DS field.

General Atomics produced for the Mu2e Collaboration a series of field maps using a helical model described above. Maps GA04 and GA05 became the default maps for a time for physics analysis. They were generated via OPERA using helical windings for the DS. A known shortcoming of these maps was the lack of a realistic buswork model.

Implementation of a model of the buswork and its inclusion in the OPERA helical model became the goal for the next Fermilab-developed field maps, which became known as Mau11 (Mu2e-doc-13443, Mu2e-doc-13440). The overview document in 13443 describes improvements to the helical model and also describes details of the buswork. While the Mau11 map has been superseded by subsequent maps, the overview document is worth reading for its description of the general modeling procedure. Mau11 was released on 26 Oct 2017.

Subsequent analysis (Mu2e-doc-14304) revealed a major problem with the geometry, not only with Mau11, but with GA04 and GA05 as well. Inspection of the geometry files for these maps revealed that the z-positions used for placement of the DS coils were taken from the GA warm design. Corrections for the significant shifting of the coil positions due to thermal contraction had not been done. This rendered all of these maps invalid.

This situation was corrected in the next map, Mau12. Starting from the GA (warm) design and then applying a thermal contraction estimate, corrected z-positions for the DS coils were obtained and a new set of maps generated (Mu2e-doc-14586 and Mu2e-doc-14799). Mau12 was released on 11 Dec 2017. Note that even after thermal correction, the z-positions of Mau9 are not recovered, but differ typically by a few mm. This is due to several permitted design changes that GA made to the coil layout.

A careful review of the GA design drawings revealed that even after correcting for thermal contraction, the DS coils were ~ 6 mm longer than those in the reference design. While this is small compared to the overall coil lengths, it represents a non-negligible partial closing of the inter-coil gaps, particularly in the tracker constant field region. An improved implementation of the coil lengths was introduced and the current field map set, Mau13, was released on 13 Feb 2018. Release notes are found in Mu2e-doc-15399.

Mau13 includes the standard maps: 

DSMap.txt
TSdMap.txt
TSuMap.txt
PSMap.txt
DSExtension.txt
PSAreaMap.txt
PStoDumpAreaMap.txt
ProtonDumpAreaMap.txt

The general policy is to use the DS helical model with its buswork in regions where the field differs from the field of an idealized solenoid model by > 5 gauss. By this criterion, maps DSMap and TSdMap use the helical model for the DS along with its buswork. All other maps use ideal solenoids only to model the DS contribution (no buswork). In all cases, the PS and TS are represented as ideal solenoids.

Another map, DSFringeArea.txt, is made using the DS helical model with buswork. This map surrounds the entire DS and extends outward to the boundary where the absolute difference between the helical model and ideal solenoid model differ by 5 gauss. This volume is bounded by -5096 < x < -2696 mm, |y| < 2500 mm, and 1600 < z < 16000 mm. Sampling size is 100 mm.

A final map, WorldMap, is made using the ideal solenoid model and is intended to map the far field region. Its volume is bounded by |x| < 10 m, |y| < 8 m, and -15 < z < 42 m. The volume is just large enough to include the location of the STM at the far downstream wall. Sampling size is 200 mm. Its main purpose is for use in cosmic ray studies.

To insure obtaining the most accurate estimate of the field at any point (x, y, z), the following recipe should suffice:

  1. Is the point within the volume of DSMap or TSdMap? If so, use one of these maps.
  2. Otherwise, is the point within the volume of DSFringeArea? If so, use this map.
  3. Otherwise, is the point within the volume of any of the other standard maps listed above? Note that all of the standard maps are non-overlapping.
  4. If all else fails, use the WorldMap.

Questions about these maps should be directed to Hank Glass.

[1] Glass, H., “Comparison of Idealized Solenoids with Helical Coils,” (2017) Mu2e-doc-8851

Retrieved from "http://mu2ewiki.fnal.gov/w/index.php?title=MagneticFieldMaps&oldid=21122"