Set StandardSequences to take MF geometry and configuration from the DB

[namapane]

This update sets the StandardSequences for MF to take MF configuration and geometry from the DB (ie linked to the GT). No code change (everything was ready in #5785, but it took ages to get new payloads in the DB).
No change in results. Regression-tested for all nominal maps.

[cmsbuild]

A new Pull Request was created by @namapane (Nicola Amapane) for CMSSW_7_5_X.

Set StandardSequences to take MF geometry and configuration from the DB

It involves the following packages:

Configuration/StandardSequences

@cmsbuild, @franzoni, @nclopezo, @davidlange6 can you please review it and eventually sign? Thanks.
@ghellwig, @appeltel, @makortel, @GiacomoSguazzoni, @rovere, @VinInn, @Martin-Grunewald, @cerati, @dgulhan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@nclopezo you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

-1
Tested at: 2ece9db
The relvals timed out after 2 hours.

When I ran the RelVals I found an error in the following worklfows:
9.0 step3

runTheMatrix-results/9.0_Higgs200ChargedTaus+Higgs200ChargedTaus+DIGI+RECO+HARVEST/step3_Higgs200ChargedTaus+Higgs200ChargedTaus+DIGI+RECO+HARVEST.log
----- Begin Fatal Exception 21-Apr-2015 20:43:11 CEST-----------------------
An exception of category 'NoProxyException' occurred while
   [0] Processing run: 1 lumi: 1 event: 1
   [1] Running path 'reconstruction_step'
   [2] Calling event method for module SeedGeneratorFromRegionHitsEDProducer/'initialStepSeedsPreSplitting'
   [3] Using EventSetup component PropagatorWithMaterialESProducer/'MaterialPropagatorParabolicMF' to make data Propagator/'PropagatorWithMaterialParabolicMf' in record TrackingComponentsRecord
Exception Message:
No data of type "MagneticField" with label "ParabolicMf" in record "IdealMagneticFieldRecord"
 Please add an ESSource or ESProducer to your job which can deliver this data.
----- End Fatal Exception -------------------------------------------------

25.0 N/A

you can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8814/4317/summary.html

[cmsbuild]

+1
Tested at: ca05e41
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8814/7261/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8814/7261/summary.html

[slava77]

prompted by somewhat large changes in jenkins comparisons only in run1 MC fullsim workflows, I checked locally with matrix workflows recycling the gensim.
There are no differences in this case.
For workflow 25.0 with recycled gensim the input is /RelValTTbar/CMSSW_7_1_0_pre7-PRE_STA71_V3-v1/GEN-SIM

Nicola, do you know why would we get a different behavior in SIM (Geant) before and after this PR?
Is it a matter of numerical precision level discrepancy of the mag field in the grid files vs DB or did the values change significantly?
Clearly GEANT with all random numbers involved, is very sensitive to small changes in the field values.

I used CMSSW_7_5_X_2015-04-21-1100 for testing.
jenkins tests were done in CMSSW_7_5_X_2015-04-21-2300

[namapane]

Dear Slava,

NO difference in the field is expected: we are not changing the map,
only updating the way it is configured. The actual map is, bitwise, the
same, if the same conditions/config are used.

So if you see a difference it means that the configuration used is
different than what was used in the reference. What GT did you use in
the tests? what magfield .py is loaded?

Cheers
Nicola

On 24-Apr-15 17:34, Slava Krutelyov wrote:

prompted by somewhat large changes in jenkins comparisons only in run1
MC fullsim workflows, I checked locally with matrix workflows recycling
the gensim.
There are no differences in this case.
For workflow 25.0 with recycled gensim the input is
/RelValTTbar/CMSSW_7_1_0_pre7-PRE_STA71_V3-v1/GEN-SIM

Nicola, do you know why would we get a different behavior in SIM (Geant)
before and after this PR?
Is it a matter of numerical precision level discrepancy of the mag field
in the grid files vs DB or did the values change significantly?
Clearly GEANT with all random numbers involved, is very sensitive to
small changes in the field values.

I used CMSSW_7_5_X_2015-04-21-1100 for testing.
jenkins tests were done in CMSSW_7_5_X_2015-04-21-2300

—
Reply to this email directly or view it on GitHub
#8814 (comment).

[namapane]

Checking further, I ran a regression test of the field map between CMSSW_7_5_X_2015-04-21-1100 and CMSSW_7_5_X_2015-04-21-1100 + this PR, using auto:run1_mc as GT and Configuration.StandardSequences.MagneticField_38T_cff, like what is done in the workflow 25.0. I find no difference at all in the MF.
(In principle, some rounding difference in the MF geometry can be present as with the new tag the geometry is created from a DB blob instead than from the XML, and there's some numerical rounding in the conversion XML->db. This would lead in extremely rare cases to a difference in the field value of a point sitting within the float numerical accuracy to a volume boundary. I have observed such differences in the past, but these do not seem to be present in this case).

So, I don't see anything wrong and neither no reason why this PR would give any differece, at least when the field is called with this .py and using this GT.

[slava77]

I think that the expected small differences in the volume boundaries explain what we see. So, I don't see showstoppers here.