SWGuideMagneticField < CMSPublic

CMSPublic Web>SWGuide>SWGuideMagneticField (2020-04-24, NicolaAmapane) (raw view)
---+ Magnetic Field Interface

%TOC{title="Contents:"}%

---++ Contacts
   * *TOSCA computation*: Vyacheslav Klyukhin
   * *CMSSW interface*: Nicola Amapane
---++ Default configuration

The python configuration to get the default field map is:

<pre>process.load("Configuration.StandardSequences.MagneticField_cff")
</pre>

This sets the the map so that the Run I/Run II map is chosen automatically based on the GT, and the nominal working point is set automatically depending on the magnet current stored in the conditions DB (!RunInfo). Nominal working points are:
   * 0 T
   * 2 T (9500 A)
   * 3 T (14340 A)
   * 3.5 T (16730 A)
   * 3.8 T (18164 A)
   * 4 T (19140 A)

*For the MC*, the magnet current in conditions is fixed, and corresponds to the 3.8 T working point; so the above always results in the 3.8 T map for MC GTs.

In order to configure CMSSW for *zero field (magnet off) in MC* one needs to replace the config with:

<pre>process.load("Configuration.StandardSequences.MagneticField_0T_cff")
</pre>

Other nominal working points can be forced by replacing the "valueOverride" parameters that are set in the same file.

---++ Access to the map

The magnetic field map is available in CMSSW from the !EventSetup as an object of type <span>CMS.MagneticField</span>. An example of getting the magnetic field in CMSSW is available in

<pre>CMS.MagneticField/Engine/test/queryField.cc
CMS.MagneticField/Engine/test/queryField.py</pre>

This is everything needed for the general user.

---++ Internals

The following sections include developer documentation and are not relevant for users.

---+++ How the field map works

Concrete implementations ("engines") of =a <nop>MagneticField= are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called <nop>VolumeBasedMagneticField, and is based on a geometrical description of the solenoid and yoke volumes, with a separate "field provider" for each volume. Normally a field provider is based on interpolation over a grid of points tabulated with a finite-element computation.<br /> Providers can however also be based on e.g. parametrizations. <br />A special region is the inner tracker region. Here, <nop>VolumeBasedMagneticField allows to specify an ad-hoc parametrization to replace the normal volume/field provider mechanism, for either speed or accuracy purposes. Technically this is implemented by overlaying a "slave field engine" with a defined spatial validitity region.

A *"static" map*, representing the MF for a given era (Run I or Run II) and current, can be created explicitly with e.g. =MagneticField/Engine/python/volumeBasedMagneticField_160812_cfi.py= ( [[https://github.com/cms-sw/cmssw/blob/CMSSW_11_0_X/MagneticField/Engine/python/volumeBasedMagneticField_160812_cfi.py][link]]). This cfi defaults to 3.8T, RunII map.It sets:
   * MF geometry reader
   * the parametrized map to be used in the tracker region
   * the actual VolumeBased map, whose configuration includes specification of the field data tables to be used (=version=) and how tables are associated to volumes (=gridFiles=).
Static maps should *not* be used in production.

The *default map is dynamic* and built with =Configuration.StandardSequences.MagneticField_cff=, which retrieves the appropriate geometry and configuration from DB for the given GT and IOV.
The internals of this builder is docomented in the following section.

---+++ Map sets and configuration in db

A map set consists of six maps for the five nominal operation currents, corresponding to 2, 3, 3.5, 3.8 and 4T, plus a zero-field map. The configuration for each map is stored in the condition DB in a !MagneticFieldConfig object i, which includes:
   * a MF geometry version (int);
   * a data table version (string);
   * a map of table names to be associated to volumes;
   * optional scaling factors for specific tables;
   * name and parameters of a slave parametrized field for the tracker region.

In each GT, configuration for all six maps of the set must be present. They are stored as separate !MagneticFieldConfig objects with the pre-defined labels "0T", "2T", "3T", "3.5T", "3.8T", "4T".
The appropriate one is retrieved by label based on the coil current stored in the !RunInfoRecord,

The geometry version of the required configuration is used to retrieve the correct geometry from the db by label. Each GT thus contains all required geometries, attached to the record !MFGeometryFileRcd,  with labels like "180812", "90322", etc.

To find what maps are included in a given GT, search fror the GT in conddb, eg for data and Run1/Run2 MC:
   * data: [[https://cms-conddb.cern.ch/cmsDbBrowser/list/Prod/gts/100X_dataRun2_HLT_v3][100X_dataRun2_HLT_v3]]
   * MC, run1: <a href="https://cms-conddb.cern.ch/cmsDbBrowser/list/Prod/gts/100X_mcRun1_design_v2" title="100X_mcRun1_design_v3">90X_mcRun1_design_v2</a>
   * MC, run2: [[https://cms-conddb.cern.ch/cmsDbBrowser/list/Prod/gts/100X_mcRun2_design_v2][100X_mcRun2_design_v2]]
Search for "MagFieldConfigRcd" in the Tags List table. You should get six entries with the labels "0T","2T", "3T", "3.5T", "3.8T", "4T" for the six maps of the set.

Note that for data, the map should have IOVs for Run1/Run2 as needed. For MC, there should be only 1 valid IOV, since there are different GTs for Run1 or Run2.

Available geometries can instead be found searching for "MFGeometryFileRcd".

The following table summarizes the currently used map sets.

<table align="center" border="1" cellpadding="0" cellspacing="0"> <tbody> <tr> <td align="center"> *Current (A)* </td> <td align="center"> *B(T)* </td> <td align="center"><b>MagFieldConfigRcd Tag<br />Run I (from:1)<br /></b></td> <td align="center"><b>MagFieldConfigRcd tag<br />Run II (from:220641)<br /></b></td> <td align="center"> *Note* </td> </tr> <tr> <td align="center">0-4779</td> <td align="center">0</td> <td align="center" colspan="2">%LIME%MFConfig_71212_0T%ENDCOLOR%</td> <td align="center">requires tables from grid_1103l_071212_4t even if zero field</td> </tr> <tr> <td align="center">4779-11987</td> <td align="center">2</td> <td align="center" colspan="2">%LIME%MFConfig_71212_2T%ENDCOLOR%</td> <td align="center">Run I version, but we don't really care about 2T</td> </tr> <tr> <td align="center">11987-15617</td> <td align="center">3</td> <td align="center" colspan="2">%GREEN%MFConfig_160812_Run2_3T%ENDCOLOR%</td> <td align="center">Run II version; used also for Run conditions</td> </tr> <tr> <td align="center">15617-17543</td> <td align="center">3.5</td> <td align="center" colspan="2">%GREEN%MFConfig_160812_Run2_3_5T%ENDCOLOR%</td> <td align="center">ditto</td> </tr> <tr> <td align="center" rowspan="2">17543-18765</td> <td align="center" rowspan="2">%RED%3.8%ENDCOLOR%</td> <td align="center">
MC tag:<br />%GREEN%MFConfig_160812_Run1_3_8T%ENDCOLOR%</td> <td align="center">MC tag:%GREEN%<br />MFConfig_160812_3_8T%ENDCOLOR%</td> <td align="center" rowspan="2"> </td> </tr> <tr> <td align="center" colspan="2">%BLACK%Data tag: %ENDCOLOR%%LIME% *MFConfig_RI_RII_160812_3_8T* %ENDCOLOR%</td> </tr> <tr> <td align="center">&gt;18765</td> <td align="center">4</td> <td align="center" colspan="2">%LIME%MFConfig_71212_4T%ENDCOLOR%</td> <td align="center">Not really needed, but we keep it nevertheless.</td> </tr> </tbody> </table> cf TagsForMagneticField160812

---++++ Summary of MF geometries currently loaded in the DB

XML files for the different geometry versions are located under MagneticField /GeomBuilder/data:

   * version 90322: =MagneticFieldVolumes_1103l.xml=. This geometry is suitable for rarely used maps (currently, only 2T and 4T)
   * version 120812: =MagneticFieldVolumes_1_v7_large.xml=, =MagneticFieldVolumes_2_v7_large.xml= - %RED%no longer in use, should be removed from future GTs%ENDCOLOR%
   * version 130503: =MagneticFieldVolumes_1_v9_large.xml=, =MagneticFieldVolumes_2_v9_large.xml= - %RED%no longer in use, should be removed from future GTs%ENDCOLOR%
   * version 160812: =MagneticFieldVolumes_160812_1.xml=, =MagneticFieldVolumes_160812_2.xml= Current up-to-date geometries.

---+++ Data tables

The actual field data is stored in tables that are published under: [[https://github.com/cms-data/MagneticField-Interpolation]]

The grids in use in current releases are:

grid_11103l_071212_2t<br />grid_11103l_071212_4t<br />grid_160812_3t<br />grid_160812_3_5t<br />grid_160812_3_8t<br />grid_160812_3_8t_Run1

%RED%The following grids are no longer used and can be removed:%ENDCOLOR%

grid_1103l_071212_3t<br />grid_1103l_071212_3_5t<br />grid_1103l_071212_3_8t<br />grid_120812_3_8t_v7_large<br />grid_120812_3_8t_v7_small<br />grid_130503_3_8t_v9_large<br />grid_130503_3_8t_v9_small<br />grid_1103l_090322_3_8t
---++ Development workflow

The steps described below must be followed, in their order, to prepare, validate and deploy a new set of maps, assuming the starting point is a new xml geometry and a corresponding set of TOSCA grid tables in txt format.
For new tables for an already existing geometry, the first part can be skipped.
---+++ Preparing a new geometry

Add the new xml file(s) in =Magfield/GeomBuilder/data=. Test geometry building by preparing a config file like =MagneticField/Engine/python/volumeBasedMagneticField_130503_cfi.py=, specifying:
   * the new xml files in =magfield.geomXMLFiles=
   * an empty =VolumeBasedMagneticFieldESProducer.gridFiles= list <p> </p>

Set this cfi in  =MagneticField/Engine/test/testMagneticField_cfg.py= instead of the default one, and set =process.VolumeBasedMagneticFieldESProducer.debugBuilder = True= .
Run this and search for errors (“ERROR”). Some WARNINGs are normal if mismatches are small (normally &lt;0.04 cm; can get up to 0.2 cm) .

The =debugBuilder= flag  activates the test ==MagGeoBuilderFromDDD::testInside==, which tests that the center of a volume is inside it and outside all other volumes. There must be no error.

Also run with =process.testVolumeGeometry = cms.EDAnalyzer("testMagGeometryAnalyzer")=. This calls ==MagGeometryExerciser::testFindVolume==, which checks random points: the corresponding volume should be found, and the points must be inside() one and only one volume. There must be no error. Note: internally this uses uses =MagGeometry::findVolume=, that has a retry mechanism with increased tolerance to avoid tiny gaps.

---+++ Table conversion

To convert txt tables (extracted from TOSCA), use =MagneticField/Interpolation/test/BinaryTablesGeneration/convertTables.py=. Check for ERROR s in the output.
Note that files are provided both with cartesian (xyz) and cylindrical coordinates (rpz). They are equivalent, but it is better to use rpz for all volume types except than for Box and Trapezoid volumes.

Once completion is completed with no error, copy the new set of maps into =MagneticField/Interpolation/data= following the existing directory structure. Edit the cfi file (eg.
=MagneticField/Engine/python/volumeBasedMagneticField_130503_cfi.py=) and set =VolumeBasedMagneticFieldESProducer.version= to the name of the newly created directory in =MagneticField/Interpolation/data=, and specify the matching between grid files and volumes, eg:

<verbatim>
    gridFiles = cms.VPSet(
           cms.PSet(
               volumes   = cms.string('1001-1464,2001-2464'),
               sectors   = cms.string('0') ,
               master    = cms.int32(=),
               path      = cms.string('s[s]/grid.[v].bin'),
           ),</verbatim>

With this syntax, all volumes numbered with range 1001-1464 and 2001-2464 for all sectors (0=all) are associated to the file s[sector]/grid.[volumeNumber].bin. The =master= specification can be used to use the table for a given sector for other sector as well by rotation, in order to save memory; 0 means that each sector will use its own specific table.

Run =testMagneticField_cfg.py= with =debugBuilder = True= as explained above. It should now try to build interppolators for all volumes, reading the data tables. In addition a test is done, that each grid point should be inside() the corresponding volume. Search for ERRORs. They can be either due to errors in the tables (e.g. irregular grid spacing), or in the geometry (volume boundaries not matching the actual grid).
To debug possible problems with the grid tables, =MagneticField/Interpolation/test/BinaryTablesGeneration/GridFileReader.cpp= can be used to dump table grid and values. To dump the memory representation of the yable, opem =MagneticField/Engine/test/testMagneticField.cc= and uncomment/edit the block containing =vol-&gt;provider()= according to specific needs.

The final check is to run a regression of the field map vs the data tables, using =Interpolation/test/BinaryTablesGeneration/validateField_TOSCATables.py=. Set the cfi.py for the new geometry; the list of tables is taken from a file =tableList.txt=, that is written during conversion by =convertTables.py=.  
Numerical discrepancies can be present in a handful of cases up to ~0.00065 T, especially in rotated tables. This could be be due to the appearance of spurious ~0 step parameters due to rounding in rotations. This level of accuracy is acceptable. Further study/development is needed to understand how to avoid these roundings.

---+++ Publishing new tables for release

Once data tables are ready, they should be published submitting a PR to [[https://github.com/cms-data/MagneticField-Interpolation]].

---+++ Conversion of the geometry to db

Edit and run =MagneticField/GeomBuilder/test/mfxmlwriter,py= and =mfwriter.py=. The first writes the geometry in a single, self-contained  xml ; the second converts it into a .db file and creates the corresponding metadata faile for upload to the condition db.

To load the geometry in the database:
<verbatim>
uploadConditions.py <mfGeometryXXXXX.db></verbatim>

---+++ Preparing a db configuration

See above for an explanation of how map configuration is stored in the condition DB.

A map configuration can be written into a .db file  with =/CondFormats/MFObjects/test/writeMagFieldConfigDB.py=. The  the corresponding metadata faile for upload to the condition db is also created.

In general, before uploading to the condition db this .db file needs to be combined with others to get a single file with all IOVs for Run I and II maps.

---++ Debugging tools

---+++ Regression Testing

Regression testing is available to validate changes that are not expected to change the field numerically in any point. It is done comparing the field returned by the map with a reference file created for each map. To run the regression testing, use [[
https://github.com/cms-sw/cmssw/blob/master/MagneticField/Engine/test/regression.py][

MagneticField/Engine/test/regression.py]]

options:
   * =producerType=: options are '<span class="WYSIWYG_TT">static_DDD</span>', '<span class="WYSIWYG_TT">static_DD4Hep</span>', '<span class="WYSIWYG_TT">fromDB</span>', '<span class="WYSIWYG_TT">fromDB_DD4Hep</span>'
   * =era=: either '<span class="WYSIWYG_TT">RunI</span>' or '<span class="WYSIWYG_TT">RunII</span>'
   * =current=: Magnet current (nominal values: 18164=3.8T; 16730=3.5T; 14340=3T; 9500=2T).
Failures are reported in the standard output.

Regression files are maintained in [[https://github.com/cms-data/MagneticField-Engine/][cms-data/MagneticField-Engine/]].

In case outliers are found, they can be visualized with gnuplot in this way (old recipe-to be updated)
<verbatim>cmsRun regression.py > ! output.txt
grep Disc output.txt | cut -f 7 -d' ' | tr '(,)' ' ' > ! outliers
cat <reference_table.txt> | cut -d' ' -f 1,2,3 > ! allpoints</verbatim>

and in gnuplot:
<verbatim>set terminal png
set xlabel "x coordinate (cm)"
set ylabel "y coordinate (cm)"
set zlabel "z coordinate (cm)"
set output "viewXY.png"
set view 0,90
splot 'allpoints','outliers'
set output "view3D.png"
set view 30,60
splot 'allpoints','outliers'
set output "viewXZ.png" 
set view 90,0
splot 'allpoints','outliers'</verbatim>

---+++ Visualization of the field map in CMSSW

The magnetic field and MF geometry can be visualized in Eve. The field visualization is implemented in =Fireworks/Geometry/plugins/DisplayGeom.cc=. An example .py configuration is shown at:
=Fireworks/Geometry/plugins/cmsRun_displayProdMFGeom_cfg.py=.

Some notes:
   * In the Eve window, click "Camera Home" in the bottom left panel (to return to this panel later, double-click on Viewers and select Viewer 1).
   * To select/deselect individual volumes, double-click on cms:World and again on each new level of the hierarchy.
   * To choose a pre-defined perspective or orthographic view, hover with the mouse on the bar below the "Viewer 1" tab. A new menu bar appears, with predefined views under Camera. Toggle auto-hide un-ticking "File-&gt;Hide Menus" in this bar.
   * Help on visualization commands (zooming, panning, rotation etc can be found under Help in the menu bar mentioned above.
   * Exit with .q from the root shell (closing the graphical window causes a crash). <p> </p> <p> </p>

---++ Release history

The following section are kept for keeping track of past (obsolete) usage and development, and are not relevant for current users.

---+++ Configuration in older releases

In releases prior to CMSSW_7_4_3 and CMSSW_7_5_0_pre5, default configurations used to be:
   * =Configuration.StandardSequences.MagneticField_AutoFromDBCurrent_cff=: Run I maps with automatic choice of nominal working point for data; fixed 3.8T for MC
   * =Configuration.StandardSequences.MagneticField_38T_PostLS1_cff=: Run II map for 3.8T only.

When moving to CMSSW_7_4_3 and CMSSW_7_5_0_pre5, please replace these with  =Configuration.StandardSequences.MagneticField_cff= as mentioned above.
Configurations for fixed nominal working points, eg. 0 T, did not change (cf above).

---+++ History of map versions

Here is a brief description of the different development and production versions.

A collection of documents related to the field map computation, mapping, and comparison with measured data can be found [[CMS.MagneticField#Documentation][here]] .
---++++++!! Version 85l_030919 ("old 4T map"; obsolete, no longer supported)

The 4T field map used in COBRA/ORCA and in CMSSW up to series 2.0.X included is based on a TOSCA finite-element computation performed in 2003. It is based on a geometric model ("magnetic field geometry") of 271 volumes representing one 30 degree-sector in z&lt;0 only (1/24 of CMS), thus the model is Z-symmetric and 12-fold phi-symmetric. For each volume, the field is computed on a regular (non-cartesian) grid defined appropriately. The CMSSW field interface returns the field at an arbitray point using 3D linear interpolation within the grid cell containing the point inside each volume. The nominal B value in this map (4T) cannot be changed. A parametrization of the TOSCA computation (by V. Karimaki) can be optionally used in the region r&lt;1.2 m, |z|&lt;3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).

This has been the only full field map available after 2003 and before CMSSW_2_1_0.

This version is no longer supported after CMSSW_2_2_10.

---++++++!! Version 1103l_071212 (Pre-CRAFT-2009 default; 3.8T version deprecated since 3_1_X; still used for some nominal operating points other than 3.8T)

This map is in use since CMSSW 2.2. and includes improvements based on the experience of the Magnet Test, which included a mapping campaign of the field within the solenoid, as well as measurements in the yoke (with flux loops during fast discharges, and with Hall probes). It is based on a TOSCA finite-element computation with a model that includes the Z-asymmetry of the coil spires and more accurate description of a full half (x&gt;0) of CMS including chimneys. However field data is still provided only for sector 1 (30 degrees, representing 1/12 of CMS with a total of 312 volumes), so the CMSSW map is 12-fold phi-symmetric (but not Z-symmetric).

The map with this model is available for several nominal field values: 2, 3, 3.5, 3.8 and 4T. The latter is expected to be different (more realistic) w.r.t. the previous 4T computation (85l_030919). <br />A parametrization of the TOSCA computation within r&lt;1.15 m, |z|&lt;2.8 m is available for all field values (V. Karimaki). This parametrization matches very well with the computed data (difference of ~5mT at the edges of the validity region) and *is used as a slave field in the default configuration* (cf section above), mainly to save CPU time in production and HLT.

<br />A different parametrization of the *real mapping data* (V. Maroussov) is available *as an option*. It is defined in the region r&lt;1.9 m, |z|&lt;3.5m, excluding the "corners" |z|+2.5*r&gt;6.7 m. This parametrization reproduces the mapping data more precisely, but is slower; it is the suggested option for application where ultimate precision is necessary and CPU speed can be sacrificed. The agreement of this map with the mapping data is better than 0.4 mT (agreement to ~10^-4) in the tracker region and up to 0.8 mT at the edges of the validity region. To activate it specify the following:
<pre>process.ParametrizedMagneticFieldProducer.version = 'PolyFit2D'
process.ParametrizedMagneticFieldProducer.parameters = cms.PSet(
         BValue = cms.double(3.81143)
)
process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True;
</pre>

(the latter card is actually set to True by default in the standard config).

In 3.1.X releases and later, where this map version is superseeded by 1103l_090322_2pi_scaled, it can be activated using:

<pre>process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").
</pre>

The *MF geometry* for this map was (a-posteriori) labelled version *90322* and is implemented in =MagneticFieldVolumes_1103l.xml=.

---++++++!! Version 1103l_090216 (Intermediate development; no longer supported)

Improved computation w.r.t. 1103l_071212, with enlarged radius (R=30 m) of the total region where the field is computed, plus some additional details outside CMS (e.g. iron plate in the hall's floor). The same 312-volume 12-fold phi-symmetric geometry is used in the CMSSW interface. This map shows much better agreement with measurements with tracks in the iron yoke. This version was used for development only, and is no longer supported.

The map was still based on MF geometry version 90322.

---++++++!! Version 1103l_090322 (deprecated)

Based on 1103l_090216 this computation is done in volume extended also in |Z| (up to 35 m). The same 312-volume 12-fold phi-symmetric geometry is used in the CMSSW interface. Changes w.r.t. 1103l_090216 are visible basically only in the forward region.<br />This version was used for development only, and is deprecated in favor of later versions.<br />
<br />
This version was available starting from recent 2_2_X versions with the configuration:

<pre>process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")</pre>

The map was still based on MF geometry version 90322.

---++++++!! Version 1103l_090322_2pi (deprecated)

Based on 1103l_090322, uses different tables for the barrel yoke iron layers in the chimney sectors (S3, S4) and for S9, S10, S11 in the third barrel layer and in the endcaps. This version was used for development only, and is deprecated in favor of later versions.

---++++++!! Version 1103l_090322_2pi_scaled (Run I default for 3.8T, adopted starting from 3_1_0)

Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.

This version was used by default in CMSSW_3_1_0 and later releases for 3.8T (while 1103l_071212 remained the default for other nominal points)  and was superseded by new map staring from version 120812.

The map was still based on MF geometry version 90322.

---++++++!! Version 1103l_090601 (Intermediate development; no longer supported)

Same as 1103l_090322_2pi; with small correction of the TOSCA geometry in L3 of barrel sectors 9,10,11. Since  in S9,S1 the thicker L3 plates extend into air volumes 297-307, a finer grid was used for these volumes/sectors. Tables with this configuration were specified in MagneticFieldParameters _07_2pi_air.xml.

Two sets of scaling factors were prepared, based on CRAFT08 (ScalingFactors _090601_091022_cfi.py) and CRAFT08+09 (ScalingFactors _090601_091116_cfi.py). These were however never released.

Configuration (no longer supported)

<pre>process.load("MagneticField.Engine.volumeBasedMagneticField_090601_cfi")</pre>

or, to also apply scaling factors from CRAFT data:

<pre>process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")</pre>

The map was still based on MF geometry version 90322.

---++++++!! Version 090812 (Intermediate development; no longer supported)

Full TOSCA model made of two halves ( _1 for X&gt;0 and _2 for X&lt;0). Has not been released into CMSSW.

---++++++!! Version 120812 (Default for Run II since CMSSW_6_2_0; replaced for data since 743/750pre5)

Full TOSCA model made of two halves ( _1 for X&gt;0 and _2 for X&lt;0). Volume numbers are 1001-1360 and 2001-2360.Two version exist, with the additional YE4 plate (post-LS1) and without (2010-2012 geometry.)

To use it in CMSSW_6_2_0, you had to use:

<pre>process.load("MagneticField.Engine.volumeBasedMagneticField_120812_largeYE4_cfi")
</pre>

and for the 2010/2012 geometry:

<pre>process.load("MagneticField.Engine.volumeBasedMagneticField_120812_cfi")
</pre>

The map was based on a new *MF geometry version 120812* (implemented in =MagneticFieldVolumes_1_v7_large.xml, MagneticFieldVolumes _2_v7_large.xml=), which is no longer in use.

---++++++!! Version 130503 (Default for 3.8T data only, starting from 743/750pre5)

Full TOSCA model of the entire CMS; reduced memory footprint cf. [[https://indico.cern.ch/event/328166/session/1/contribution/24][this presentation]].
804 volumes per sector; volumes outside any detector are replicated starting from sector 1  (volumes extending from R~7.6 m to  to R=9 m, ie 1011, 1028-1029,1034-1035,1042-1043,1050-1051,1058-1059,1064-1065,1072-1073,1078-1079; volumes beyond |Z|&gt;10.86 ie 1084-1129,1136-1137; and the corresponding +1000).
Volumes 1134-1135 (for the volume outside CASTOR) are replicated from sector 4 instead than 1, to avoid aliasing effects due to the plates in the cylinder gap.

The map was based on the new *MF geometry version 130503* (implemented in =MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes _2_v9_large.xml=), which is no longer in use.

---++++++!! Version 160812 (Current default for 3.8, 3.5 and 3T, both data and MC since later releases in the 93X series)

Updated TOSCA model, cf. [[https://indico.cern.ch/event/642366/contributions/2606389/][this presentation]]:
   * Extend the description of the rotating shielding and TAS up to |Z|=22 m (was up to |Z|=17.86 m in the previous map)
   * Add the 18 kA current leads in the chimney in YB-1 S3

The map was computed for 3.8T, 3.5T, 3T in the RunII configuration and for 3.8T only in the RunI configuration.
It is currently used for all nominal points except for 2T for both RunI and II.

The map was based on the new *MF geometry version 160812* (implemented in  =MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes _160812_2.xml=).

---+++ Configuration of superseded table sets in DB

The following tables report the DB configurations loaded in the DB *prior* to the present version (for historical purpose only).

<table align="center" border="1" cellpadding="0" cellspacing="0"> <tbody> <tr> <td align="center" colspan="7"> *Run 1 default ("090322_2pi_scaled") - data and MC* </td> </tr> <tr> <td align="center"> *Current (A)* </td> <td align="center"> *B(T)* </td> <td align="center"> *geometryVersion* </td> <td align="center"> *Table set<br />(version)* </td> <td align="center"> *Parametrization type<br />(paramLabel)* </td> <td align="center"> *paramData* </td> <td align="center"> *scaling factors* </td> </tr> <tr> <td align="center">0-4779</td> <td align="center">0</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_4t</td> <td align="center">Uniform</td> <td align="center">0</td> <td align="center">-</td> </tr> <tr> <td align="center">4779-11987</td> <td align="center">2</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_2t</td> <td align="center">OAE_1103l_071212</td> <td align="center">2</td> <td align="center">-</td> </tr> <tr> <td align="center">11987-15617</td> <td align="center">3</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_3t</td> <td align="center">OAE_1103l_071212</td> <td align="center">3</td> <td align="center">-</td> </tr> <tr> <td align="center">15617-17543</td> <td align="center">3.5</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_3_5t</td> <td align="center">OAE_1103l_071212</td> <td align="center">3.5</td> <td align="center">-</td> </tr> <tr> <td align="center">17543-18765</td> <td align="center">%RED%3.8%ENDCOLOR%</td> <td align="center">%RED%90322%ENDCOLOR%</td> <td align="center">%RED%grid_1103l_090322_3_8t%ENDCOLOR%</td> <td align="center">%RED%OAE_1103l_071212%ENDCOLOR%</td> <td align="center">%RED%3.8%ENDCOLOR%</td> <td align="center">%RED%ScalingFactors_090322_2pi_090520_cfi%ENDCOLOR%</td> </tr> <tr> <td align="center">&gt;18765</td> <td align="center">4</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_4t</td> <td align="center">OAE_1103l_071212</td> <td align="center">4</td> <td align="center">-</td> </tr> </tbody> </table>

<table align="center" border="1" cellpadding="0" cellspacing="0"> <tbody> <tr> <td align="center" colspan="7"> *Run 2, MC* </td> </tr> <tr> <td align="center"> *Current (A)* </td> <td align="center"> *B(T)* </td> <td align="center"> *geometryVersion* </td> <td align="center"> *Table set<br />(version)* </td> <td align="center"> *Parametrization type<br />(paramLabel)* </td> <td align="center"> *paramData* </td> <td align="center"> *scaling factors* </td> </tr> <tr> <td align="center">0-4779</td> <td align="center">0</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_4t</td> <td align="center">Uniform</td> <td align="center">0</td> <td align="center">-</td> </tr> <tr> <td align="center">4779-11987</td> <td align="center">2</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_2t</td> <td align="center">OAE_1103l_071212</td> <td align="center">2</td> <td align="center">-</td> </tr> <tr> <td align="center">11987-15617</td> <td align="center">3</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_3t</td> <td align="center">OAE_1103l_071212</td> <td align="center">3</td> <td align="center">-</td> </tr> <tr> <td align="center">15617-17543</td> <td align="center">3.5</td> <td align="center">130503</td> <td align="center">%BLACK%grid_130503_3_8t_v9_large%ENDCOLOR%</td> <td align="center">%BLACK%OAE_1103l_071212%ENDCOLOR%</td> <td align="center">3.5</td> <td align="center">-</td> </tr> <tr> <td align="center">17543-18765</td> <td align="center">%RED%3.8%ENDCOLOR%</td> <td align="center">%RED%120812%ENDCOLOR%</td> <td align="center">%RED%grid_120812_3_8t_v7_large%ENDCOLOR%</td> <td align="center">%RED%OAE_1103l_071212%ENDCOLOR%</td> <td align="center">%RED%3.8%ENDCOLOR%</td> <td align="center">%RED%-%ENDCOLOR%</td> </tr> <tr> <td align="center">&gt;18765</td> <td align="center">4</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_4t</td> <td align="center">OAE_1103l_071212</td> <td align="center">4</td> <td align="center">-</td> </tr> </tbody> </table>

<table align="center" border="1" cellpadding="0" cellspacing="0"> <tbody> <tr> <td align="center" colspan="7"><strong>Run 2, data<br /></strong></td> </tr> <tr> <td align="center"> *Current (A)* </td> <td align="center"> *B(T)* </td> <td align="center"> *geometryVersion* </td> <td align="center"> *Table set<br />(version)* </td> <td align="center"> *Parametrization type<br />(paramLabel)* </td> <td align="center"> *paramData* </td> <td align="center"> *scaling factors* </td> </tr> <tr> <td align="center">0-4779</td> <td align="center">0</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_4t</td> <td align="center">Uniform</td> <td align="center">0</td> <td align="center">-</td> </tr> <tr> <td align="center">4779-11987</td> <td align="center">2</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_2t</td> <td align="center">OAE_1103l_071212</td> <td align="center">2</td> <td align="center">-</td> </tr> <tr> <td align="center">11987-15617</td> <td align="center">3</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_3t</td> <td align="center">OAE_1103l_071212</td> <td align="center">3</td> <td align="center">-</td> </tr> <tr> <td align="center">15617-17543</td> <td align="center">3.5</td> <td align="center">130503</td> <td align="center">grid_130503_3_5t_v9_large</td> <td align="center">OAE_1103l_071212</td> <td align="center">3.5</td> <td align="center">-</td> </tr> <tr> <td align="center">17543-18765</td> <td align="center">%RED%3.8%ENDCOLOR%</td> <td align="center">%RED%130503%ENDCOLOR%</td> <td align="center">%RED%grid_130503_3_8t_v9_large%ENDCOLOR%</td> <td align="center">%RED%OAE_1103l_071212%ENDCOLOR%</td> <td align="center">%RED%3.8%ENDCOLOR%</td> <td align="center">%RED%-%ENDCOLOR%</td> </tr> <tr> <td align="center">&gt;18765</td> <td align="center">4</td> <td align="center">90322</td> <td align="center">grid_1103l_071212_4t</td> <td align="center">OAE_1103l_071212</td> <td align="center">4</td> <td align="center">-</td> </tr> </tbody> </table>
---++ Fancy use cases
---+++ How to load two field maps in the same job

Any number of different maps can be loaded in the same job and accessed in parallel, for e.g. comparison. One of them will be the "standard" one which is visible by all modules; it will be the one with a null label., the others are available in the job using their specific non-null label. In the following example we specify a second map with label '090216_3_8t' in addition to the standard one (default 3.8T map).

<pre># The standard one
process.load("Configuration.StandardSequences.MagneticField_38T_cff")



# The new one with label "090216_3_8t"
# Note I use a different process name than what us used in the default.
process.VolumeBasedMagneticFieldESProducerNew = 
cms.ESProducer("VolumeBasedMagneticFieldESProducer",
   timerOn = cms.untracked.bool(False),
   useParametrizedTrackerField = cms.bool(False),
   label = cms.untracked.string('090216_3_8t'),
   version = cms.string('grid_1103l_090216_3_8t'),
   debugBuilder = cms.untracked.bool(False),
   cacheLastVolume = cms.untracked.bool(True),
   scalingVolumes = cms.vint32(),
   scalingFactors = cms.vdouble()
)

</pre>

In the code, you will then be able to get both fields maps:

<pre>ESHandle&lt;CMS.MagneticField&gt; magfield;
setup.get&lt;IdealMagneticFieldRecord&gt;().get(magfield);

ESHandle&lt;CMS.MagneticField&gt; newMagfield;
setup.get&lt;IdealMagneticFieldRecord&gt;().get("090216_3_8t",newMagfield);
</pre>

---+++ How to apply per-volume rescaling factors

A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector. <br /> <br />The scaling is provided with two matching vectors. The first vector lists the volumes, encoded as (100*volume number + sector). Entries with sector=0 will match all sectors for which a specific sector entry is not set.<br />The second vector specifies the corresponding scaling factors.<br /><br />The volume numbers for the iron yoke plates can be obtained from this [[http://cmsdoc.cern.ch/cms/Physics/muon/www/Magfield/transverse.pdf][schema]].

In version, 1103l_090322_2pi_scaled, the default scaling factors are implemented in [[http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/MagneticField/Engine/python/ScalingFactors_090322_2pi_090520_cfi.py?revision=1.2&view=markup][MagneticField/Engine/python/ScalingFactors_090322_2pi_090520_cfi.py]]. If you need to test modified scaling factor, please use this file as a starting point.

Annotated lists of volumes (actual factors are NOT significant):
   * [[%PUBURL%/CMS/CMS.MagneticFieldIssues/MagnetScalingFactors.py.txt][all barrel yoke iron volumes, including brackets]].
   * [[%ATTACHURL%/EndcapScalingFactors.py.txt][endcap iron disks volumes]] <p> </p> <p> </p> <p> </p> <p> </p> <p> </p>

#ReviewStatus

---++!! Review status

<!-- Add your review status in this table structure with 2 columns delineated by three vertical bars -->

| *Reviewer/Editor and Date (copy from screen)* | *Comments* |
| Main.KatiLassilaPerini - 23 Jan 2007 | created template page  |
| Main.NicolaAmapane - 01 Jul 2008 |  first edit |
| Main.NicolaAmapane - 10 Aug 2019 | review |
<!-- In the following line, be sure to put a blank space AFTER your name; otherwise the Summary doesn't come out right. -->

%RESPONSIBLE% <nop>Nicola Amapane %BR%
%REVIEW% Never reviewed

<div id="_mcePaste" style="overflow: hidden; position: absolute; left: -10000px; top: 3105px; width: 1px; height: 1px;"> <pre>CMS.MagneticField/GeomBuilder
</pre> </div>
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
txt	EndcapScalingFactors.py.txt	r1	manage	0.4 K	2009-05-14 - 16:10	NicolaAmapane	Scaling factors for endcap yoke volumes (example syntax)
Topic revision: r43 - 2020-04-24 - NicolaAmapane
CMSPublic
Create a LeftBar
Public webs
- Cern Search
- TWiki Search
- Google Search
CMSPublic All webs
Copyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback