search

cms-AlCaDB / AlCaTools

Collection of Tools for daily work of CMS AlCa/DB team
1 stars 18 forks source link

Add `SimBeamSpotObjects` to MC Global Tags #86

Closed francescobrivio closed 11 months ago

francescobrivio commented 1 year ago

Multi-step solution for https://github.com/cms-sw/cmssw/issues/41894:

mmusich commented 1 year ago

In order to help with this step

  • [ ] Include the new tags in the MC GTs
    • Need to check:
      • Which GTs should actually be updated, only Run3 or also Run2 and Run1?
      • The correct correspondence between GT <-> tag

and hence make progress with https://github.com/cms-sw/cmssw/pull/42664 I started to compile the coupling Global Tag <-> SimBeamSpot tag for each simulation GT key of autoCond (as of CMSSW_13_3_X_2023-08-25-2300), in order to decide which tags to move from the preparation to the production database. You can find it below:

Follows list of GT ⇆ tag couplings * `run1_design` : `131X_mcRun1_design_v2` * `BeamSpotObjectsRcd` : `Realistic8TeVCollisions_START50_V13_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic8TeVCollisionVtxSmearingParameters_v0_mc`, * `run1_mc` : `131X_mcRun1_realistic_v2` * `BeamSpotObjectsRcd` : `Realistic8TeVCollisions_START50_V13_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic8TeVCollisionVtxSmearingParameters_v0_mc` * `run1_mc_hi` : `131X_mcRun1_HeavyIon_v2` * `BeamSpotObjectsRcd` : `RealisticHICollisions2013_START53_V9_v1_mc` *`SimBeamSpotObjectsRcd` : `SimBeamSpot_RealisticHIpPb2013CollisionVtxSmearingParameters_v0_mc`, * `run2_mc_50ns` : `131X_mcRun2_startup_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic50ns_13TeVCollisions_Startup_v0_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic50ns13TeVCollisionVtxSmearingParameters_v0_mc`, * `run2_mc_l1stage1` : `131X_mcRun2_asymptotic_l1stage1_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic50ns_13TeVCollisions_Asymptotic_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic50ns13TeVCollisionVtxSmearingParameters_v0_mc`, * `run2_mc_pre_vfp` : `131X_mcRun2_asymptotic_preVFP_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeV2016Collisions_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeV2016CollisionVtxSmearingParameters_v0_mc`, * `run2_mc` : `131X_mcRun2_asymptotic_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeV2016Collisions_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeV2016CollisionVtxSmearingParameters_v0_mc`, * `run2_mc_cosmics` : `131X_mcRun2cosmics_asymptotic_deco_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeV2016Collisions_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeV2016CollisionVtxSmearingParameters_v0_mc`, * `run2_mc_hi` : `131X_mcRun2_HeavyIon_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_RealisticHICollision2015_MC_75X_v1` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_RealisticHICollisionFixZ2015VtxSmearingParameters_v0_mc`, * `run2_mc_pa` : `131X_mcRun2_pA_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic8TeVPACollision2016_v1` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic8TeVPACollision2016VtxSmearingParameters_v0_mc`, * `phase1_2017_realistic` : `131X_mc2017_realistic_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2017_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2017CollisionVtxSmearingParameters_v0_mc`, * `phase1_2017_cosmics` : `131X_mc2017cosmics_realistic_deco_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2017_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2017CollisionVtxSmearingParameters_v0_mc`, * `phase1_2017_cosmics_peak` : `131X_mc2017cosmics_realistic_peak_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2017_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2017CollisionVtxSmearingParameters_v0_mc`, * `phase1_2018_realistic` : `131X_upgrade2018_realistic_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2018_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2018CollisionVtxSmearingParameters_v0_mc`, * `phase1_2018_realistic_rd` : `131X_upgrade2018_realistic_RD_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2018_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2018CollisionVtxSmearingParameters_v0_mc`, * `phase1_2018_realistic_hi` : `131X_upgrade2018_realistic_HI_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic_5TeVPbPb_HI2018A_MC_v1` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_RealisticPbPbCollision2018VtxSmearingParameters_v0_mc` * `phase1_2018_realistic_HEfail` : `131X_upgrade2018_realistic_HEfail_v3` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2018_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2018CollisionVtxSmearingParameters_v0_mc`, * `phase1_2018_cosmics` : `131X_upgrade2018cosmics_realistic_deco_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2018_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2018CollisionVtxSmearingParameters_v0_mc`, * `phase1_2018_cosmics_peak` : `131X_upgrade2018cosmics_realistic_peak_v3` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13TeVCollisions_Early2018_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13TeVEarly2018CollisionVtxSmearingParameters_v0_mc`, * `phase1_2022_realistic` : `132X_mcRun3_2022_realistic_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_EOY2022_v2_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEOY2022CollisionVtxSmearingParameters_v0_mc`, * `phase1_2022_realistic_postEE` : `132X_mcRun3_2022_realistic_postEE_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_EOY2022_v2_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEOY2022CollisionVtxSmearingParameters_v0_mc`, * `phase1_2022_cosmics` : `132X_mcRun3_2022cosmics_realistic_deco_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_EOY2022_v2_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEOY2022CollisionVtxSmearingParameters_v0_mc`, * `phase1_2022_realistic_hi` : `132X_mcRun3_2022_realistic_HI_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic2022PbPbCollision_v5_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic2022PbPbCollisionVtxSmearingParameters_v0_mc`, * `phase1_2023_realistic` : `132X_mcRun3_2023_realistic_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_Early2023_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEarly2023CollisionVtxSmearingParameters_v0_mc`, * `phase1_2023_realistic_postBPix` : `132X_mcRun3_2023_realistic_postBPix_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_Early2023_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEarly2023CollisionVtxSmearingParameters_v0_mc`, * `phase1_2023_cosmics` : `132X_mcRun3_2023cosmics_realistic_deco_v2` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_Early2023_v1_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEarly2023CollisionVtxSmearingParameters_v0_mc`, * `phase1_2023_realistic_hi` : `132X_mcRun3_2023_realistic_HI_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic2022PbPbCollision_v5_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic2022PbPbCollisionVtxSmearingParameters_v0_mc`, * `phase1_2024_realistic` : `132X_mcRun3_2024_realistic_v1` * `BeamSpotObjectsRcd` : `BeamSpotObjects_Realistic25ns_13p6TeVCollisions_Early2022_v3_mc` * `SimBeamSpotObjectsRcd` : `SimBeamSpot_Realistic25ns13p6TeVEarly2022CollisionVtxSmearingParameters_v0_mc`,
mmusich commented 1 year ago

While compiling this list, one issue with this approach that occurred to me, is that the current SimBeamSpotObjects CondFormat assumes that the simulation step happens via the BetafuncEvtVtxGenerator, while there are instead use cases that use a different functional form (e.g. in the case of the design simulation the GaussEvtVtxGenerator or in the case of phase-2 simulation the HLLHCEvtVtxGenerator). These use a different set of parameters that cannot be translated into the existing SimBeamSpotObjects data layout. I guess it's up to discussion if (given that currently there is no tag associated to this C++ class in the production database) if it's appropriate to amend the class layout to allow these parameters, or if otherwise devise entirely different classes (and hence EventSetup records).

Below the list of PSets in IOMC/EventVertexGenerators/python/VtxSmearedParameters_cfi.py affected by this problem:

GaussVtxSigmaZ4cmSmearingParameters : cms.PSet(
    MeanX = cms.double(0.0),
    MeanY = cms.double(0.0),
    MeanZ = cms.double(0.0),
    SigmaX = cms.double(0.0015),
    SigmaY = cms.double(0.0015),
    SigmaZ = cms.double(4.0),
    TimeOffset = cms.double(0.0)
)
GaussVtxSmearingParameters : cms.PSet(
    MeanX = cms.double(0.0),
    MeanY = cms.double(0.0),
    MeanZ = cms.double(0.0),
    SigmaX = cms.double(0.0015),
    SigmaY = cms.double(0.0015),
    SigmaZ = cms.double(5.3),
    TimeOffset = cms.double(0.0)
)
HLLHCCrabKissingVtxSmearingParameters : cms.PSet(
    BeamProfile = cms.string('Flat'),
    BetaStarCrossingPlaneInm = cms.double(0.3),
    BetaStarParallelPlaneInm = cms.double(0.075),
    CrabAngleCrossingPlaneInurad = cms.double(200.0),
    CrabAngleParallelPlaneInurad = cms.double(100.0),
    CrabFrequencyCrossingPlaneInMHz = cms.double(400.0),
    CrabFrequencyParallelPlaneInMHz = cms.double(400.0),
    EprotonInGeV = cms.double(6500.0),
    HalfCrossingAngleInurad = cms.double(200.0),
    MeanXIncm = cms.double(0.0),
    MeanYIncm = cms.double(0.0),
    MeanZIncm = cms.double(0.0),
    NormalizedEmittanceCrossingPlaneInum = cms.double(2.5),
    NormalizedEmittanceParallelPlaneInum = cms.double(2.5),
    TimeOffsetInns = cms.double(0.0),
    ZsizeInm = cms.double(0.15)
)
HLLHCVtxSmearingParameters : cms.PSet(
    BetaCrossingPlaneInm = cms.double(0.2),
    BetaSeparationPlaneInm = cms.double(0.2),
    BunchLengthInm = cms.double(0.09),
    CrabFrequencyInMHz = cms.double(400.0),
    CrabbingAngleCrossingInurad = cms.double(380.0),
    CrabbingAngleSeparationInurad = cms.double(0.0),
    CrossingAngleInurad = cms.double(510.0),
    EprotonInGeV = cms.double(6500.0),
    HorizontalEmittance = cms.double(2.5e-06),
    MeanXIncm = cms.double(0.0),
    MeanYIncm = cms.double(0.0),
    MeanZIncm = cms.double(0.0),
    RF800 = cms.bool(False),
    TimeOffsetInns = cms.double(0.0),
    VerticalEmittance = cms.double(2.05e-06)
)
Run3FlatOpticsGaussVtxSigmaZ4p2cmSmearingParameters : cms.PSet(
    MeanX = cms.double(0.0107682),
    MeanY = cms.double(0.041722),
    MeanZ = cms.double(0.035748),
    SigmaX = cms.double(0.00118),
    SigmaY = cms.double(0.00055),
    SigmaZ = cms.double(4.2),
    TimeOffset = cms.double(0.0)
)
Run3FlatOpticsGaussVtxSigmaZ5p3cmSmearingParameters : cms.PSet(
    MeanX = cms.double(0.0107682),
    MeanY = cms.double(0.041722),
    MeanZ = cms.double(0.035748),
    SigmaX = cms.double(0.0015),
    SigmaY = cms.double(0.0013),
    SigmaZ = cms.double(5.3),
    TimeOffset = cms.double(0.0)
)
civanch commented 1 year ago

@mmusich , would be correct if we will try to resolve the issue in the next release cycle? The dead-line for 13_3 is too close.

mmusich commented 1 year ago

@civanch

would be correct if we will try to resolve the issue in the next release cycle? The dead-line for 13_3 is too close.

Personally, I don't mind. I am waiting the alca people to comment on the points above. @saumyaphor4252 @francescobrivio

mmusich commented 1 year ago

may I ask where we stand with this issue . @saumyaphor4252 @francescobrivio

francescobrivio commented 1 year ago

I plan to take a look this afternoon, sorry for the delay!

francescobrivio commented 1 year ago

Thanks @mmusich for compiling the list and pointing out the missing ingredients! Regarding:

if it's appropriate to amend the class layout to allow these parameters, or if otherwise devise entirely different classes (and hence EventSetup records).

I compiled a list of all the members that would be needed:

fX0          // for BetafuncEvtVtxGenerator only
fY0
fZ0
fbetastar
femittance
fPhi
fAlpha

fSigmaZ      // for BetafuncEvtVtxGenerator and GaussEvtVtxGenerator

fSigmaX      // for GaussEvtVtxGenerator only
fSigmaY

fMeanX       // for GaussEvtVtxGenerator and HLLHCEvtVtxGenerator
fMeanY
fMeanZ

momeV        // for HLLHCEvtVtxGenerator only
phi
wcc
RF800
betx
bets
epsxn
epssn
sigs
alphax
alphay

fTimeOffset  // for all three generators

So, given that the original SimBeamSpotObjects alraedy includes 9 of them, we can update it to include them all.

But there are a few parameters defined in HLLHCCrabKissingVtxSmearingParameters:

     BeamProfile = cms.string('Flat'),
     BetaStarCrossingPlaneInm = cms.double(0.3),
     BetaStarParallelPlaneInm = cms.double(0.075),
     CrabAngleCrossingPlaneInurad = cms.double(200.0),
     CrabAngleParallelPlaneInurad = cms.double(100.0),
     CrabFrequencyCrossingPlaneInMHz = cms.double(400.0),
     CrabFrequencyParallelPlaneInMHz = cms.double(400.0),
     HalfCrossingAngleInurad = cms.double(200.0),
     NormalizedEmittanceCrossingPlaneInum = cms.double(2.5),
     NormalizedEmittanceParallelPlaneInum = cms.double(2.5),
     ZsizeInm = cms.double(0.15)

That are not used in any .cc/.h file (as a matter of fact they are not used anywhere as this example search in cmssw shows), so I'm not sure how to treat those...

Alternatively one could think about updating the current simBS object with the parameters needed by the GaussEvtVtxGenerator now, and postpone this migration for the Phase2 GT to later, by making an entirely new record/object for the HLLHC case. Would this be technically doable (i.e. to decaouple the Phase2 GT update)?

What do you think? I'm open to suggestions!

mmusich commented 1 year ago

Alternatively one could think about updating the current simBS object with the parameters needed by the GaussEvtVtxGenerator now, and postpone this migration for the Phase2 GT to later, by making an entirely new record/object for the HLLHC case. Would this be technically doable (i.e. to decaouple the Phase2 GT update)?

I think it's probably better to settle the question now that the record is "virgin" (never used in production). About the parameters never referenced in the source code we should follow up with the developers that created the configuration in the first place.

francescobrivio commented 1 year ago

Dear @lgray, sorry to drag you into this discussion, but from github history it seems like you were the last one to update the HL-LHC beamspot parameters in CMSSW!

We are trying to migrate the vertex smearing parameters to the GT (see issue description and the following discussion for details), and we noticed that in https://github.com/cms-sw/cmssw/pull/16942 you removed some of the parameters used by IOMC/EventVertexGenerators/interface/HLLHCEvtVtxGenerator.h, but the same parameters were never cleaned up in the HLLHCCrabKissingVtxSmearingParameters configuration, see: https://github.com/cms-sw/cmssw/blob/2cd78edfb8f8a002926332e7cd5eedbd000501b6/IOMC/EventVertexGenerators/python/VtxSmearedParameters_cfi.py#L1080-L1098

Was that done on purpose? Or simply forgotten?

Thanks a lot!

Cheers, Francesco

francescobrivio commented 1 year ago

First part of this issue, regarding Run-1/2/3 GTs, is almost done, see: https://cms-talk.web.cern.ch/t/mc-new-simbeamspotobjectsrcd-tags-for-run1-2-3-mc-gts/31292

For the Phase-2 GT: the work to define a new CondFormat is ongoing in https://github.com/cms-sw/cmssw/pull/43186

francescobrivio commented 1 year ago

Run-1/2/3 MC GTs are being updated in https://github.com/cms-sw/cmssw/pull/43197

mmusich commented 11 months ago

my take is that this issue can be closed. Is there anything outstanding @francescobrivio ?

francescobrivio commented 11 months ago

my take is that this issue can be closed. Is there anything outstanding @francescobrivio ?

The only remaining open point is the HL-LHC case (GT, CondFormat. etc...). We can probably move that to a new issue for bookkeeping.

lgray commented 11 months ago

Oh the reasoning from back in the day was that those parameterizations did not need those parameters. I didn't remove them from the python config because I was lazy. :-)

francescobrivio commented 11 months ago

Oh the reasoning from back in the day was that those parameterizations did not need those parameters. I didn't remove them from the python config because I was lazy. :-)

Thanks for the feedback @lgray! No problem I can take care of the cleanup!

If you don't mind, could you have a look at https://github.com/cms-sw/cmssw/pull/43186 and provide any feedback in case you have it?

francescobrivio commented 11 months ago

Closing in favor of https://github.com/cms-AlCaDB/AlCaTools/issues/95 which will be used to track the remaining open points for the HL-LHC case.