Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleaning obsolete GeometryExtended2026D* from all config files; Use Default config #42945

Open
srimanob opened this issue Oct 4, 2023 · 22 comments

Comments

@srimanob
Copy link
Contributor

srimanob commented Oct 4, 2023

D49 geometry is obsolete for long time, however there are still numbers of config files which keep it
https://github.com/search?q=repo%3Acms-sw%2Fcmssw+GeometryExtended2026D49&type=code&p=1
I assume none of them are used.

This ticket is to keep track of cleaning the config files on Phase-2.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 4, 2023

A new Issue was created by @srimanob Phat Srimanobhas.

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

cms-bot commands are listed here

@srimanob
Copy link
Contributor Author

srimanob commented Oct 4, 2023

assign upgrade

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 4, 2023

New categories assigned: upgrade

@AdrianoDee,@srimanob you have been requested to review this Pull request/Issue and eventually sign? Thanks

@mmusich
Copy link
Contributor

mmusich commented Oct 18, 2023

This is a recurrent issue.
Developers that need or want to to create a test configuration for Phase 2, usually choose to use the default of that cycle, but then the default moves to something else and the test configuration remains stuck with the old geometry.
Would it make sense to create a couple of files:

Configuration/Geometry/python/GeometryExtended2026Default_cff.py and
Configuration/Geometry/python/GeometryExtended2026DefaultReco_cff.py

which contain just the import * of the contemporary default (e.g. now using D98)?.
Then one can just use these and it will be automatically "forward ported" everywhere when the default changes.

@srimanob
Copy link
Contributor Author

srimanob commented Jan 9, 2024

@mmusich @cms-sw/alca-l2
One thing just pops up to me is that even we make a default one, config still need to update the GT which include customization (i.e. T21), right? Is the GT defined in autoCond always point to the default geometry?
https://github.com/cms-sw/cmssw/blob/master/Configuration/AlCa/python/autoCond.py#L93

Thx.

@mmusich
Copy link
Contributor

mmusich commented Jan 9, 2024

Is the GT defined in autoCond always point to the default geometry?

normally yes, but it's not strictly enforced (at least to my knowledge).

@srimanob
Copy link
Contributor Author

srimanob commented Jan 9, 2024

Thanks @mmusich

Question to @cms-sw/alca-l2
Is it possible to keep the default Phase-2 GT to match with default geometry baseline? I think this is the key to load default config and get everything properly. I understand that this is kind of manual book-keeping, but I don't expect we change drastically often.

@perrotta
Copy link
Contributor

@srimanob the GT in autocond is supposed to point to the default geometry. If not, it should be notified and then updated. Yes, this is a manual procedure: please let AlCa know in case any update is needed for it.

@mmusich
Copy link
Contributor

mmusich commented Jan 10, 2024

the GT in autocond is supposed to point to the default geometry. If not, it should be notified and then updated. Yes, this is a manual procedure: please let AlCa know in case any update is needed for it.

@perrotta, if that's the case, this situation is currently not verified for the master branch in which the default geometry is D98 (which should use auto:phase2_realistic_T25 as per

), while the autoCond key seems still to point to a T21 geometry:

'phase2_realistic' : '133X_mcRun4_realistic_v1'

please cross-check.

@perrotta
Copy link
Contributor

Thank you @mmusich.

Therefore, if I understand correctly, the default geometry should be the one that corresponds to the T25 customization in Configuration/AlCa/python/autoCondPhase2.py, which is different from what currently in the DB (T21, as far as I can see).

The tracker config which corresponds to D98 should be T32 rather than T25. However, I imagine that they are similar enough that do not require separated tracker configurations (see Configuration/Geometry/README.md): correct?

In any case Configuration/AlCa/python/autoCondPhase2.py only customizes the Tracker geometry: is it enough to migrate just them , or should we also customize other subsystems in the GT, instead, to fully migrate to D98?

And, finally: @srimanob are you requesting to update the affected tags in the Phase2 default GT in order to synchronize it with the current default D98 update geometry? Or that "default" is expected to change often, so that the customizations are more practical, instead? In any case, this could be implemented when we'll derive the 140X GTs for Phase2.

@mmusich
Copy link
Contributor

mmusich commented Jan 10, 2024

The tracker config which corresponds to D98 should be T32 rather than T25. However, I imagine that they are similar enough that do not require separated tracker configurations (see Configuration/Geometry/README.md): correct?

it is not only similar enough, it is identical, see

* T32: Phase2 tilted tracker. The tracker description is identical to T25. The outer radius of the tracker volume is reduced to avoid a clash with the BTL geometry (same as T31). The positions of the tracker components are not affected. This geometry is intended as a transition step towards a realistic configuration with 3D sensors in TBPX layer1.

In any case Configuration/AlCa/python/autoCondPhase2.py only customizes the Tracker geometry: is it enough to migrate just them

this is NOT the case, it customizes all the conditions that depend on the geometry.

or should we also customize other subsystems in the GT, instead, to fully migrate to D98?

as far as I am aware the Tracker is the only subsystem that supports different geometries (with geometry-dependent conditions) in the same release.

@srimanob
Copy link
Contributor Author

Hi @perrotta

The default may change 2-3 times a year (~HGCal, Tracker, MTD at least once a year). I try to keep running the most recent geometry. As @mmusich states, only tracker that needs customization. So, maybe 1 (or 2) times a year that we update the tracker baseline, we will need your help to update the GT.

Regarding to move Phase-2 GT to T25, do you need something from Phase-2 tracker (or me), or any short talk at Alca meeting before the GT will be built. Thanks.

@perrotta
Copy link
Contributor

Regarding to move Phase-2 GT to T25, do you need something from Phase-2 tracker (or me), or any short talk at Alca meeting before the GT will be built. Thanks.

It would be appropriate, indeed, in particular to decide the update strategies: thank you for proposing it, Phat.
Would you be available already this Monday https://indico.cern.ch/event/1358549? Othewise next one could also be ok.

@mmusich
Copy link
Contributor

mmusich commented Jan 10, 2024

It would be appropriate, indeed, in particular to decide the update strategies

Technically that's nothing terribly new (see here for some details).
The main thing to manually enforce is just that the auto:phase2_realistic GT key is a "physical" copy of the "symbolic" auto:phase2_realistic_TXX corresponding to the geometry currently default in release (which was sort of implied when this arrangement was first stipulated, see also #27517). This step is in any case always required for phase2 sample production as the production infrastructure is not technically capable of digesting symbolic GT keys.

EDIT : incidentally I think the tracker geometry for phase2 in converging (after some technical difficulties are overcome) to a final layout sometime this year, so this extra requirement would be fairly soon dropped.

@perrotta
Copy link
Contributor

It would be appropriate, indeed, in particular to decide the update strategies

Technically that's nothing terribly new (see here for some details).

Thank you for the link. It is indeed almost five years old (I see that "2023" was the reference year for Phase2 in it...) and it is probably worth to quickly refresh the audience at the AlCa meeting.

The main thing to manually enforce is just that the auto:phase2_realistic GT key is a "physical" copy of the "symbolic" auto:phase2_realistic_TXX corresponding to the geometry currently default in release (which was sort of implied when this arrangement was first stipulated, see also #27517). This step is in any case always required for phase2 sample production as the production infrastructure is not technically capable of digesting symbolic GT keys.

This is indeed the main point: to decide when to manually update the "physical" GT key and the autoCond link: new campaigns, new releases, when the Upgrade contact tells AlCa that a new default geometry was agreed...

EDIT : incidentally I think the tracker geometry for phase2 in converging (after some technical difficulties are overcome) to a final layout sometime this year, so this extra requirement would be fairly soon dropped.

Great, some less manual work to adapt to it in sight, then!

@srimanob
Copy link
Contributor Author

Hi @perrotta

I will be available on Monday for short update on phase 2 geometry and workflow. Thx.

@perrotta
Copy link
Contributor

Hi @perrotta

I will be available on Monday for short update on phase 2 geometry and workflow. Thx.

Thank you Phat, added to the agenda: https://indico.cern.ch/event/1358549

@mmusich
Copy link
Contributor

mmusich commented Jan 16, 2024

Thank you Phat, added to the agenda: https://indico.cern.ch/event/1358549

for those who didn't attend (since there are no minutes posted), would it be possible to summarize here the action items on this topic?

@perrotta
Copy link
Contributor

Thank you Phat, added to the agenda: https://indico.cern.ch/event/1358549

for those who didn't attend (since there are no minutes posted), would it be possible to summarize here the action items on this topic?

  • We will move the Phase 2 GTs to the T25 as soon as we migrate to the 140X queues. Other queues can be also updated if requested.
  • Upgrade coordination will keep AlCa informed whenever a new default Phase 2 geometry is decided, so that the Phase2 GTs can be updated accordingly: a couple of updates per year are expected now, even less when those geometries will further stabilize.

@perrotta
Copy link
Contributor

A new GT, 140X_mcRun4_realistic_v1, with the "default" T25 Phase2 tracker geometry was created

You can see the tag difference with respect to previous 133X_mcRun4_realistic_v1 in:
https://cms-conddb.cern.ch/cmsDbBrowser/diff/Prod/gts/133X_mcRun4_realistic_v1/140X_mcRun4_realistic_v1

The new GT will be included in autocond in 140X as default GT for Phase2

@saumyaphor4252
Copy link
Contributor

The new GT will be included in autocond in 140X as default GT for Phase2

Here's the PR to include the above GT in autoCond: #43763

@srimanob
Copy link
Contributor Author

Thanks @cms-sw/alca-l2

@srimanob srimanob changed the title Cleaning GeometryExtended2026D49* from all config files Cleaning obsolete GeometryExtended2026D* from all config files; Use Default config Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants