Zero cross section

[ohl]

At some time between r3966 and r3979, the process gl, gl => t, B, d, U lost all its cross section:

model = SM
process leptons = gl, gl => t, B, e1, N1
process jets = gl, gl => t, B, d, U
process boson = gl, gl => t, B, Wm
compile
sqrts = 1 TeV
beams = gl, gl
integrate (leptons, jets, boson) { iterations = 2:1000 }

that's when WK merges CS's code (found by Fabian)

[Juergen Reuter]

Confirmed, I have some suspicion, but no strong opinion yet. May you live in interesting times? Sometimes a bit more quietude would be great!

[Juergen Reuter]

One first observation, but a minor point, the process name in a print line is missing: r3966:

| Initializating integration for process leptons:

r3979:

| Initializating integration for process :

[Juergen Reuter]

My suspicion seems to have been undermined, and the culprit seems to be indeed CS! It looks like the helicity selection rules. The reason why the process "leptons" is non-zero and the process "jets" is zero, is that the electron is massive while d and ubar are both massless. Setting me = 0 results also in a zero cross section for the process "leptons". However, switching off the helicity selection rules does not help. Strange. CS, what did you do???

[Juergen Reuter]

It seems not to be the helicity selection is NOT the culprit, but many things in processes.f90 went berserk. Sometimes I don't understand the changes by CS.

[Juergen Reuter]

When using process_write to debug, there is something wrong with the interaction_write statement on the structure functions. Secondly, the phase space forest initialization seems to not have been worked properly.

[Juergen Reuter]

I am tempted to say that this is connected to #468: if WK will rework that part of the code (processes and/or integrations) we will find it (hopefully) :(

[Juergen Reuter]

Whatever that is we should definitely add it as a unit test. Going home now.

[Juergen Reuter]

its process_compute_vamp_phs_factor, the weights seem ok, so it's probably the grids.....

[Christian Speckner]

I can't reproduce the problem in my whizard_nlo branch, so if it is indeed connected to the NLO code, I suspect that bug was introduced or exposed during the merge.

[Juergen Reuter]

OMG, this means we have to go through the code line by line ... viel Spass

[Juergen Reuter]

Thanks for the tip, CS, anyhow. So it seems to be an incompatibility with the changes in the trunk from the point who forked your branch to the nlo setup.

[Juergen Reuter]

Before you edit this, WK, I'm investigating this at the moment :) (after I made a Brathuhn with Asian vegetables)

[kilian]

Could be. In any case, the quick hacks that incorporated CS's branch in the trunk are not going to stay. The process component and library handler are being rewritten, essentially from scratch. So, we should check this as a test case once the program is up and running again, but right now it's pointless.

(If you just found the problem, go ahead, but otherwise don't worry.)

[Juergen Reuter]

Well, that's what I said in comment #7

[Juergen Reuter]

I found the culprit, it's ?phs_step_mapping flag. If you set this to false the zero cross sections work again. But I don't understand yet why it causes a problem from 3979 (the merge) on.

[Juergen Reuter]

Mysterious: the phs_tree for 3966 and 3979 is the same, but in version the problem is there, in the other it isn't. :(

 exp_type     =  F
 variable_lim =  F
 External: 6     Mask: 63
 Incoming: 2     Mask: 48
 Branches: 9
    32
    16
 *  15         Daughters:    2   13   +  (axis +)
 *  13         Daughters:    1   12   +  (axis +)
 *  12         Daughters:    4    8   +  (axis +)
     8
     4
     2
     1
 Branch #  12:  Mapping (s_channel) for particle "W+"
   m/w    =    80.418999999999997        2.0489999999999999     
   a1/2/3 =    0.0000000000000000        0.0000000000000000        0.0000000000000000     
 Arrays: mass_sum, effective_mass, effective_width
              1   173.09999999999999        173.09999999999999        0.0000000000000000     
              2   4.2000000000000002        4.2000000000000002        0.0000000000000000     
              4   0.0000000000000000        0.0000000000000000        0.0000000000000000     
              8   0.0000000000000000        0.0000000000000000        0.0000000000000000     
             12   0.0000000000000000        80.418999999999997        2.0489999999999999     
             13   173.09999999999999        253.51900000000001        2.0489999999999999     
             15   177.29999999999998        257.71899999999999        2.0489999999999999

[Juergen Reuter]

Actually, there is a big difference, the phs_tree of the r3979 version is twice as big as the one from r3966! Now, I have to trace it back.

[Juergen Reuter]

The step_mappings have not been present in the nlo_lab_tagged version. Somehow that seems to cause the problem now.

[Juergen Reuter]

There is twice a call to phs_forest_set_parameters, one filling the forest subtype of process, one the forest subtype of process%kinematic_configuration_in. For this second call there appears to be an unknown particle in the tree:

 Branch #  12:  Mapping (step_hyp ) for particle "?"
   m/w    =    0.0000000000000000        0.0000000000000000     
   a1/2/3 =    0.0000000000000000        0.0000000000000000        0.0000000000000000 

but I don't know whether this causes the problem.

[Juergen Reuter]

Some more info: the problem only appears if both the two variables

?phs_step_mapping 

and

?phs_keep_resonant

are true. If either of those is set false.

[Juergen Reuter]

it works.

[Juergen Reuter]

I think this is all I can contribute. WK, could you comment on this, how shall we proceed?

[Juergen Reuter]

Once, processes are integrable again and PHS (incl. step function mapping, which I have in suspicion) are back, I will run this. I expect it to go away then, but let's see. Depending on #468.

[Juergen Reuter]

I will do these checks as soon as ticket #534 has been closed.

[Juergen Reuter]

As of now (r5206) this SINDARIN file runs completely ok. I guess it was a bogus of the merge of CS's code with the actual trunk. Closing.