Application of cuts to full process vs. hard process

[Juergen Reuter]

Generating one shower event, and then -- in a second run -- adding more shower events results in an endless loop. WHIZARD never terminates. Memory consumption seems stable, but could nevertheless be connected to #422.

[sschmidt]

I looked into this and the infinite loop is the

rejection: do
...
end do

loop in vamp_next_event_multi. From taking a look at the loop I would guess that it has something to do with (uninitialized) weights(?). Moreover I found that the infinte loop didn't occur in every run.

This has nothing to do with #422, by the way.

[Juergen Reuter]

JRR confirmed this, investigating right now...

[sschmidt]

Further information: The endless loop occurs becausue all events are vetoed by process_passes_cuts, although a call eval_tree_write(process%cut_expr) looks reasonable.

Moreover the endless loop doesn't appear when disabling hadronization(?).

[Juergen Reuter]

WHIZARD does apply the cuts to the full process, i.e. the showered, even the hadronized process. That is the reason while none of the showered events could pass my Delta R or pT cuts. Do we want to have a possibility to choose here?

[sschmidt]

So the problem arises from replacing WHIZARD's particle_set with a particle_set containing the showered event. The only way to avoid this problem, as I see it, is to introduce another particle_set in the event_t type. This particle_set can then be used for the showered/hadronized/... event while the other one is reserved for the matrix element/decays event. So the "correct" particle_set can be used when applying the cuts. Both sets would then be saved to and read from the evx file, while only the showered one (if it exists) would be saved to the output formats for the user.

[kilian]

@Sebastian or JRR: Could you provide an example here? I'm not that fluent in speaking shower yet ...

[kilian]

I still don't understand. I just set up an example with decays and shower. The order of application is:

• kinematics (partonic)
• cuts (on partons)
• matrix element (partonic)
• rejection/acception
• decay
• shower
• selection (on hadrons)
• analysis
• output (formatted)
• output (raw)

If the event is read from file, this is replaced by

• input (raw)
• selection
• analysis
• output (formatted)

This looks ok to me ...?

Neither did I get an endless loop, so I'd like to have the example.

[sschmidt]

Okay here is an example, run it with

../bin/whizard -e "n_events=10" ticket425.sin && ../bin/whizard -e "n_events=20" ticket425.sin

The first run will work as expected, the second will be in an endless loop when trying to generate the additional events.

It seems to be necessary that there is a light quark or gluon in the final state of the hard matrix element and that there is a cut for the infrared/soft singularity for this quark or gluon (and probably with a very high cutoff, e.g. E>100 GeV in the example). As during the shower more low energy gluons or quarks are produced, the showered event probably doesn't satisfy the matrix element cuts. However it seems to me, that when WHIZARD is generating more events, it somehow applies the ME cuts to the showered events and is therefore stuck in an endless loop.

[kilian]

Thanks. Still, I don't see that the ME cuts could be applied to the showered events in any way. But I will dig through the example, there is likely _some_ bug.

[kilian]

I did reproduce the endless loop --

strange thing is that it doesn't occur with pdf_builtin, only with lhapdf.

[kilian]

Interesting bug.

The subevt in the process object is used both for cuts and analysis. For generated events, it contains the partonic events. When read from file, it contains the hadronic events. The problem is that when appending extra events, it was not re-initialized to the partonic events. Therefore the cuts were applied to bogus particles from the last event read, which never changed => endless loop.

I fixed the immediate problem in r3618. However, there remains the problem of inconsistent input for the internal analysis. I transfer this to a new ticket #444.