Update the magnetic field model for data

[davidwalter2]

• Updates on the test scripts to query the b field at points of the NMR probes
• Adding all magnetic field map configuration files:
  • 090322 (Run 1)
  • 120812 (Run 1, Run 2),
  • 130503 (Run 1, Run 2),
  • 160812 (Run 1, Run 2),
  • 170812 (Surface for tracker and ecal region only, Run 1, Run 2)
• Setting "useParametrizedTrackerField" to false everywhere
• Changing the field map to be used for data to the latest model (170812) without parameterization in the tracker
  • The model parameters would be taken from https://github.com/cms-data/MagneticField-Interpolation but it is not there yet, so it needs to be added there first

[bendavid]

since this is not overriding the default magnetic field, I suggest to give it a less generic name to avoid confusion.

[davidwalter2]

Renamed to "Opera3DMagneticFieldProducer"

[davidwalter2]

There was also some configuration missing to use the right geometry for the magnetic field. Now it runs in the custom nano production (tested locally). But it requires the new magnet field model in the https://github.com/cms-data/MagneticField-Interpolation which still has to be added. I've copied it locally for now.

[bendavid]

What's the purpose of these two lines, and what do you mean by "prefer it over any other definition"?

It's important that we don't change the magnetic field map for everything outside of the track refit in order to avoid inadvertently modifying the behaviour of other variables in the NanoAOD.

[bendavid]

(even if these don't actually overwrite the default it would be better to give them less generic names as well to make this clear)

[davidwalter2]

These two lines exist because Opera3DMagneticFieldProducer is the old-style VolumeBasedMagneticFieldESProducer (file-based, not FromDB). Its C++ code hardcodes iRecord.get("magfield", cpv) — it requires a DDCompactView labelled "magfield" from an XMLIdealGeometryESSource. The standard NanoAOD production uses VolumeBasedMagneticFieldESProducerFromDB instead, which reads geometry from MFGeometryFileRcd (GlobalTag blob) and never calls that line, so the default setup never registers a "magfield" source — hence these two lines must be added explicitly.

The standard default field (label "") continues to be served by VolumeBasedMagneticFieldESProducerFromDB via the GlobalTag, unchanged. process.magfield only supplies geometry to Opera3DMagneticFieldProducer, which has a distinct label ("grid_170812_3_8t") used only by the components explicitly configured with MagneticFieldLabel = fieldlabel.

About the renaming, process.magfield must stay named "magfield" — the string "magfield" is hardcoded in the C++ of VolumeBasedMagneticFieldESProducer and is not configurable.

Some info about using two magnet field models can be found in this twiki but it may be outdated

[bendavid]

For running in our local branch we definitely don't/can't rely on any update of cms-data, so everything should be self contained in the PR (ie the configuration should be modified to load the needed files from the src area or wherever they would end up after scram b if possible)

Otherwise how will we systematically run this with crab?
(ok the needed files could be copied to the data directory as part of the setup script in https://github.com/WMass/WMassNanoProduction but that's rather ugly.)