#246 closed defect (invalid)
combine leads to unpredictable behaviour if the referenced particles don't exist
Reported by: | sschmidt | Owned by: | kilian |
---|---|---|---|
Priority: | P3 | Milestone: | |
Component: | core | Version: | 2.0.0rc3 |
Severity: | normal | Keywords: | |
Cc: |
Description
When having a cut that uses a combine statement that references a particle that is not existing in the corresponding process, the results of the cuts are unpredictable (for me), either the cut has no effect at all or the crosssection is reduced to zero.
E.g. having the process
process eebbuuss = e1, E1 -> u, U, b, B, s, S
and a cut like
all (M < 70 GeV or M > 90 GeV) [combine[t, U]]
Maybe there should be a warning or the cut should have no effect at all? Because combining particles that don't exist doesn't make sense to me.
Attachments (1)
Change History (4)
Changed 15 years ago by
Attachment: | ticket246.sin added |
---|
comment:1 Changed 15 years ago by
Status: | new → assigned |
---|
To me, the behavior looks reasonable.
The question is, what do the operators 'all' and 'any' when operating on an empty particle list. To me, it appears most sensible that
- all returns true
- any returns false
in this case. Obviously, 'not all' and 'not any' return the opposite. On the other hand 'all not' returns the same result as 'all' since the list is empty in both cases.
I wanted to NOT issue warnings in such cases, since it is useful to have a set of default cuts that can be applied to any process without problems or warnings. Think of 'all' as a cut condition and 'any' as a trigger condition.
Any other suggestion? I would consider the ticket as invalid, but it's of course my task to document this properly.
comment:2 Changed 15 years ago by
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Since nobody has complained, I close the ticket (see above).
extensive example file