Update the magnetic field model for data#42
Update the magnetic field model for data#42davidwalter2 wants to merge 4 commits intoWMass:WmassNanoProd_10_6_26from
Conversation
davidwalter2
commented
Dec 5, 2025
- 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
| from MagneticField.Engine.volumeBasedMagneticField_170812_cfi import VolumeBasedMagneticFieldESProducer as MagneticFieldProducer | ||
| fieldlabel = "grid_170812_3_8t" | ||
|
|
||
| process.MagneticFieldProducer = MagneticFieldProducer |
There was a problem hiding this comment.
since this is not overriding the default magnetic field, I suggest to give it a less generic name to avoid confusion.
There was a problem hiding this comment.
Renamed to "Opera3DMagneticFieldProducer"
… over any other definition
|
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. |
| process.magfield = MagneticFieldGeometry | ||
| process.es_prefer_magfield = es_prefer_magfield |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
(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)
|
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? |