#144 closed defect (fixed)
Max_Epsilon seems broken
| Reported by: | Steffen Schumann | Owned by: | Frank Siegert |
|---|---|---|---|
| Priority: | blocker | Milestone: | |
| Component: | Unknown | Version: | 0.trunk |
| Keywords: | Cc: | Stefan Hoeche |
Description
Whenever I want to use Max_Epsilon parameter, with the lastest trunk version the generation of unweighted events chrashes with
Process_Group::OneEvent(): Cannot select any process.
Looks like the modified maxima are not properly accounted for, in fact the local sum of weights for all individual processes is indeed smaller than the global value Process_Integrator::SelectionWeight returns. If we want to make Max_Epsilon different to 1 by default this is a critical problem.
Attachments (0)
Change History (6)
comment:1 Changed 13 years ago by
| Version: | 1.2.3 → 0.trunk |
|---|
comment:2 Changed 13 years ago by
| Owner: | changed from support@sherpa-mc.de to Frank Siegert |
|---|
comment:3 Changed 13 years ago by
| Cc: | Stefan Hoeche added |
|---|---|
| Priority: | critical → blocker |
| Status: | new → assigned |
Yep, this originally comes from c16843 (on branches/enhance) where the event generation was unified for weighted/unweighted and above all the process selection was switched to use the maximum instead of the total xs. Problem was that the maxima of the group were not correctly updated after the single ones were reduced according to maxeps. This should be fixed on trunk in r17093. Steffen, could you test this, and Stefan, could you take a look whether that looks correct to you? Thanks.
comment:5 Changed 13 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Solution looks perfect to me.
r16858 still works fine, commit 16880 seems to be the critical one. FrankS is going to check this.