Opened 14 years ago
Closed 14 years ago
#371 closed defect (invalid)
Automagic integration produces wrong internal analysis results
Reported by: | dwiesler | Owned by: | kilian |
---|---|---|---|
Priority: | P2 | Milestone: | v2.0.4 |
Component: | core | Version: | 2.0.3 |
Severity: | major | Keywords: | integration event generation |
Cc: |
Description
In the attached sindarin example, only the version where automagic integration of an unstable particle is activated produces the correct results. If the integration is requested manually, the event generation takes about a factor of 100 longer and the internally produced histogram is obviously wrong.
I'm not sure wether this is a specific 'feature' of my PSSSM version, I'm trying to reproduce this with an edited version of the casc_dec.sin example.
.sin - example:
model = PSSSM process dec_lqino_tb = lqino1 => u,e1,neu1 { $restrictions = "3+4~'se1-'" } process sig1 = u,g => SE11, lqino1 compile ?slha_read_decays = true read_slha("sps1aNMSSMed.in") !if integrate is not commented out, the histogram gets faulty and event generation takes longer by a factor of 100?! !integrate (dec_lqino_tb) mlqino_1 = 600 wlqino_1 = 5.87 yuk_nd = 0.312 yuk_d1 = 0.312 yuk_d2 = 0 yuk_dc = 0.312 sqrts = 14000 beams = p, p => lhapdf integrate (sig1) { iterations = 5:50000, 2:50000 } n_events = 10000 histogram inv_mass1_tb (0,1000,10) unstable lqino1 (dec_lqino_tb) simulate (sig1) { $sample = "test" sample_format = lhef checkpoint = 1000 analysis = record inv_mass1_tb (eval M [combine[u,e1]]) } write_analysis compile_analysis { $out_file = "sigtehest.dat"}
Attachments (4)
Change History (5)
Changed 14 years ago by
Attachment: | correct.pdf added |
---|
Changed 14 years ago by
Changed 14 years ago by
Attachment: | failing.sin added |
---|
Changed 14 years ago by
Attachment: | sps1aNMSSMed.in added |
---|
comment:1 Changed 14 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
Stupid stupid me, the faulty histograms were due to the mass parameter set AFTER the first (manual) integration, confirming that in my case the problem is mostly located between the keyboard and the chair...
The speed issues seem to depend on the amount of parameters defined after the manually requested decay integration. This is strange, but not relevant for the output, thus I close this ticket for good!