SIM step depends on reco BeamSpot due to PPS transport introduced in #35679

[francescobrivio]

Issue description

While discussing with @mmusich about the conditions for 2023 MC production, we discovered that starting from Run3 (in particular PR #35679) the SIM step depends on the reco-level BeamSpot, as highlighted in #35679 (comment).

This is clearly breaking the whole chain of MC conditions production beacuse it blocks the possibility to have a PU library (which in theory should only depend on the generator VertexSmearing).

Possible solution

As Marco suggests in the same comment, the SimTransport/PPSProtonTransport/src/HectorTransport.cc producer should probably be changed to consume the generator level VertexSmearing instead of the reco BS from the GT, but PPS experts should confirm if this is correct or not.

[cmsbuild]

A new Issue was created by @francescobrivio .

@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[francescobrivio]

assign simulation,ctpps-dpg

[cmsbuild]

New categories assigned: ctpps-dpg,simulation

@mdhildreth,@vavati,@fabferro,@jan-kaspar,@civanch you have been requested to review this Pull request/Issue and eventually sign? Thanks

[civanch]

@fabferro , can you, please, comment or invite somebody with whom we should discuss the issue.

[fabferro]

@diemort is checking

[diemort]

@civanch @fabferro I'm contact with @mundim to take a look at this issue in the following days.

[diemort]

@francescobrivio @mmusich @civanch just for the record, SimTransport/PPSProtonTransport/src/OpticalFunctionsTransport.cc is the default simulation for proton propagation.

As proposed by @mmusich, should we move from BeamSpotObjects to SimBeamSpotObjects ?

[mmusich]

@diemort

should we move from BeamSpotObjects to SimBeamSpotObjects

currently SimBeamSpotObjects is not stored in the Global Tag (there is active no usage yet, though I have been entertaining the idea of using it in lieu of the vertex smearing to minimize the chance of mismatches between GEN and RECO steps), but indeed this looks like a good use case.

[diemort]

@mmusich I see. Does this mean that the previous GTs don't have a record for this object and we need to promote it in the next GTs?

[mmusich]

Does this mean that the previous GTs don't have a record for this object and we need to promote it in the next GTs?

That's correct.

[diemort]

@wpcarvalho can we included this record in the futures PPS GTs? I'm not sure which is the best procedure here.

[wpcarvalho]

@wpcarvalho can we included this record in the futures PPS GTs? I'm not sure which is the best procedure here.

Hi @diemort , sorry for the late comment, somehow I missed this issue. I've seen that @francescobrivio and @mmusich have made improvements to the SimBeamSpotObjects code. Next week I will check what is needed to produce a sensible payload so that you can test it in the MC chain.

[francescobrivio]

@cms-sw/ctpps-dpg-l2 @cms-sw/simulation-l2 I'll close this issue as completed since the Run-1/2/3 cases have been all addressed in cms-AlCaDB/AlCaTools#86.

The remaining Phase-2 case open points will be tracked in cms-AlCaDB/AlCaTools#95, but they have nothing to do with CTPPS.