Difference: SWGuideMagneticField (1 vs. 42)

Revision 422019-08-10 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 9 to 9
 
  • CMSSW interface: Nicola Amapane

Default configuration

Changed:
<
<
The python configuration to get the default field map is, since CMSSW_7_4_3 and CMSSW_7_5_0_pre5 (see below for older releases):
>
>
The python configuration to get the default field map is:
 
process.load("Configuration.StandardSequences.MagneticField_cff")
Line: 21 to 21
 
  • 3.8 T (18164 A)
  • 4 T (19140 A)
Changed:
<
<
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. In order to configure CMSSW for zero field (magnet off) in MC one needs to replace the config with:
>
>
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:

 
process.load("Configuration.StandardSequences.MagneticField_0T_cff")
Changed:
<
<
Similarly, to fix the map to other nominal working points, replace "0T" with one of the following: "20T", "30T", "35T". Note that this is not necessary for data.

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

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

Access to the map

Line: 48 to 39
 

Internals

Changed:
<
<
The following sections include developer documentation and non-standard and advanced options that may be needed for specific studies.
>
>
The following sections include developer documentation and are not relevant for users.
 

How the field map works

Changed:
<
<
Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called 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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
>
>
Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called 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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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 ( 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:

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.

Current (A) B(T) MagFieldConfigRcd Tag
Run I (from:1)
MagFieldConfigRcd tag
Run II (from:220641)
Note
0-4779 0 MFConfig_71212_0T requires tables from grid_1103l_071212_4t even if zero field
4779-11987 2 MFConfig_71212_2T Run I version, but we don't really care about 2T
11987-15617 3 MFConfig_160812_Run2_3T Run II version; used also for Run conditions
15617-17543 3.5 MFConfig_160812_Run2_3_5T ditto
17543-18765 3.8 MC tag:
MFConfig_160812_Run1_3_8T
MC tag:
MFConfig_160812_3_8T
Data tag: MFConfig_RI_RII_160812_3_8T
>18765 4 MFConfig_71212_4T Not really needed, but we keep it nevertheless.
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 - no longer in use, should be removed from future GTs
  • version 130503: MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes_2_v9_large.xml - no longer in use, should be removed from future GTs
  • 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
grid_11103l_071212_4t
grid_160812_3t
grid_160812_3_5t
grid_160812_3_8t
grid_160812_3_8t_Run1

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

grid_1103l_071212_3t
grid_1103l_071212_3_5t
grid_1103l_071212_3_8t
grid_120812_3_8t_v7_large
grid_120812_3_8t_v7_small
grid_130503_3_8t_v9_large
grid_130503_3_8t_v9_small
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

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

    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'),
           ),

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

uploadConditions.py <mfGeometryXXXXX.db>

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 the head version of:

CMS.MagneticField/Engine/test/regression.py

This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.

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

Release history

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

 
Changed:
<
<
With this setting, a field map with label = 'parametrizedField' is searched for in the <nop>EventSetup and used for the inner tracker region.
>
>

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

Line: 64 to 207
 A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)
Changed:
<
<
The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).
>
>
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<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<1.2 m, |z|<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.

Changed:
<
<
Version 1103l_071212 (Pre-CRAFT default; deprecated since 3_1_X; still used for some nominal operating points other than 3.8T)
>
>
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>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).
Changed:
<
<
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). Physics analyses should use the 3.8T map.
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
>
>
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).
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
 
A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:
Line: 91 to 234
 
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").
Added:
>
>
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.

Added:
>
>
The map was still based on MF geometry version 90322.
 
Version 1103l_090322 (deprecated)
Changed:
<
<
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.
This version was used for development only, and is deprecated in favor of later versions.

This version will is available since recent 2_2_X versions with the configuration:
>
>
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.
This version was used for development only, and is deprecated in favor of later versions.

This version was available starting from recent 2_2_X versions with the configuration:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
Added:
>
>
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.

Changed:
<
<
Version 1103l_090322_2pi_scaled (Run I default , adopted starting from 3_1_0)
>
>
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.
Changed:
<
<
This version is used by default in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \CMS.MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")
>
>
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)
Line: 124 to 275
 or, to also apply scaling factors from CRAFT data:
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")
Added:
>
>
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>0 and _2 for X<0). Has not been released into CMSSW.

Line: 132 to 285
  Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Volume numbers are 1001-1360 and 2001-2360.Two version exist, with the additional YE4 plate (post-LS1) and without (2010-2012 geometry.)
Changed:
<
<
To use it in CMSSW_6_2_0, you need to use:
>
>
To use it in CMSSW_6_2_0, you had to use:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_120812_largeYE4_cfi")

and for the 2010/2012 geometry:

process.load("MagneticField.Engine.volumeBasedMagneticField_120812_cfi")
Changed:
<
<
Version 130503 (Default for data only, starting from 743/750pre5)
>
>
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. 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|>10.86 ie 1084-1129,1136-1137; and the corresponding +1000).
Changed:
<
<
Volumes 1134-1135 (for the volume outside CASTOR) are replicated from sector 4 instead than 1, to avoid aliasing effect due to the plates in the cylinder gap.
>
>
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.
 
Changed:
<
<

Map sets and configuration in db

>
>
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.
 
Changed:
<
<
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.
>
>
Version 160812 (Current default for 3.8, 3.5 and 3T, both data and MC since later releases in the 93X series)
 
Changed:
<
<
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,
>
>
Updated TOSCA model, cf. 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
 
Changed:
<
<
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 "120812", "130505", etc.
>
>
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.
 
Changed:
<
<
To find what maps are included in a given GT, search fror the GT in conddb, eg for data and Run1/Run2 MC: 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.
>
>
The map was based on the new MF geometry version 160812 (implemented in MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes _160812_2.xml).
 
Changed:
<
<
Note that for data, the map should have IOVs for Run1/Run2 as needed. For MC, there should be only 1 valid IOV, depending on whether the GT is for Run1 or Run2.
>
>

Configuration of superseded table sets in DB

 
Changed:
<
<
Available geometries can instead be found searching for "MagFieldConfigRcd".

The following table summarizes the currently used map sets.

>
>
The following tables report the DB configurations loaded in the DB prior to the present version (for historical purpose only).
 
Run 1 default ("090322_2pi_scaled") - data and MC
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 90322 grid_1103l_090322_3_8t OAE_1103l_071212 3.8 ScalingFactors_090322_2pi_090520_cfi
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, MC
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 120812 grid_120812_3_8t_v7_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, data
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
Changed:
<
<
Future map set, based on 160812, configuration labels per IOV:

Current (A) B(T) Run I (from:1)
Run II (from:220641)
Note
0-4779 0 MFConfig_71212_0T requires grid_1103l_071212_4t
4779-11987 2 MFConfig_71212_2T Run I version, but we don't really care about 2T
11987-15617 3 MFConfig_160812_Run2_3T A specific Run I version is not needed
15617-17543 3.5 MFConfig_160812_Run2_3_5T ditto
17543-18765 3.8

MC tag:
MFConfig_90322_2pi_scaled_3_8T

OR
MFConfig_160812_Run1_3_8T

MC tag:
MFConfig_160812_3_8T

Must decide whether to use the new model for Run I as well, or not.

The data tag with 2 IOVs will be either MFConfig_RI90322_RII160812_3_8T
or MFConfig_RI_RII_160812_3_8T depending on what is chosen fro Run I.

>18765 4 MFConfig_71212_4T Not really needed?
With this map set, the following grids are no longer used:

grid_1103l_071212_3t
grid_1103l_071212_3_5t
grid_1103l_071212_3_8t
grid_120812_3_8t_v7_large
grid_120812_3_8t_v7_small
grid_130503_3_8t_v9_large
grid_130503_3_8t_v9_small
grid_1103l_090322_3_8t (ONLY IF NOT KEPT FOR RUN I)

Setting these new tables as default in the glibalTag: cf TagsForMagneticField160812

Magnetic field map geometries

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

  • version 90322: MagneticFieldVolumes_1103l.xml. This geometry is suitable for all older maps in different releases.
  • version 120812: MagneticFieldVolumes_1_v7_large.xml, MagneticFieldVolumes_2_v7_large.xml
  • version 130503: MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes_2_v9_large.xml
  • version 160812: MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes_160812_2.xml

Other options

How to load two field maps in the same job
>
>

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).
Added:
>
>
 
# The standard one
process.load("Configuration.StandardSequences.MagneticField_38T_cff")

Line: 237 to 358
 setup.get<IdealMagneticFieldRecord>().get("090216_3_8t",newMagfield);
Changed:
<
<
How to apply per-volume rescaling factors
>
>

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.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.
Line: 245 to 366
  Annotated lists of volumes (actual factors are NOT significant):
Changed:
<
<

Development of new maps

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

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

    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'),
           ),

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

uploadConditions.py <mfGeometryXXXXX.db>

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 the head version of:

CMS.MagneticField/Engine/test/regression.py

This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.

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

>
>
 
Line: 339 to 377
 
Reviewer/Editor and Date (copy from screen) Comments
KatiLassilaPerini - 23 Jan 2007 created template page
NicolaAmapane - 01 Jul 2008 first edit
Added:
>
>
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: Nicola Amapane

Revision 412017-07-11 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 193 to 193
 
>18765 4 MFConfig_71212_4T Not really needed?
With this map set, the following grids are no longer used:

grid_1103l_071212_3t
grid_1103l_071212_3_5t
grid_1103l_071212_3_8t
grid_120812_3_8t_v7_large
grid_120812_3_8t_v7_small
grid_130503_3_8t_v9_large
grid_130503_3_8t_v9_small
grid_1103l_090322_3_8t (ONLY IF NOT KEPT FOR RUN I)

Added:
>
>
Setting these new tables as default in the glibalTag: cf TagsForMagneticField160812
 

Magnetic field map geometries

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

Revision 402017-06-27 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 169 to 159
  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 "120812", "130505", etc.
Changed:
<
<
To find what maps are included in a given GT, search fror the GT in conddb, eg for 90X_dataRun2_HLT_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.
>
>
To find what maps are included in a given GT, search fror the GT in conddb, eg for data and Run1/Run2 MC: 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, depending on whether the GT is for Run1 or Run2.

  Available geometries can instead be found searching for "MagFieldConfigRcd".
Line: 183 to 179
  Future map set, based on 160812, configuration labels per IOV:
Changed:
<
<
Current (A) B(T) Run I (from:1)
Run II (from:220641)
Note
0-4779 0 MFConfig_71212_0T requires grid_1103l_071212_4t
4779-11987 2 MFConfig_71212_2T Run I version, but we don't really care about 2T
11987-15617 3 MFConfig_160812_Run2_3T A; specific Run I version is not needed
15617-17543 3.5 MFConfig_160812_Run2_3_5T ditto
17543-18765 3.8 MFConfig_90322_2pi_scaled_3_8T
OR
MFConfig_160812_Run1_3_8T
MFConfig_160812_3_8T Must decide whether to use the new model for Run I as well, or not.
>18765 4 MFConfig_71212_4T Not really needed?
With this map set, the following grids are no longer used:
>
>
Current (A) B(T) Run I (from:1)
Run II (from:220641)
Note
0-4779 0 MFConfig_71212_0T requires grid_1103l_071212_4t
4779-11987 2 MFConfig_71212_2T Run I version, but we don't really care about 2T
11987-15617 3 MFConfig_160812_Run2_3T A specific Run I version is not needed
15617-17543 3.5 MFConfig_160812_Run2_3_5T ditto
17543-18765 3.8

MC tag:
MFConfig_90322_2pi_scaled_3_8T

OR
MFConfig_160812_Run1_3_8T

MC tag:
MFConfig_160812_3_8T

Must decide whether to use the new model for Run I as well, or not.

The data tag with 2 IOVs will be either MFConfig_RI90322_RII160812_3_8T
or MFConfig_RI_RII_160812_3_8T depending on what is chosen fro Run I.

>18765 4 MFConfig_71212_4T Not really needed?
With this map set, the following grids are no longer used:
  grid_1103l_071212_3t
grid_1103l_071212_3_5t
grid_1103l_071212_3_8t
grid_120812_3_8t_v7_large
grid_120812_3_8t_v7_small
grid_130503_3_8t_v9_large
grid_130503_3_8t_v9_small
grid_1103l_090322_3_8t (ONLY IF NOT KEPT FOR RUN I)

Magnetic field map geometries

Revision 392017-06-22 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 152 to 152
 
Version 130503 (Default for data only, starting from 743/750pre5)

Full TOSCA model of the entire CMS; reduced memory footprint cf. this presentation.

Changed:
<
<
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|>10.86 ie 1084-1129,1136-1137; and the corresponding +1000).
>
>
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|>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 effect due to the plates in the cylinder gap.

Map sets and configuration in db

Line: 180 to 180
 
Run 2, MC
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 120812 grid_120812_3_8t_v7_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, data
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
Added:
>
>
Future map set, based on 160812, configuration labels per IOV:

Current (A) B(T) Run I (from:1)
Run II (from:220641)
Note
0-4779 0 MFConfig_71212_0T requires grid_1103l_071212_4t
4779-11987 2 MFConfig_71212_2T Run I version, but we don't really care about 2T
11987-15617 3 MFConfig_160812_Run2_3T A; specific Run I version is not needed
15617-17543 3.5 MFConfig_160812_Run2_3_5T ditto
17543-18765 3.8 MFConfig_90322_2pi_scaled_3_8T
OR
MFConfig_160812_Run1_3_8T
MFConfig_160812_3_8T Must decide whether to use the new model for Run I as well, or not.
>18765 4 MFConfig_71212_4T Not really needed?
With this map set, the following grids are no longer used:

grid_1103l_071212_3t
grid_1103l_071212_3_5t
grid_1103l_071212_3_8t
grid_120812_3_8t_v7_large
grid_120812_3_8t_v7_small
grid_130503_3_8t_v9_large
grid_130503_3_8t_v9_small
grid_1103l_090322_3_8t (ONLY IF NOT KEPT FOR RUN I)

 

Magnetic field map geometries

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

Line: 280 to 283
 

Publishing new tables for release

Changed:
<
<
Once data tables are ready, they should be published submitting a PR to https://github.com/cms-data/MagneticField-Interpolation.
>
>
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

Line: 288 to 291
  To load the geometry in the database:
Changed:
<
<
uploadConditions.py <mfGeometryXXXXX.db>
>
>
uploadConditions.py <mfGeometryXXXXX.db>
 

Preparing a db configuration

Revision 382017-06-07 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 284 to 284
 

Conversion of the geometry to db

Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
To load the geometry in the database: [in progress]
>
>
To load the geometry in the database:
uploadConditions.py <mfGeometryXXXXX.db>
 

Preparing a db configuration

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

Changed:
<
<
A map configuration can be written into a .db file with /CondFormats/MFObjects/test/writeMagFieldConfigDB.py.
>
>
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.
 
Changed:
<
<
To upload this db to the conddb: [...]
>
>
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

Revision 372017-05-26 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 152 to 152
 
Version 130503 (Default for data only, starting from 743/750pre5)

Full TOSCA model of the entire CMS; reduced memory footprint cf. this presentation.

Changed:
<
<
It will become the default for MC as well in the next MC backward-incompatible release.
>
>
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|>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 effect due to the plates in the cylinder gap.
 

Map sets and configuration in db

Line: 266 to 267
  path = cms.string('s[s]/grid.[v].bin'), ),
Changed:
<
<
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).
>
>
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->provider() according to specific needs.

Revision 362017-05-26 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 276 to 276
 

Publishing new tables for release

Changed:
<
<
...in progress...
>
>
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

Revision 352017-05-11 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 141 to 154
 Full TOSCA model of the entire CMS; reduced memory footprint cf. this presentation. It will become the default for MC as well in the next MC backward-incompatible release.
Changed:
<
<

Map sets in production

>
>

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 "120812", "130505", etc.

 
Changed:
<
<
Run 1 default ("090322_2pi_scaled")
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 90322 grid_1103l_090322_3_8t OAE_1103l_071212 3.8 ScalingFactors_090322_2pi_090520_cfi
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
>
>
To find what maps are included in a given GT, search fror the GT in conddb, eg for 90X_dataRun2_HLT_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.
 
Changed:
<
<
Run 2, current default
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 120812 grid_120812_3_8t_v7_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
>
>
Available geometries can instead be found searching for "MagFieldConfigRcd".
 
Changed:
<
<
Run 2, development version
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
>
>
The following table summarizes the currently used map sets.
 
Added:
>
>
Run 1 default ("090322_2pi_scaled") - data and MC
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 90322 grid_1103l_090322_3_8t OAE_1103l_071212 3.8 ScalingFactors_090322_2pi_090520_cfi
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, MC
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 120812 grid_120812_3_8t_v7_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, data
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
 

Magnetic field map geometries

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

Line: 156 to 186
 
  • version 90322: MagneticFieldVolumes_1103l.xml. This geometry is suitable for all older maps in different releases.
  • version 120812: MagneticFieldVolumes_1_v7_large.xml, MagneticFieldVolumes_2_v7_large.xml
  • version 130503: MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes_2_v9_large.xml
Changed:
<
<
  • version 160812: MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes_160812_2.xml
>
>
  • version 160812: MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes_160812_2.xml

 

Other options

How to load two field maps in the same job
Line: 200 to 230
  Annotated lists of volumes (actual factors are NOT significant):
Changed:
<
<

>
>
 

Development of new maps

Added:
>
>
 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.
Line: 209 to 237
 For new tables for an already existing geometry, the first part can be skipped.

Preparing a new geometry

Added:
>
>
 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
Changed:
<
<
  • an empty VolumeBasedMagneticFieldESProducer.gridFiles list
>
>
  • an empty VolumeBasedMagneticFieldESProducer.gridFiles list

  Set this cfi in MagneticField/Engine/test/testMagneticField_cfg.py instead of the default one, and set process.VolumeBasedMagneticFieldESProducer.debugBuilder = True .
Changed:
<
<
Run this and search for errors (“ERROR”). Some WARNINGs are normal if mismatches are small (normally <0.04 cm; can get up to 0.2 cm) .
>
>
Run this and search for errors (“ERROR”). Some WARNINGs are normal if mismatches are small (normally <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.
Line: 234 to 264
  sectors = cms.string('0') , master = cms.int32(=), path = cms.string('s[s]/grid.[v].bin'),
Changed:
<
<
),
>
>
),
  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).

Changed:
<
<
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->provider() according to specific needs.
>
>
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->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.
Line: 255 to 285
 To load the geometry in the database: [in progress]

Preparing a db configuration

Deleted:
<
<
The configuration of a map is stored in a MagneticFieldConfig object, that 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. A configuration db can be created with /CondFormats/MFObjects/test/writeMagFieldConfigDB.py.
 
Changed:
<
<
In each GT, configuration for maps at 0, 2, 3, 3.5, 3.8 and 4T must be present; each one is a MagneticFieldConfig with the predefined labels "0T","2T", "3T", "3.5T", "3.8T", "4T".
>
>
See above for an explanation of how map configuration is stored in the condition DB.
 
Changed:
<
<
The appropriate one is retrieved by label based on the coil current stored in the RunInfoRecord, The geometry version for this configuration is then used to retrieve the correct geometry from the db.
>
>
A map configuration can be written into a .db file with /CondFormats/MFObjects/test/writeMagFieldConfigDB.py.

To upload this db to the conddb: [...]

 

Debugging tools

Line: 279 to 310
 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.
Changed:
<
<
  • 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->Hide Menus" in this bar.
>
>
  • 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->Hide Menus" in this bar.
 
  • Help on visualization commands (zooming, panning, rotation etc can be found under Help in the menu bar mentioned above.
Changed:
<
<
  • Exit with .q from the root shell (closing the graphical window causes a crash).
>
>
  • Exit with .q from the root shell (closing the graphical window causes a crash).

 

Revision 342017-05-08 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 250 to 250
 ...in progress...

Conversion of the geometry to db

Changed:
<
<
...in progress...
>
>
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.

To load the geometry in the database: [in progress]

Preparing a db configuration

The configuration of a map is stored in a MagneticFieldConfig object, that 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. A configuration db can be created with /CondFormats/MFObjects/test/writeMagFieldConfigDB.py.

In each GT, configuration for maps at 0, 2, 3, 3.5, 3.8 and 4T must be present; each one is a MagneticFieldConfig with the predefined 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 for this configuration is then used to retrieve the correct geometry from the db.

 

Debugging tools

Revision 332017-05-08 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 218 to 218
  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.
Changed:
<
<
Also run with process.testVolumeGeometry = cms.EDAnalyzer("testMagGeometryAnalyzer"). This calls MagGeometryExerciser::testFindVolume to Insicheck random points: they must be inside() one and only one volume. Note: internally this uses uses MagGeometry::findVolume, that has a retry mechanism with increased tolerance to avoid tiny gaps. 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.
Line: 239 to 239
  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).
Changed:
<
<
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.
>
>
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->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

...in progress...

Revision 322017-05-08 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 202 to 202
 
Deleted:
<
<
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 the head version of:

CMS.MagneticField/Engine/test/regression.py

This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.

Visualization of the field map in CMSSW

The magnetic field can be visualized in Eve.

 

Development of new maps

Line: 251 to 241
  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.
Added:
>
>

Publishing new tables for release

...in progress...

Conversion of the geometry to db

...in progress...

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 the head version of:

CMS.MagneticField/Engine/test/regression.py

This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.

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

Revision 312017-05-04 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 215 to 215
 

Development of new maps

Added:
>
>
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
Changed:
<
<
  • set process.VolumeBasedMagneticFieldESProducer.debugBuilder = True
>
>
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 <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.

Line: 230 to 234
 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.
Added:
>
>
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:

    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'),
           ),

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.

 

Review status

Revision 302017-05-03 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 149 to 149
 
Run 2, development version
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
Changed:
<
<

Magnetic field map geometries XML files for the different geometry versions are located under MagneticField/GeomBuilder/data:

>
>

Magnetic field map geometries

 
Changed:
<
<
version 90322: MagneticFieldVolumes_1103l.xml. This geometry is suitable for all older maps in different releases. version 120812: MagneticFieldVolumes_1_v7_large.xml, MagneticFieldVolumes_2_v7_large.xml version 130503: MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes_2_v9_large.xml version 160812: MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes_160812_2.xml
>
>
XML files for the different geometry versions are located under MagneticField/GeomBuilder/data:

  • version 90322: MagneticFieldVolumes_1103l.xml. This geometry is suitable for all older maps in different releases.
  • version 120812: MagneticFieldVolumes_1_v7_large.xml, MagneticFieldVolumes_2_v7_large.xml
  • version 130503: MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes_2_v9_large.xml
  • version 160812: MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes_160812_2.xml
 

Other options

How to load two field maps in the same job
Line: 214 to 216
 

Development of new maps

Preparing a new geometry

Changed:
<
<
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 * set process.VolumeBasedMagneticFieldESProducer.debugBuilder = True
>
>
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
  • set process.VolumeBasedMagneticFieldESProducer.debugBuilder = True
  Run this and search for errors (“ERROR”). Some WARNINGs are normal if mismatches are small (normally <0.04 cm; can get up to 0.2 cm) .
Changed:
<
<
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 to Insicheck random points: they must be inside() one and only one volume. Note: internally this uses uses MagGeometry::findVolume, that has a retry mechanism with increased tolerance to avoid tiny gaps. There must be no error.

>
>
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.
 
Added:
>
>
Also run with process.testVolumeGeometry = cms.EDAnalyzer("testMagGeometryAnalyzer"). This calls MagGeometryExerciser::testFindVolume to Insicheck random points: they must be inside() one and only one volume. Note: internally this uses uses MagGeometry::findVolume, that has a retry mechanism with increased tolerance to avoid tiny gaps. There must be no error.
 
Added:
>
>

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.
 

Revision 292017-05-03 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 149 to 149
 
Run 2, development version
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
Changed:
<
<
-+++ Magnetic field map geometries XML files for the different geometry versions are located under MagneticField/GeomBuilder/data:

>
>

Magnetic field map geometries XML files for the different geometry versions are located under MagneticField/GeomBuilder/data:

 
Added:
>
>
version 90322: MagneticFieldVolumes_1103l.xml. This geometry is suitable for all older maps in different releases. version 120812: MagneticFieldVolumes_1_v7_large.xml, MagneticFieldVolumes_2_v7_large.xml version 130503: MagneticFieldVolumes_1_v9_large.xml, MagneticFieldVolumes_2_v9_large.xml version 160812: MagneticFieldVolumes_160812_1.xml, MagneticFieldVolumes_160812_2.xml
 

Other options

How to load two field maps in the same job
Line: 213 to 211
  The magnetic field can be visualized in Eve.
Added:
>
>

Development of new maps

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 * set process.VolumeBasedMagneticFieldESProducer.debugBuilder = True Run this and search for errors (“ERROR”). Some WARNINGs are normal if mismatches are small (normally <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 to Insicheck random points: they must be inside() one and only one volume. Note: internally this uses uses MagGeometry::findVolume, that has a retry mechanism with increased tolerance to avoid tiny gaps. There must be no error.

 

Review status

Revision 282017-05-03 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 148 to 148
 
Run 2, current default
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 120812 grid_120812_3_8t_v7_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, development version
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
Added:
>
>
-+++ Magnetic field map geometries XML files for the different geometry versions are located under MagneticField/GeomBuilder/data:

 

Other options

How to load two field maps in the same job

Revision 272015-11-05 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 12 to 12
 
process.load("Configuration.StandardSequences.MagneticField_cff")
Changed:
<
<
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, 2, 3, 3.5 and 3.8 T.
>
>
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. In order to configure CMSSW for zero field (magnet off) in MC one needs to replace the config with:

Revision 262015-06-01 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Deleted:
<
<
Complete: 1
 

Contacts

  • TOSCA computation: Vyacheslav Klyukhin
  • CMSSW interface: Nicola Amapane
Changed:
<
<

Introduction and default configuration

>
>

Default configuration

The python configuration to get the default field map is, since CMSSW_7_4_3 and CMSSW_7_5_0_pre5 (see below for older releases):
process.load("Configuration.StandardSequences.MagneticField_cff")

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, 2, 3, 3.5 and 3.8 T.

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. In order to configure CMSSW for zero field (magnet off) in MC one needs to replace the config with:

process.load("Configuration.StandardSequences.MagneticField_0T_cff")
Similarly, to fix the map to other nominal working points, replace "0T" with one of the following: "20T", "30T", "35T". Note that this is not necessary for data.

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.
 
Changed:
<
<
The magnetic field map is available in CMSSW from the EventSetup as an object of type CMS.MagneticField.
>
>
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).
 
Changed:
<
<
An example of getting the magnetic field in CMSSW is available in
>
>

Access to the map

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

 
CMS.MagneticField/Engine/test/queryField.cc
CMS.MagneticField/Engine/test/queryField.py
Changed:
<
<
The required configuration file to get the default field map is:
process.load("Configuration.StandardSequences.MagneticField_38T_cff")
>
>
This is everything needed for the general user.
 
Changed:
<
<
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "0T", "20T", "30T", "35T", "40T".
>
>

Internals

 
Changed:
<
<
This is everything needed for the average user. The following sections cover non-standard and advanced options that may be needed for specific studies.
>
>
The following sections include developer documentation and non-standard and advanced options that may be needed for specific studies.
 
Deleted:
<
<

Advanced usage

 

How the field map works

Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called 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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:

Line: 38 to 53
 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 here .

Changed:
<
<
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)
>
>
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)
  The 4T field map used in 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<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<1.2 m, |z|<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.

Deleted:
<
<
To use this map you have to include in your cfg.py:
process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
 This version is no longer supported after CMSSW_2_2_10.
Changed:
<
<
Version 1103l_071212 (Pre-CRAFT default; deprecated since 3_1_X; still used for some nominal operating points other than 3.8T)
>
>
Version 1103l_071212 (Pre-CRAFT default; 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>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).
Line: 69 to 80
  In 3.1.X releases and later, where this map version is superseeded by 1103l_090322_2pi_scaled, it can be activated using:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").

Deleted:
<
<
 
Deleted:
<
<
Version 1103l_090216 (Intermediate development; no longer supported)
 
Changed:
<
<
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 deprecated in favor of later versions.

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
>
>
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.

 
Changed:
<
<
In previous CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data 
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Version 1103l_090322 (deprecated)
>
>
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.
This version was used for development only, and is deprecated in favor of later versions.

This version will is available since recent 2_2_X versions with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
Changed:
<
<
In older CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data 
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
Version 1103l_090322_2pi (deprecated)
>
>
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.
Changed:
<
<
To use it (in CMSSW_3_10 or 2_2_13, or later) , use:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")

Version 1103l_090322_2pi_scaled (Run I default , adopted starting from 3_1_0)
>
>
Version 1103l_090322_2pi_scaled (Run I default , adopted starting from 3_1_0)
  Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.
Line: 104 to 103
 
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")
Changed:
<
<
Due to an error in the release configuration, CMSSW_2_1_12 also requires setting (after setting up the cmssw environment, and assuming tcsh syntax):
setenv CMSSW_SEARCH_PATH /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-CMS.MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}

In older CMSSW_2_2_X releases, it is necessary to checkout and compile few packages:

cvs co -r V00-04-19 MagneticField/GeomBuilder
cvs co -r V00-03-07 MagneticField/Interpolation
cvs co -r V00-04-20 MagneticField/Engine
cvs co -r V00-02-07 MagneticField/VolumeGeometry
scramv1 b
cd MagneticField/Interpolation/data/grid_1103l_090322_3_8t
/afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh

Version 1103l_090601 (Intermediate development; no longer supported)
>
>
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 platesextend 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.

Changed:
<
<
To use it:
cvs co -r V00-04-24 MagneticField/GeomBuilder
cvs co -r V00-04-25 MagneticField/Engine
cvs co -r V00-02-09 MagneticField/VolumeGeometry 
cvs co -r V00-03-08 MagneticField/Interpolation
cvs co -r CMSSW_3_2_7 TrackPropagation/CMS.SteppingHelixPropagator
cp -r /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_1103l_090601_3_8t MagneticField/Interpolation/data 
scramv1 b

and specify in your configuration:

>
>
Configuration (no longer supported)
 
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_cfi")

or, to also apply scaling factors from CRAFT data:

process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")
Changed:
<
<
Version 090812 (Intermediate development; no longer supported)
>
>
Version 090812 (Intermediate development; no longer supported)
  Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Has not been released into CMSSW.
Changed:
<
<
Version 120812 (Current default for Run II)
>
>
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>0 and _2 for X<0). Volume numbers are 1001-1360 and 2001-2360.Two version exist, with the additional YE4 plate (post-LS1) and without (2010-2012 geometry.)
Changed:
<
<
To use it in CMSSW_6_2_X, you need to update MagneticField:

cvs co -r map120812_v1 MagneticField
cd MagneticField/Interpolation/data
ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_large .
ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_small .
cd -
scram b -j4

and specify in your configuration, for the setup with YE4:

>
>
To use it in CMSSW_6_2_0, you need to use:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_120812_largeYE4_cfi")

and for the 2010/2012 geometry:

process.load("MagneticField.Engine.volumeBasedMagneticField_120812_cfi")
Changed:
<
<
Version 130503 (new)
>
>
Version 130503 (Default for data only, starting from 743/750pre5)

Full TOSCA model of the entire CMS; reduced memory footprint cf. this presentation. It will become the default for MC as well in the next MC backward-incompatible release.

 
Deleted:
<
<
Full TOSCA model of the entire CMS.
 

Map sets in production

Run 1 default ("090322_2pi_scaled")
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 90322 grid_1103l_090322_3_8t OAE_1103l_071212 3.8 ScalingFactors_090322_2pi_090520_cfi
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Revision 252014-10-29 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 7 to 7
 

Contacts

Deleted:
<
<
  • B Field Task coordinator: Dietrich Liko
 
  • TOSCA computation: Vyacheslav Klyukhin
Changed:
<
<
  • CMSSW interface: Nicola Amapane, Martijn Mulders
  • XML field geometry: Valeri Andreev
>
>
  • CMSSW interface: Nicola Amapane
 

Introduction and default configuration

Changed:
<
<
The magnetic field map is available in CMSSW from the EventSetup as an object of type CMS.MagneticField.
>
>
The magnetic field map is available in CMSSW from the EventSetup as an object of type CMS.MagneticField.
  An example of getting the magnetic field in CMSSW is available in
CMS.MagneticField/Engine/test/queryField.cc

Line: 24 to 21
 
process.load("Configuration.StandardSequences.MagneticField_38T_cff")
Changed:
<
<
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".
Zero-field map can also be specified replacing "38T" with "0T".
>
>
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "0T", "20T", "30T", "35T", "40T".
  This is everything needed for the average user. The following sections cover non-standard and advanced options that may be needed for specific studies.
Line: 32 to 29
 

How the field map works

Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called 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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:

Changed:
<
<
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
>
>
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
  With this setting, a field map with label = 'parametrizedField' is searched for in the <nop>EventSetup and used for the inner tracker region.
Changed:
<
<

Map versions

>
>

History of map versions

 
Changed:
<
<
Different versions of the <nop>VolumeBasedMagneticField exist. Here is a brief description of the main one.
>
>
Here is a brief description of the different development and production versions.
 
Changed:
<
<
A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
>
>
A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
 
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)

The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).

Line: 50 to 46
  To use this map you have to include in your cfg.py:
Changed:
<
<
process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
>
>
process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
  This version is no longer supported after CMSSW_2_2_10.
Changed:
<
<
Version 1103l_071212 (Pre-CRAFT default; deprecated since 3_1_X)
>
>
Version 1103l_071212 (Pre-CRAFT default; 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>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).
Line: 76 to 71
 
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").

Changed:
<
<
Version 1103l_090216 (Intermediate development; deprecated)
>
>
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 deprecated in favor of later versions.

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
Line: 102 to 96
 To use it (in CMSSW_3_10 or 2_2_13, or later) , use:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")
Changed:
<
<
Version 1103l_090322_2pi_scaled (Default starting from 3_1_0)
>
>
Version 1103l_090322_2pi_scaled (Run I default , adopted starting from 3_1_0)
  Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.
Line: 123 to 117
 /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh
Changed:
<
<
Version 1103l_090601 (Intermediate development; deprecated)
>
>
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 platesextend 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.
Line: 145 to 139
 or, to also apply scaling factors from CRAFT data:
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")
Changed:
<
<
Version 090812 (Intermediate development; deprecated)
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Has not been released into CMSSW.
>
>
Version 090812 (Intermediate development; no longer supported)

Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Has not been released into CMSSW.

 
Changed:
<
<
Version 120812
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Volume numbers are 1001-1360 and 2001-2360.Two version exist, with the additional YE4 plate (post-LS1) and without (2010-2012 geometry.)
>
>
Version 120812 (Current default for Run II)

Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<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_X, you need to update MagneticField:
Changed:
<
<
cvs co -r map120812_v1 MagneticField

>
>
cvs co -r map120812_v1 MagneticField

 cd MagneticField/Interpolation/data ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_large . ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_small .
Line: 162 to 157
 scram b -j4
Deleted:
<
<
 and specify in your configuration, for the setup with YE4:
Changed:
<
<
process.load("MagneticField.Engine.volumeBasedMagneticField_120812_largeYE4_cfi")

>
>
process.load("MagneticField.Engine.volumeBasedMagneticField_120812_largeYE4_cfi")

 

and for the 2010/2012 geometry:

Changed:
<
<
process.load("MagneticField.Engine.volumeBasedMagneticField_120812_cfi")

>
>
process.load("MagneticField.Engine.volumeBasedMagneticField_120812_cfi")

 
Added:
>
>
Version 130503 (new)
 
Added:
>
>
Full TOSCA model of the entire CMS.

Map sets in production

 
Changed:
<
<

Other options

>
>
Run 1 default ("090322_2pi_scaled")
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 90322 grid_1103l_090322_3_8t OAE_1103l_071212 3.8 ScalingFactors_090322_2pi_090520_cfi
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Run 2, current default
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 90322 grid_1103l_071212_3_5t OAE_1103l_071212 3.5 -
17543-18765 3.8 120812 grid_120812_3_8t_v7_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -
 
Added:
>
>
Run 2, development version
Current (A) B(T) geometryVersion Table set
(version)
Parametrization type
(paramLabel)
paramData scaling factors
0-4779 0 90322 grid_1103l_071212_4t Uniform 0 -
4779-11987 2 90322 grid_1103l_071212_2t OAE_1103l_071212 2 -
11987-15617 3 90322 grid_1103l_071212_3t OAE_1103l_071212 3 -
15617-17543 3.5 130503 grid_130503_3_5t_v9_large OAE_1103l_071212 3.5 -
17543-18765 3.8 130503 grid_130503_3_8t_v9_large OAE_1103l_071212 3.8 -
>18765 4 90322 grid_1103l_071212_4t OAE_1103l_071212 4 -

Other options

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

Line: 216 to 215
 In version, 1103l_090322_2pi_scaled, the default scaling factors are implemented in 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):

Changed:
<
<
>
>
 

Regression Testing
Line: 225 to 224
 
CMS.MagneticField/Engine/test/regression.py

This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.

Deleted:
<
<
Visualization of the field map in CMSSW

The magnetic field can be visualized in the Iguana event display as follows:

cvs co VisDocumentation/VisTutorial
iguana -p VisDocumentation/VisTutorial/cmssw-geom.cfg -is "CMSSW"

Click on 'next event', wait, and put a check mark at 'Magnetic Field' in the left side bar. Remove the perspective view and select projection from the X axis.

 
Changed:
<
<
You'll see something like this:
>
>
Visualization of the field map in CMSSW
 
Changed:
<
<
field_y0_small.jpg
>
>
The magnetic field can be visualized in Eve.
 
Line: 248 to 238
 
Reviewer/Editor and Date (copy from screen) Comments
KatiLassilaPerini - 23 Jan 2007 created template page
NicolaAmapane - 01 Jul 2008 first edit
Deleted:
<
<
 
<!-- In the following line, be sure to put a blank space AFTER your name; otherwise the Summary doesn't come out right. -->
Changed:
<
<
Responsible: ResponsibleIndividual
>
>
Responsible: Nicola Amapane
 Last reviewed by: Never reviewed
Changed:
<
<
CMS.MagneticField/GeomBuilder

>
>
CMS.MagneticField/GeomBuilder

 

META FILEATTACHMENT attachment="EndcapScalingFactors.py.txt" attr="" comment="Scaling factors for endcap yoke volumes (example syntax)" date="1242310241" name="EndcapScalingFactors.py.txt" path="EndcapScalingFactors.py" size="430" stream="EndcapScalingFactors.py" user="Main.NicolaAmapane" version="1"

Revision 242013-05-12 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 148 to 148
 
Version 090812 (Intermediate development; deprecated)
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Has not been released into CMSSW.
Changed:
<
<
Version 120812 (Release candidate)
>
>
Version 120812
 Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<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_X, you need to update MagneticField:


Changed:
<
<
cvs co MagneticField
>
>
cvs co -r map120812_v1 MagneticField
 cd MagneticField/Interpolation/data ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_large . ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_small .

Revision 232013-05-12 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 123 to 123
 /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh
Changed:
<
<
Version 1103l_090601 (Development)
>
>
Version 1103l_090601 (Intermediate development; deprecated)
  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 platesextend 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.
Line: 145 to 145
 or, to also apply scaling factors from CRAFT data:
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")
Changed:
<
<
Version 090812 (Development)
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Never released into CMSSW.
>
>
Version 090812 (Intermediate development; deprecated)
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Has not been released into CMSSW.
 
Version 120812 (Release candidate)
Changed:
<
<
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Volume numbers are 1001-1360 and 2001-2360.Two version exist, with/without the additional YE4 plate.
>
>
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<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_X, you need to update MagneticField:

cvs co MagneticField
cd MagneticField/Interpolation/data
ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_large .
ln -s /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_120812_3_8t_v7_small .
cd -
scram b -j4

and specify in your configuration, for the setup with YE4:

process.load("MagneticField.Engine.volumeBasedMagneticField_120812_largeYE4_cfi")

and for the 2010/2012 geometry:

process.load("MagneticField.Engine.volumeBasedMagneticField_120812_cfi")
 

Other options

Revision 222013-03-30 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 14 to 14
 

Introduction and default configuration

Changed:
<
<
The magnetic field map is available in CMSSW from the EventSetup as an object of type MagneticField.
>
>
The magnetic field map is available in CMSSW from the EventSetup as an object of type CMS.MagneticField.
  An example of getting the magnetic field in CMSSW is available in
Changed:
<
<
MagneticField/Engine/test/queryField.cc
MagneticField/Engine/test/queryField.py
>
>
CMS.MagneticField/Engine/test/queryField.cc
CMS.MagneticField/Engine/test/queryField.py
  The required configuration file to get the default field map is:
process.load("Configuration.StandardSequences.MagneticField_38T_cff")

Line: 106 to 106
  Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.
Changed:
<
<
This version is used by default in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \MagneticField config fragment with:
>
>
This version is used by default in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \CMS.MagneticField config fragment with:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")

Due to an error in the release configuration, CMSSW_2_1_12 also requires setting (after setting up the cmssw environment, and assuming tcsh syntax):

Changed:
<
<
setenv CMSSW_SEARCH_PATH /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}
>
>
setenv CMSSW_SEARCH_PATH /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-CMS.MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}
  In older CMSSW_2_2_X releases, it is necessary to checkout and compile few packages:
cvs co -r V00-04-19 MagneticField/GeomBuilder

Line: 125 to 125
 
Version 1103l_090601 (Development)
Changed:
<
<
Same as 1103l_090322_2pi; with small correction of the TOSCA geometry in L3 of barrel sectors 9,10,11. No scaling factors applied.
>
>
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 platesextend 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.

  To use it:
cvs co -r V00-04-24 MagneticField/GeomBuilder
cvs co -r V00-04-25 MagneticField/Engine
cvs co -r V00-02-09 MagneticField/VolumeGeometry 
cvs co -r V00-03-08 MagneticField/Interpolation

Changed:
<
<
cvs co -r CMSSW_3_2_7 TrackPropagation/SteppingHelixPropagator
>
>
cvs co -r CMSSW_3_2_7 SteppingHelixPropagator
 cp -r /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_1103l_090601_3_8t MagneticField/Interpolation/data scramv1 b
Line: 143 to 145
 or, to also apply scaling factors from CRAFT data:
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")
Added:
>
>
Version 090812 (Development)
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Never released into CMSSW.

Version 120812 (Release candidate)
Full TOSCA model made of two halves ( _1 for X>0 and _2 for X<0). Volume numbers are 1001-1360 and 2001-2360.Two version exist, with/without the additional YE4 plate.
 

Other options

How to load two field maps in the same job
Line: 171 to 180
  In the code, you will then be able to get both fields maps:
Changed:
<
<
ESHandle<MagneticField> magfield;

>
>
ESHandle<CMS.MagneticField> magfield;

 setup.get<IdealMagneticFieldRecord>().get(magfield);
Changed:
<
<
ESHandle<MagneticField> newMagfield;
>
>
ESHandle<CMS.MagneticField> newMagfield;
 setup.get<IdealMagneticFieldRecord>().get("090216_3_8t",newMagfield);
Line: 185 to 194
 In version, 1103l_090322_2pi_scaled, the default scaling factors are implemented in 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):

Changed:
<
<
>
>
 

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 the head version of:

Changed:
<
<
MagneticField/Engine/test/regression.py
>
>
CMS.MagneticField/Engine/test/regression.py
  This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.
Visualization of the field map in CMSSW
Line: 206 to 215
  You'll see something like this:
Changed:
<
<
field_y0_small.jpg
>
>
field_y0_small.jpg
 
Line: 222 to 231
  Responsible: ResponsibleIndividual
Last reviewed by: Never reviewed
Changed:
<
<
MagneticField/GeomBuilder

>
>
CMS.MagneticField/GeomBuilder

 

META FILEATTACHMENT attachment="EndcapScalingFactors.py.txt" attr="" comment="Scaling factors for endcap yoke volumes (example syntax)" date="1242310241" name="EndcapScalingFactors.py.txt" path="EndcapScalingFactors.py" size="430" stream="EndcapScalingFactors.py" user="Main.NicolaAmapane" version="1"

Revision 212009-11-13 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 132 to 132
 cvs co -r V00-04-25 MagneticField/Engine cvs co -r V00-02-09 MagneticField/VolumeGeometry cvs co -r V00-03-08 MagneticField/Interpolation
Added:
>
>
cvs co -r CMSSW_3_2_7 TrackPropagation/SteppingHelixPropagator
 cp -r /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_1103l_090601_3_8t MagneticField/Interpolation/data
Added:
>
>
scramv1 b
 

and specify in your configuration:

Revision 202009-11-05 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 121 to 121
 scramv1 b cd MagneticField/Interpolation/data/grid_1103l_090322_3_8t /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh
Deleted:
<
<
 
Changed:
<
<
Version 1103l_090602 (Development)
>
>
Version 1103l_090601 (Development)
  Same as 1103l_090322_2pi; with small correction of the TOSCA geometry in L3 of barrel sectors 9,10,11. No scaling factors applied.
Line: 179 to 178
 
How to apply per-volume rescaling factors
Changed:
<
<
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.

Annotated examples of configuration fragments:
>
>
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.

In version, 1103l_090322_2pi_scaled, the default scaling factors are implemented in 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):

 
Regression Testing

Revision 192009-10-23 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 124 to 124
 

Changed:
<
<
Version 1103l_090602_2pi (Development)
>
>
Version 1103l_090602 (Development)
  Same as 1103l_090322_2pi; with small correction of the TOSCA geometry in L3 of barrel sectors 9,10,11. No scaling factors applied.

To use it:

cvs co -r  V00-04-24 MagneticField/GeomBuilder
cvs co -r V00-04-25 MagneticField/Engine

Changed:
<
<
mkdir -p MagneticField/Interpolation/data
>
>
cvs co -r V00-02-09 MagneticField/VolumeGeometry cvs co -r V00-03-08 MagneticField/Interpolation
 cp -r /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_1103l_090601_3_8t MagneticField/Interpolation/data

Revision 182009-10-22 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Line: 130 to 131
  To use it:
cvs co -r  V00-04-24 MagneticField/GeomBuilder

Changed:
<
<
cvs co -r V00-04-24 MagneticField/Engine
>
>
cvs co -r V00-04-25 MagneticField/Engine
 mkdir -p MagneticField/Interpolation/data cp -r /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_1103l_090601_3_8t MagneticField/Interpolation/data

and specify in your configuration:

process.load("MagneticField.Engine.volumeBasedMagneticField_090601_cfi")
Added:
>
>
or, to also apply scaling factors from CRAFT data:
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_scaled_cfi")
 

Other options

How to load two field maps in the same job

Revision 172009-10-21 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Added:
>
>
 Complete: 1

Line: 11 to 12
 
  • CMSSW interface: Nicola Amapane, Martijn Mulders
  • XML field geometry: Valeri Andreev
Changed:
<
<

Introduction and default configuration

>
>

Introduction and default configuration

 The magnetic field map is available in CMSSW from the EventSetup as an object of type MagneticField.

An example of getting the magnetic field in CMSSW is available in

MagneticField/Engine/test/queryField.cc
MagneticField/Engine/test/queryField.py
Changed:
<
<
The required configuration file to get the default field map is:
>
>
The required configuration file to get the default field map is:
 
process.load("Configuration.StandardSequences.MagneticField_38T_cff")

Changed:
<
<
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".
Zero-field map can also be specified replacing "38T" with "0T".
>
>

This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".
Zero-field map can also be specified replacing "38T" with "0T".

 
Changed:
<
<
This is everything needed for the average user. The following sections cover non-standard and advanced options that may be needed for specific studies.
>
>
This is everything needed for the average user. The following sections cover non-standard and advanced options that may be needed for specific studies.

Advanced usage

How the field map works

Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called 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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:

VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
 
Changed:
<
<

Advanced usage

How the field map works

>
>
With this setting, a field map with label = 'parametrizedField' is searched for in the <nop>EventSetup and used for the inner tracker region.
 
Changed:
<
<
Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called  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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
With this setting, a field map with label = 'parametrizedField' is searched for in the <nop>EventSetup and used for the inner tracker region.

Map versions

>
>

Map versions

 
Changed:
<
<
Different versions of the <nop>VolumeBasedMagneticField exist. Here is a brief description of the main one.
>
>
Different versions of the <nop>VolumeBasedMagneticField exist. Here is a brief description of the main one.
  A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Changed:
<
<
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)
>
>
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)
 The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).
Changed:
<
<
This has been the only full field map available after 2003 and before CMSSW_2_1_0.
>
>
This has been the only full field map available after 2003 and before CMSSW_2_1_0.
 
Changed:
<
<
To use this map you have to include in your cfg.py:
>
>
To use this map you have to include in your cfg.py:
 
process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
Changed:
<
<
This version is no longer supported after CMSSW_2_2_10.
>
>

This version is no longer supported after CMSSW_2_2_10.

 
Version 1103l_071212 (Pre-CRAFT default; deprecated since 3_1_X)
Deleted:
<
<
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>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).
 
Changed:
<
<
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). Physics analyses should use the 3.8T map.
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
>
>
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>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).
 
Changed:
<
<

A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:
>
>
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). Physics analyses should use the 3.8T map.
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
 
Changed:
<
<
process.ParametrizedMagneticFieldProducer.version = 'PolyFit2D'

>
>

A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:

process.ParametrizedMagneticFieldProducer.version = 'PolyFit2D'

 process.ParametrizedMagneticFieldProducer.parameters = cms.PSet( BValue = cms.double(3.81143) ) process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True;
Changed:
<
<
(the latter card is actually set to True by default in the standard config).
>
>
(the latter card is actually set to True by default in the standard config).
 
Changed:
<
<
In 3.1.X releases and later, where this map version is superseeded by 1103l_090322_2pi_scaled, it can be activated using:
>
>
In 3.1.X releases and later, where this map version is superseeded by 1103l_090322_2pi_scaled, it can be activated using:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").

Line: 64 to 76
 
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").

Added:
>
>
 
Version 1103l_090216 (Intermediate development; deprecated)
Changed:
<
<
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  deprecated in favor of later versions.

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
>
>
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 deprecated in favor of later versions.

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")

In previous CMSSW versions, the map can be used with the following recipe:

  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data 
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t  MagneticField/Interpolation/data 
 
  1. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Version 1103l_090322 (deprecated)
Changed:
<
<
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.
This version was used for development only, and is  deprecated in favor of later versions.

This version will is available since recent 2_2_X versions with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
In older CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t    MagneticField/Interpolation/data 
>
>
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.
This version was used for development only, and is deprecated in favor of later versions.

This version will is available since recent 2_2_X versions with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")

In older CMSSW versions, the map can be used with the following recipe:

  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data 
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t  MagneticField/Interpolation/data 
 
  1. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
Changed:
<
<
Version 1103l_090322_2pi (deprecated)
>
>
Version 1103l_090322_2pi (deprecated)
 
Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
To use it (in CMSSW_3_10 or  2_2_13, or later) , use:
>
>
To use it (in CMSSW_3_10 or 2_2_13, or later) , use:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")
Changed:
<
<

Version 1103l_090322_2pi_scaled (Default starting from 3_1_0)
>
>
Version 1103l_090322_2pi_scaled (Default starting from 3_1_0)
 
Changed:
<
<
Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.
>
>
Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.
 
Changed:
<
<
This version is used by default  in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \MagneticField config fragment with:
>
>
This version is used by default in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \MagneticField config fragment with:
 
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")

Changed:
<
<
Due to an error in the  release configuration,  CMSSW_2_1_12 also requires setting (after setting up the cmssw environment, and assuming tcsh syntax):
setenv CMSSW_SEARCH_PATH  /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}
>
>
 
Changed:
<
<
In older CMSSW_2_2_X releases, it is necessary to checkout and compile few packages:
>
>
Due to an error in the release configuration, CMSSW_2_1_12 also requires setting (after setting up the cmssw environment, and assuming tcsh syntax):
setenv CMSSW_SEARCH_PATH /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}

In older CMSSW_2_2_X releases, it is necessary to checkout and compile few packages:

 
cvs co -r V00-04-19 MagneticField/GeomBuilder
cvs co -r V00-03-07 MagneticField/Interpolation
cvs co -r V00-04-20 MagneticField/Engine

Line: 98 to 121
 scramv1 b cd MagneticField/Interpolation/data/grid_1103l_090322_3_8t /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh
Added:
>
>

Version 1103l_090602_2pi (Development)

Same as 1103l_090322_2pi; with small correction of the TOSCA geometry in L3 of barrel sectors 9,10,11. No scaling factors applied.

To use it:

cvs co -r  V00-04-24 MagneticField/GeomBuilder
cvs co -r V00-04-24 MagneticField/Engine
mkdir -p MagneticField/Interpolation/data
cp -r /afs/cern.ch/cms/OO/mag_field/CMSSW/grid_1103l_090601_3_8t MagneticField/Interpolation/data 

 
Deleted:
<
<

Other options

 
Changed:
<
<
How to load two field maps in the same job
>
>
and specify in your configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_090601_cfi")

Other options

How to load two field maps in the same job
 
Changed:
<
<
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).
>
>
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).
 
# The standard one
process.load("Configuration.StandardSequences.MagneticField_38T_cff")

Line: 113 to 151
 # Note I use a different process name than what us used in the default. process.VolumeBasedMagneticFieldESProducerNew = cms.ESProducer("VolumeBasedMagneticFieldESProducer",
Changed:
<
<
    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()
>
>
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()
 )

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

>
>
In the code, you will then be able to get both fields maps:
 
ESHandle<MagneticField> magfield;
setup.get<IdealMagneticFieldRecord>().get(magfield);

Line: 134 to 172
 setup.get<IdealMagneticFieldRecord>().get("090216_3_8t",newMagfield);
Changed:
<
<
How to apply per-volume rescaling factors
>
>
How to apply per-volume rescaling factors
 
Changed:
<
<
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.

Annotated examples of configuration fragments:

>
>
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.

Annotated examples of configuration fragments:
 
Changed:
<
<

>
>
 
Regression Testing
Changed:
<
<
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 the head version of:
MagneticField/Engine/test/regression.py
This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.
Visualization of the field map in CMSSW
>
>
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 the head version of:
MagneticField/Engine/test/regression.py

This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.

Visualization of the field map in CMSSW
  The magnetic field can be visualized in the Iguana event display as follows:
cvs co VisDocumentation/VisTutorial

Line: 150 to 192
 
Changed:
<
<
Click on 'next event', wait, and put a check mark at 'Magnetic Field' in the left side bar. Remove the perspective view and select projection from the X axis.

You'll see something like this: 

>
>
Click on 'next event', wait, and put a check mark at 'Magnetic Field' in the left side bar. Remove the perspective view and select projection from the X axis.
 
Changed:
<
<
field_y0_small.jpg
>
>
You'll see something like this:
 
Changed:
<
<

>
>
field_y0_small.jpg
 
Changed:
<
<

>
>
 
Deleted:
<
<

 

Review status

<!-- Add your review status in this table structure with 2 columns delineated by three vertical bars -->
Line: 172 to 211
 
<!-- In the following line, be sure to put a blank space AFTER your name; otherwise the Summary doesn't come out right. -->

Responsible: ResponsibleIndividual

Changed:
<
<
Last reviewed by: Never reviewed
>
>
Last reviewed by: Never reviewed
MagneticField/GeomBuilder
 
META FILEATTACHMENT attachment="EndcapScalingFactors.py.txt" attr="" comment="Scaling factors for endcap yoke volumes (example syntax)" date="1242310241" name="EndcapScalingFactors.py.txt" path="EndcapScalingFactors.py" size="430" stream="EndcapScalingFactors.py" user="Main.NicolaAmapane" version="1"

Revision 162009-08-15 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Complete: 1
Line: 141 to 141
 
Regression Testing
Changed:
<
<
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 the head version of:
MagneticField/Engine/test/regression.py
This file loads the default map version and points to the corresponding reference file (on AFS).
 
>
>
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 the head version of:
MagneticField/Engine/test/regression.py
This file loads the default map version and points to the corresponding reference file (on AFS).

Failures are reported in the standard output.
 
Visualization of the field map in CMSSW

The magnetic field can be visualized in the Iguana event display as follows:

Revision 152009-08-15 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide"

Magnetic Field Interface

Complete: 1
Line: 33 to 33
  Different versions of the <nop>VolumeBasedMagneticField exist. Here is a brief description of the main one.
Changed:
<
<
A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Version 1103l_071212 (Pre-CRAFT default)
>
>
A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Version 85l_030919 ("old 4T map"; obsolete, no longer supported)
The 4T field map used in 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<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<1.2 m, |z|<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.

To use this map you have to include in your cfg.py:

process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
This version is no longer supported after CMSSW_2_2_10.

Version 1103l_071212 (Pre-CRAFT default; deprecated since 3_1_X)
 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>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).
Changed:
<
<
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). Physics analyses should use the 3.8T map.
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
>
>
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). Physics analyses should use the 3.8T map.
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
 
A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:
Line: 55 to 64
 
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").

Changed:
<
<
Version 1103l_090216 (Intermediate development)
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 is however deprecated in favor of version 1103l_090322 and later (see below).

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
>
>
Version 1103l_090216 (Intermediate development; deprecated)
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  deprecated in favor of later versions.

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Changed:
<
<
Version 1103l_090322
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 baiscally only in the forward region.

This version will become available in a future releases with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
In current CMSSW versions, the map can be used with the following recipe:
>
>
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.
This version was used for development only, and is  deprecated in favor of later versions.

This version will is available since recent 2_2_X versions with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
In older CMSSW versions, the map can be used with the following recipe:
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
Changed:
<
<
Version 1103l_090322_2pi
>
>
Version 1103l_090322_2pi (deprecated)
 
Changed:
<
<
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. To use it (in CMSSW_3_10 or  2_2_13, or later) , use:
>
>
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.

To use it (in CMSSW_3_10 or  2_2_13, or later) , use:

 
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")


Line: 87 to 98
 scramv1 b cd MagneticField/Interpolation/data/grid_1103l_090322_3_8t /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh
Changed:
<
<

Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<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.

To use this map you have to include in your cfg.py:

process.load("Configuration.StandardSequences.MagneticField_40T_851cff")

This version is no longer supported after CMSSW_2_2_10.

>
>
 

Other options

How to load two field maps in the same job
Line: 139 to 139
 A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.

Annotated examples of configuration fragments:

Added:
>
>

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 the head version of:
MagneticField/Engine/test/regression.py
This file loads the default map version and points to the corresponding reference file (on AFS).
 
 
Visualization of the field map in CMSSW

The magnetic field can be visualized in the Iguana event display as follows:

Revision 142009-07-29 - KatiLassilaPerini

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="SWGuide01MainAreas"
>
>
META TOPICPARENT name="SWGuide"
 

Magnetic Field Interface

Complete: 1

Revision 132009-07-17 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 35 to 35
  A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Version 1103l_071212 (Pre-CRAFT default)
Changed:
<
<
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>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).
>
>
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>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).
 
Changed:
<
<
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). Physics analyses should use the 3.8T map.
>
>
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). Physics analyses should use the 3.8T map.
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.
 
Changed:
<
<
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.

A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:
>
>

A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:
 
process.ParametrizedMagneticFieldProducer.version = 'PolyFit2D'
process.ParametrizedMagneticFieldProducer.parameters = cms.PSet(

Line: 48 to 49
 process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True;
Changed:
<
<
(the latter card is actually set to True by default in the standard config).
>
>
(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:

process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_cfi").

 
Version 1103l_090216 (Intermediate development)
Changed:
<
<
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 is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
>
>
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 is however deprecated in favor of version 1103l_090322 and later (see below).

This version is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Line: 69 to 75
  Same as 1103l_090322_2pi; in addition the field is scaled with factors measured from CRAFT data.
Changed:
<
<
This version is used by default  in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")

>
>
This version is used by default  in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")

 Due to an error in the  release configuration,  CMSSW_2_1_12 also requires setting (after setting up the cmssw environment, and assuming tcsh syntax):
setenv CMSSW_SEARCH_PATH  /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}

In older CMSSW_2_2_X releases, it is necessary to checkout and compile few packages:

Revision 122009-07-16 - MartijnMulders

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 34 to 34
 Different versions of the <nop>VolumeBasedMagneticField exist. Here is a brief description of the main one.

A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .

Changed:
<
<
Version 1103l_071212 (Current default)
>
>
Version 1103l_071212 (Pre-CRAFT default)
 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>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). Physics analyses should use the 3.8T map.

Revision 112009-06-16 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 59 to 59
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
Added:
>
>
Version 1103l_090322_2pi

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. To use it (in CMSSW_3_10 or  2_2_13, or later) , use:

process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")


 
Version 1103l_090322_2pi_scaled (Default starting from 3_1_0)
Changed:
<
<
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.

Instructions for beta testers:
cvs co -r V00-04-19 MagneticField/GeomBuilder

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

This version is used by default  in CMSSW_3_1_0 and later releases.
In CMSSW_2_2_12 and CMSSW_2_2_13 it can be optionally used replacing whatever other \MagneticField config fragment with:

process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")
Due to an error in the  release configuration,  CMSSW_2_1_12 also requires setting (after setting up the cmssw environment, and assuming tcsh syntax):
setenv CMSSW_SEARCH_PATH  /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/data-MagneticField-Interpolation/25:${CMSSW_SEARCH_PATH}

In older CMSSW_2_2_X releases, it is necessary to checkout and compile few packages:

cvs co -r V00-04-19 MagneticField/GeomBuilder

 cvs co -r V00-03-07 MagneticField/Interpolation cvs co -r V00-04-20 MagneticField/Engine cvs co -r V00-02-07 MagneticField/VolumeGeometry scramv1 b cd MagneticField/Interpolation/data/grid_1103l_090322_3_8t /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh
Changed:
<
<
In your cfg.py,  replace whatever other \MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")

>
>

 
Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).

Revision 102009-05-26 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 54 to 54
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Changed:
<
<
Version 1103l_090322 (Proposed new default)
>
>
Version 1103l_090322
 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 baiscally only in the forward region.

This version will become available in a future releases with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
In current CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
Changed:
<
<

Version 1103l_090322_2pi (Development)
Based on 1103l_090322, uses different tables for the barrel yoke iron layers in the chimney sectors (S3, S4)  and in the third layer of S9, S10, S11 and for the endcaps.

Instructions for beta testers:
cvs co -r V00-04-18 MagneticField/Engine
cvs co -r V00-04-17 MagneticField/GeomBuilder

>
>
Version 1103l_090322_2pi_scaled (Default starting from 3_1_0)
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.

Instructions for beta testers:
cvs co -r V00-04-19 MagneticField/GeomBuilder
cvs co -r V00-03-07 MagneticField/Interpolation
cvs co -r V00-04-20 MagneticField/Engine

 cvs co -r V00-02-07 MagneticField/VolumeGeometry scramv1 b
Changed:
<
<
mkdir -p Interpolation/data ln -s /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t Interpolation/data/ In your cfg.py,  replace whatever other MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")
>
>
cd MagneticField/Interpolation/data/grid_1103l_090322_3_8t /afs/cern.ch/cms/OO/mag_field/CMSSW/get.csh In your cfg.py,  replace whatever other \MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_scaled_cfi")

 
Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).

Revision 92009-05-15 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 61 to 61
 
  1. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'

Version 1103l_090322_2pi (Development)
Changed:
<
<
Based on 1103l_090322, uses different tables for the barrel yoke iron layers in the chimney sectors (S3, S4).
Work is ongoing to add other special sectors (notably the feet ones).

Instructions for beta testers:
cvs co -r V00-04-18 MagneticField/Engine
cvs co -r V00-04-16 MagneticField/GeomBuilder

>
>
Based on 1103l_090322, uses different tables for the barrel yoke iron layers in the chimney sectors (S3, S4)  and in the third layer of S9, S10, S11 and for the endcaps.

Instructions for beta testers:
cvs co -r V00-04-18 MagneticField/Engine
cvs co -r V00-04-17 MagneticField/GeomBuilder

 cvs co -r V00-02-07 MagneticField/VolumeGeometry scramv1 b mkdir -p Interpolation/data ln -s /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t Interpolation/data/
Changed:
<
<
In your cfg.py,  replace whatever other MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")

>
>
In your cfg.py,  replace whatever other MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")
 
Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).

Revision 82009-05-14 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 116 to 116
 
How to apply per-volume rescaling factors
Changed:
<
<
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

An example of the syntax is available in MagnetScalingFactors.py. The scaling is provided with two matching vectors, one with the volumes (encoded as 100*volume number + sector,  with sector=0 meaning all sectors) and one with the corresponding factors. The vectors in the example are annotated, so that the
various elements can be identified easily.
To specify each sector independently, one will have to add a line for a given volume replacing "00" with the sector number.
Note that the factor specified for a specific sector overrides the factor specified with "00", which is therefore the value used for all sectors of a given volue except those for which a specific value has been set separately.

This feature is available since CMSSW_2_2_4.


>
>
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

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.
The second vector specifies the corresponding scaling factors.

The volume numbers for the iron yoke plates can be obtained from this schema.

Annotated examples of configuration fragments:

 
Visualization of the field map in CMSSW

The magnetic field can be visualized in the Iguana event display as follows:

Line: 154 to 150
  Responsible: ResponsibleIndividual
Last reviewed by: Never reviewed
Deleted:
<
<

 \ No newline at end of file
Added:
>
>
META FILEATTACHMENT attachment="EndcapScalingFactors.py.txt" attr="" comment="Scaling factors for endcap yoke volumes (example syntax)" date="1242310241" name="EndcapScalingFactors.py.txt" path="EndcapScalingFactors.py" size="430" stream="EndcapScalingFactors.py" user="Main.NicolaAmapane" version="1"

Revision 72009-05-13 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 54 to 54
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Changed:
<
<
Version 1103l_090322 (Development)
>
>
Version 1103l_090322 (Proposed new default)
 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 baiscally only in the forward region.

This version will become available in a future releases with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
In current CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
Added:
>
>

Version 1103l_090322_2pi (Development)
Based on 1103l_090322, uses different tables for the barrel yoke iron layers in the chimney sectors (S3, S4).
Work is ongoing to add other special sectors (notably the feet ones).

Instructions for beta testers:
cvs co -r V00-04-18 MagneticField/Engine
cvs co -r V00-04-16 MagneticField/GeomBuilder
cvs co -r V00-02-07 MagneticField/VolumeGeometry
scramv1 b
mkdir -p Interpolation/data
ln -s /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t Interpolation/data/
In your cfg.py,  replace whatever other MagneticField config fragment with:
process.load("MagneticField.Engine.volumeBasedMagneticField_090322_2pi_cfi")

 
Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).
Line: 69 to 78
 process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
Added:
>
>
This version is no longer supported after CMSSW_2_2_10.
 

Other options

How to load two field maps in the same job
Line: 125 to 135
  You'll see something like this: 
Changed:
<
<
field_y0_small.jpg
>
>
field_y0_small.jpg
 
Line: 143 to 153
 
<!-- In the following line, be sure to put a blank space AFTER your name; otherwise the Summary doesn't come out right. -->

Responsible: ResponsibleIndividual

Changed:
<
<
Last reviewed by: Never reviewed
>
>
Last reviewed by: Never reviewed

 \ No newline at end of file

Revision 62009-04-23 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 113 to 113
 This feature is available since CMSSW_2_2_4.


Added:
>
>
Visualization of the field map in CMSSW
 
Changed:
<
<
>
>
The magnetic field can be visualized in the Iguana event display as follows:
cvs co VisDocumentation/VisTutorial
iguana -p VisDocumentation/VisTutorial/cmssw-geom.cfg -is "CMSSW"

Click on 'next event', wait, and put a check mark at 'Magnetic Field' in the left side bar. Remove the perspective view and select projection from the X axis.

You'll see something like this: 

field_y0_small.jpg




 

Review status

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

Revision 52009-04-01 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 28 to 28
 

How the field map works

Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called  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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:

Changed:
<
<
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
With this setting, a field map with label = 'parametrizedField' is searched for in the EventSetup and used for the inner tracker region.
>
>
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
With this setting, a field map with label = 'parametrizedField' is searched for in the <nop>EventSetup and used for the inner tracker region.
 

Map versions

Changed:
<
<
Different versions of the VolumeBasedMagneticField exist. Here is a brief description of the main one.
>
>
Different versions of the <nop>VolumeBasedMagneticField exist. Here is a brief description of the main one.
  A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Version 1103l_071212 (Current default)
Line: 49 to 49
 

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

Changed:
<
<
Version 1103l_090216 (Development)
Improved computation w.r.t. 1103l_071212, featuring based on larger volume for the field return and 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 is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
>
>
Version 1103l_090216 (Intermediate development)
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 is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
 
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Added:
>
>
Version 1103l_090322 (Development)
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 baiscally only in the forward region.

This version will become available in a future releases with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090322_cfi")
In current CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090322_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090322_3_8t'
 
Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (and it also provides smoother derivatives than the interpolation).

Revision 42009-03-25 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 11 to 11
 
  • CMSSW interface: Nicola Amapane, Martijn Mulders
  • XML field geometry: Valeri Andreev
Changed:
<
<

Introduction

>
>

Introduction and default configuration

 The magnetic field map is available in CMSSW from the EventSetup as an object of type MagneticField.
Changed:
<
<
Different concrete field engines are available to deliver different maps. In particular
  • VolumeBasedMagneticField: full map over the entire CMS detector, based on finite-element computations. This is the map used in normal simulation and reconstruction applications.
  • UniformMagneticField: Simple uniform field (Bz=const)
  • Parametrized fields: several engines provide different parametrizations of the field in the tracker region. They can be used alone for applications that need the field in the tracker region only, or as a slave for the full field map.

Accessing the field in an application

An example of getting the magnetic field in CMSSW is available in
MagneticField/Engine/test/queryField.cc
>
>
An example of getting the magnetic field in CMSSW is available in
MagneticField/Engine/test/queryField.cc
MagneticField/Engine/test/queryField.py

The required configuration file to get the default field map is:

process.load("Configuration.StandardSequences.MagneticField_38T_cff")
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".
Zero-field map can also be specified replacing "38T" with "0T".

This is everything needed for the average user. The following sections cover non-standard and advanced options that may be needed for specific studies.

Advanced usage

How the field map works

 
Changed:
<
<

Essential information on the full CMS map (VolumeBasedMagneticField)

>
>
Concrete implementations ("engines") of a MagneticField are available to deliver different maps in either the whole CMS or in specific parts of it. The default map is called  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.
Providers can however also be based on e.g. parametrizations.
A special region is the inner tracker region. Here, 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. This behaviour is specified by the card:
VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True
With this setting, a field map with label = 'parametrizedField' is searched for in the EventSetup and used for the inner tracker region.

Map versions

 
Changed:
<
<
A collection of field-related documents can be found here .
>
>
Different versions of the VolumeBasedMagneticField exist. Here is a brief description of the main one.
 
Changed:
<
<
Documentation for the available map versions is present in the following sections:
>
>
A collection of documents related to the field map computation, mapping, and comparison with measured data can be found here .
Version 1103l_071212 (Current default)
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>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).
 
Changed:
<
<

Version 85l_030919 ("old 4T map"; obsolete)

The 4T field map used in 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<0 only (1/24 of CMS), thus the model is Z-symmetric and 12-fold phi-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). Physics analyses should use the 3.8T map.
 
Changed:
<
<
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.
>
>
A parametrization of the TOSCA computation within r<1.15 m, |z|<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.

A different parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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:
 
Changed:
<
<
The nominal B value in this map (4T) cannot be changed.
>
>
process.ParametrizedMagneticFieldProducer.version = 'PolyFit2D'
process.ParametrizedMagneticFieldProducer.parameters = cms.PSet(
         BValue = cms.double(3.81143)
)
process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = True;
 
Changed:
<
<
A parametrization of the TOSCA computation (by V. Karimaki) can be optionally used in the region r<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (although it also provides smoother derivatives than the interpolation).
>
>
(the latter card is actually set to True by default in the standard config).
Version 1103l_090216 (Development)
Improved computation w.r.t. 1103l_071212, featuring based on larger volume for the field return and 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 is available since 2_2_7 with the configuration:
process.load("MagneticField.Engine.volumeBasedMagneticField_1103l_090216_cfi")
In previous CMSSW versions, the map can be used with the following recipe:
  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
Version 85l_030919 ("old 4T map"; obsolete)
The 4T field map used in 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<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<1.2 m, |z|<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.

To use this map you have to include in your cfg.py:

Changed:
<
<
Configuration/StandardSequences/python/MagneticField_40T_851_cff.py
>
>
process.load("Configuration.StandardSequences.MagneticField_40T_851cff")
 
Changed:
<
<

Version 1103l_071212 (Current default)

The TOSCA model was improved after 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).
>
>

Other options

 
Changed:
<
<
The model used in the computation includes the Z-asymmetry of the coil spires and more accurate description of a full half (x>0) of CMS. However field data is still provided only for one 30 degree sector (312 volumes representing 1/12 of CMS), so the new CMSSW map is still 12-fold phi-symmetric (but no more Z-symmetric).
>
>
How to load two field maps in the same job
 
Changed:
<
<
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 "old" 4T value. The default for CMSSW 2.1.0 will be the 3.8T field map.
>
>
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).
# The standard one
process.load("Configuration.StandardSequences.MagneticField_38T_cff")

 
Deleted:
<
<
A parametrization of the TOSCA computation within r<1.15 m, |z|<2.8 m is available for all field values (V. Karimaki) and, differently than in the past, this parametrization is switched on by default, mainly to save CPU time in production and HLT.
 
Deleted:
<
<
Additionally, a parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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.
 
Changed:
<
<
The default TOSCA parametrization differs by few mT (up to ~5mT at the edges of the validity region). However, it matches very well the full interpolated map; while the more precise data parametrization results in a discontinuity of the field of few mT at the edge of the parametrization validity region.
>
>
# 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() )
 
Changed:
<
<
To use this map you have to include in your cfg.py:
Configuration/StandardSequences/python/MagneticField_38T_cff.py
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".
>
>
 
Changed:
<
<

Version 1103l_090216 (Development)

To use this development version, use the following recipe in CMSSW_2_1_0 or later:

  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
    process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = False
>
>
In the code, you will then be able to get both fields maps:

ESHandle<MagneticField> magfield;
setup.get<IdealMagneticFieldRecord>().get(magfield);

ESHandle<MagneticField> newMagfield;
setup.get<IdealMagneticFieldRecord>().get("090216_3_8t",newMagfield);

How to apply per-volume rescaling factors
 
Changed:
<
<


>
>
A scaling factor for |B| can be specified independently for each of the 312 volumes in each sector.

An example of the syntax is available in MagnetScalingFactors.py. The scaling is provided with two matching vectors, one with the volumes (encoded as 100*volume number + sector,  with sector=0 meaning all sectors) and one with the corresponding factors. The vectors in the example are annotated, so that the
various elements can be identified easily.
To specify each sector independently, one will have to add a line for a given volume replacing "00" with the sector number.
Note that the factor specified for a specific sector overrides the factor specified with "00", which is therefore the value used for all sectors of a given volue except those for which a specific value has been set separately.

This feature is available since CMSSW_2_2_4.


 

Review status

Revision 32009-03-10 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 18 to 18
 
  • VolumeBasedMagneticField: full map over the entire CMS detector, based on finite-element computations. This is the map used in normal simulation and reconstruction applications.
  • UniformMagneticField: Simple uniform field (Bz=const)
  • Parametrized fields: several engines provide different parametrizations of the field in the tracker region. They can be used alone for applications that need the field in the tracker region only, or as a slave for the full field map.
Added:
>
>

Accessing the field in an application

An example of getting the magnetic field in CMSSW is available in
MagneticField/Engine/test/queryField.cc
 

Essential information on the full CMS map (VolumeBasedMagneticField)

Changed:
<
<

Versions

Version 85l_030919 ("old 4T map")

>
>
A collection of field-related documents can be found here .

Documentation for the available map versions is present in the following sections:

Version 85l_030919 ("old 4T map"; obsolete)

 The 4T field map used in 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<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.

Line: 30 to 37
  A parametrization of the TOSCA computation (by V. Karimaki) can be optionally used in the region r<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (although it also provides smoother derivatives than the interpolation).
Changed:
<
<
This has been the only full field map available after 2003 and before CMSSW_2_1_0.
>
>
This has been the only full field map available after 2003 and before CMSSW_2_1_0.

To use this map you have to include in your cfg.py:

Configuration/StandardSequences/python/MagneticField_40T_851_cff.py
 
Changed:
<
<

Version 1103l_071212 ("new maps")

>
>

Version 1103l_071212 (Current default)

 The TOSCA model was improved after 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).

The model used in the computation includes the Z-asymmetry of the coil spires and more accurate description of a full half (x>0) of CMS. However field data is still provided only for one 30 degree sector (312 volumes representing 1/12 of CMS), so the new CMSSW map is still 12-fold phi-symmetric (but no more Z-symmetric).

Line: 43 to 54
  Additionally, a parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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.
Changed:
<
<
The default TOSCA parametrization differs by few mT (up to ~5mT at the edges of the validity region). However, it matches very well the full interpolated map; while the more precise data parametrization results in a discontinuity of the field of few mT at the edge of the parametrization validity region.
>
>
The default TOSCA parametrization differs by few mT (up to ~5mT at the edges of the validity region). However, it matches very well the full interpolated map; while the more precise data parametrization results in a discontinuity of the field of few mT at the edge of the parametrization validity region.
 
Changed:
<
<

Documentation

A collection of field-related documents can be found here

An example of getting the magnetic field in CMSSW is available in

MagneticField/Engine/test/queryField.cc

The configuration fragments to get the field maps in the 21X series are:

  • New map
    Configuration/StandardSequences/python/MagneticField_38T_cff.py

    This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".

  • Old map, 4T only:
    Configuration/StandardSequences/python/MagneticField_40T_851_cff.py
>
>
To use this map you have to include in your cfg.py:
Configuration/StandardSequences/python/MagneticField_38T_cff.py
This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".
 

Version 1103l_090216 (Development)

To use this development version, use the following recipe in CMSSW_2_1_0 or later:

Line: 65 to 65
 
  1.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  2. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
    process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = False
Changed:
<
<



>
>


 

Review status

Revision 22009-03-02 - NicolaAmapane

Line: 1 to 1
 
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1
Line: 22 to 22
 

Essential information on the full CMS map (VolumeBasedMagneticField)

Versions

Version 85l_030919 ("old 4T map")

Changed:
<
<
The 4T field map used in 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<0 only (1/24 of CMS), thus the model is Z-symmetric and 12-fold phi-symmetric.
>
>
The 4T field map used in 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<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.

Changed:
<
<
A parametrization of the TOSCA computation (by V. Karimaki) can be optionally used in the region r<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (although it also provides smoother derivatives than the interpolation).
>
>
A parametrization of the TOSCA computation (by V. Karimaki) can be optionally used in the region r<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (although 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.

Version 1103l_071212 ("new maps")

The TOSCA model was improved after 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).
Changed:
<
<
The model used in the computation includes the Z-asymmetry of the coil spires and more accurate description of a full half (x>0) of CMS. However field data is still provided only for one 30 degree sector (312 volumes representing 1/12 of CMS), so the new CMSSW map is still 12-fold phi-symmetric (but no more Z-symmetric).
>
>
The model used in the computation includes the Z-asymmetry of the coil spires and more accurate description of a full half (x>0) of CMS. However field data is still provided only for one 30 degree sector (312 volumes representing 1/12 of CMS), so the new CMSSW map is still 12-fold phi-symmetric (but no more 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 "old" 4T value. The default for CMSSW 2.1.0 will be the 3.8T field map.
Changed:
<
<
A parametrization of the TOSCA computation within r<1.15 m, |z|<2.8 m is available for all field values (V. Karimaki) and, differently than in the past, this parametrization is switched on by default, mainly to save CPU time in production and HLT.
>
>
A parametrization of the TOSCA computation within r<1.15 m, |z|<2.8 m is available for all field values (V. Karimaki) and, differently than in the past, this parametrization is switched on by default, mainly to save CPU time in production and HLT.
 
Changed:
<
<
Additionally, a parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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.
>
>
Additionally, a parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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.
  The default TOSCA parametrization differs by few mT (up to ~5mT at the edges of the validity region). However, it matches very well the full interpolated map; while the more precise data parametrization results in a discontinuity of the field of few mT at the edge of the parametrization validity region.
Deleted:
<
<
Validation of simulation and reconstruction with new maps
The effect of switching to 3.8T should be checked on simulation and reconstruction. Particular care has to be taken with parametrizations that will have to be updated.

Special samples for this validation were produced in 210_pre6 and are available here (note: those listed as 4.0T samples are produced with the old 4T interface).

 

Documentation

A collection of field-related documents can be found here
Line: 63 to 54
 

The configuration fragments to get the field maps in the 21X series are:

Changed:
<
<
  • New map, 3.8T:
Configuration/StandardSequences/python/MagneticField_38T_cff.py
>
>
  • New map
    Configuration/StandardSequences/python/MagneticField_38T_cff.py

    This sets the 3.8 T default map. To use the maps at other nominal B values replace "38T" with one of the following: "20T", "30T", "35T", "40T".

 
Changed:
<
<
  • New map, 4T:
    Configuration/StandardSequences/python/MagneticField_40T_cff.py
    

  • Old map, 4T:
    Configuration/StandardSequences/python/MagneticField_40T_851_cff.py
    

  • Default map:
    Configuration/StandardSequences/python/MagneticField_cff.py
    
currently, this points to the old 4T map (this will change in the 210 release).
>
>
  • Old map, 4T only:
    Configuration/StandardSequences/python/MagneticField_40T_851_cff.py
 
Added:
>
>

Version 1103l_090216 (Development)

To use this development version, use the following recipe in CMSSW_2_1_0 or later:

  1.  cd CMSSW_X_Y_Z/src; mkdir -p MagneticField/Interpolation/data  
  2.  cp -r /afs/cern.ch/cms/OO/mag_field/grid_1103l_090216_3_8t    MagneticField/Interpolation/data 
  3. Set in your .py:
    process.load("Configuration.StandardSequences.MagneticField_38T_cff")
    process.VolumeBasedMagneticFieldESProducer.version = 'grid_1103l_090216_3_8t'
    process.VolumeBasedMagneticFieldESProducer.useParametrizedTrackerField = False
 
Added:
>
>



 

Review status

Line: 94 to 78
 
<!-- In the following line, be sure to put a blank space AFTER your name; otherwise the Summary doesn't come out right. -->
Changed:
<
<
Responsible: ResponsibleIndividual
>
>
Responsible: ResponsibleIndividual
 Last reviewed by: Never reviewed

Revision 12008-07-01 - NicolaAmapane

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SWGuide01MainAreas"

Magnetic Field Interface

Complete: 1

Contacts

  • B Field Task coordinator: Dietrich Liko
  • TOSCA computation: Vyacheslav Klyukhin
  • CMSSW interface: Nicola Amapane, Martijn Mulders
  • XML field geometry: Valeri Andreev

Introduction

The magnetic field map is available in CMSSW from the EventSetup as an object of type MagneticField.

Different concrete field engines are available to deliver different maps. In particular

  • VolumeBasedMagneticField: full map over the entire CMS detector, based on finite-element computations. This is the map used in normal simulation and reconstruction applications.
  • UniformMagneticField: Simple uniform field (Bz=const)
  • Parametrized fields: several engines provide different parametrizations of the field in the tracker region. They can be used alone for applications that need the field in the tracker region only, or as a slave for the full field map.

Essential information on the full CMS map (VolumeBasedMagneticField)

Versions

Version 85l_030919 ("old 4T map")

The 4T field map used in 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<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<1.2 m, |z|<3.0 m in place of the interpolation; the main advantage is speed (although 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.

Version 1103l_071212 ("new maps")

The TOSCA model was improved after 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).

The model used in the computation includes the Z-asymmetry of the coil spires and more accurate description of a full half (x>0) of CMS. However field data is still provided only for one 30 degree sector (312 volumes representing 1/12 of CMS), so the new CMSSW map is still 12-fold phi-symmetric (but no more 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 "old" 4T value. The default for CMSSW 2.1.0 will be the 3.8T field map.

A parametrization of the TOSCA computation within r<1.15 m, |z|<2.8 m is available for all field values (V. Karimaki) and, differently than in the past, this parametrization is switched on by default, mainly to save CPU time in production and HLT.

Additionally, a parametrization of the real mapping data (V. Maroussov) is available as an option. It is defined in the region r<1.9 m, |z|<3.5m, excluding the "corners" |z|+2.5*r>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.

The default TOSCA parametrization differs by few mT (up to ~5mT at the edges of the validity region). However, it matches very well the full interpolated map; while the more precise data parametrization results in a discontinuity of the field of few mT at the edge of the parametrization validity region.

Validation of simulation and reconstruction with new maps
The effect of switching to 3.8T should be checked on simulation and reconstruction. Particular care has to be taken with parametrizations that will have to be updated.

Special samples for this validation were produced in 210_pre6 and are available here (note: those listed as 4.0T samples are produced with the old 4T interface).

Documentation

A collection of field-related documents can be found here

An example of getting the magnetic field in CMSSW is available in

MagneticField/Engine/test/queryField.cc

The configuration fragments to get the field maps in the 21X series are:

  • New map, 3.8T:
Configuration/StandardSequences/python/MagneticField_38T_cff.py

  • New map, 4T:
    Configuration/StandardSequences/python/MagneticField_40T_cff.py
    

  • Old map, 4T:
    Configuration/StandardSequences/python/MagneticField_40T_851_cff.py
    

  • Default map:
    Configuration/StandardSequences/python/MagneticField_cff.py
    
currently, this points to the old 4T map (this will change in the 210 release).

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
KatiLassilaPerini - 23 Jan 2007 created template page
NicolaAmapane - 01 Jul 2008 first edit

<!-- In the following line, be sure to put a blank space AFTER your name; otherwise the Summary doesn't come out right. -->

Responsible: ResponsibleIndividual
Last reviewed by: Never reviewed

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback