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
Moved fastSim reconstruction to use era #20884
Conversation
The code-checks are being triggered in jenkins. |
I used release validation workflow 25402.0 as the test bed. I used the following simple configuration for testing
With that configuration, I found the my change returns a configuration with exactly the same module configuration as before. In addition, I checked that the Paths |
@gartung here is the fastsim change |
+code-checks |
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages: Configuration/StandardSequences @perrotta, @civanch, @lveldere, @ssekmen, @mdhildreth, @cmsbuild, @franzoni, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
-1 Tested at: 50c957c The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: You can see the results of the tests here: I found follow errors while testing this PR Failed tests: RelVals
When I ran the RelVals I found an error in the following worklfows: runTheMatrix-results/1000.0_RunMinBias2011A+RunMinBias2011A+TIER0+SKIMD+HARVESTDfst2+ALCASPLIT/step3_RunMinBias2011A+RunMinBias2011A+TIER0+SKIMD+HARVESTDfst2+ALCASPLIT.log The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
The workflow 1000.0 is failing in the IBs with the exact same configuration error. |
Changes in this PR should be discussed in some joint meeting with fastsim category managers. |
We have indeed planned to discuss the PR in the next simulation meeting when all simulation conveners are available. |
On 10/25/17 9:58 AM, Matti Kortelainen wrote:
Below are some comments regarding changes in tracking configurations
after some more thought.
We are not particularly happy of making the already-complex iterative
tracking configuration files more complicated. Said that, this PR alone
would be acceptable (even if barely) for us. But we have concerns what
will happen when FastSim will start to support phase1 pixel+tracking
(will 2016 support continue?) or phase2 at some point.
Were any alternative strategies thought (even if they would more or less
break the era design "modify module where it is defined")? E.g. would
something along the following work out in light of the Task migration
(#20879 <#20879>)
# In FastSimulation/Configuration/python/Reconstruction_cff.py
from Configuration.StandardSequences.Reconstruction_cff import *
<move all reco fastsim era customizations here>
? (basically following the current separation of FastSim and Reco but
doing the reco customizations using the |fastsim| era)
Design of eras works best if the modifiers are applied in the same file
where the original modules are defined.
Perhaps it's time to think of refactoring the Iter_cff files?
Best would be to see the same configuration used for fastsim and fullsim
reco.
How far are we from that point?
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20884 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbqHXpm0AiI9Pb7ren0woAPO1-o5Vks5svuo0gaJpZM4P0f5x>.
|
Do you mean something like for each iterations splitting the seeding, pattern recognition+final fit, and selection to their own cff files imported in the main iteration cff file that also defines the iteration Task(/Sequence)? |
On 10/25/17 10:58 AM, Matti Kortelainen wrote:
Perhaps it's time to think of refactoring the Iter_cff files?
Do you mean something like for each iterations splitting the seeding,
pattern recognition+final fit, and selection to their own cff files
imported in the main iteration cff file that also defines the iteration
Task(/Sequence)?
I haven't thought of a specific change pattern.
It was more of a general statement
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20884 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbgHwjhwDJ4bgWW9UhTruM8A5vSUnks5svvhBgaJpZM4P0f5x>.
|
I agree with Slava
and I will go further. Not putting the modifier in the original module can lead to unforseen side-effects. E.g. clones that do not match or sequences that break. |
@Perrota, discussing with the FastSim tracking experts. We will come with a more concrete plan at our presentation at the tracking meeting on Nov 6. |
Thank you Sezen.
At the same time, I have to correct myself, and apologize: #20884 and
#20666 do NOT interfere each other, in the sense that I was able to
merge them one on top of the other, without conflicts, starting from
940pre3. I only badly interpreted the git output at a first glance.
Anyhow, having a concrete plan is good: let us know after nov 6. (At
this point, I must imagine that they are both only meant to 10_0_X and
the 2018+ releases.
Cheers,
Andrea
Sezen Sekmen <notifications@github.com> ha scritto:
… @Perrota, discussing with the FastSim experts. We will come with a
more concrete plan at our presentation at the tracking meeting on
Nov 6.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#20884 (comment)
|
+1
|
hi @civanch - this is the PR discussed in the ORP yesterday |
+1 |
merge |
@Dr15Jones I noticed some failures in fastsim premixing workflows in the IB tests (https://cms-sw.github.io/relvalLogDetail.html#slc7_aarch64_gcc700;CMSSW_10_0_X_2017-11-10-1100):
Might be caused by this PR, can you take a look? |
ah, I see you were faster than me with #21263. |
When trying to convert the reconstruction configurations from Sequences to Tasks, we found that the fastsim was greatly complicating the transition. One reason was the fastsim was directly rewriting Configuration.StandardSequences.Reconstruction_cff from within FastSimulation.Configuration.Reconstruction_AftMix_cff which was leading to very 'brittle' configuration code. For example, if someone accidently loaded Reconstruction_cff into the Process before Reconstruction_AftMix_cff the configuration would no longer work. Switching to fully using the fastSim era avoids many problems and makes fastsim behave like the other configuration modification workflows.