Wrong entries in LHEF files

[Juergen Reuter]

Thanks to Daniel W. for reporting this problem. Looking into the LHEF file from e.g. the qedtest.sin example shows that the flavours of the initial state particles are 0, not given by their PDF codes. Adding the lines

?write_lhef = true 
$file_lhef = "drell_yan.lhef"

in the lhapdf.sin input file in front of the last simulate yields events with 8 particles instead of 4, with some beam remants in the event. Is this intended? Here is an example:

 <LesHouchesEvents version="1.0">
 <header>
   <generator_name>WHIZARD</generator_name>
   <generator_version>2.0.0_rc1</generator_version>
 </header>
 <init>
        2212        2212   500.00000000000000        500.00000000000000               -1          -1          -1          -1           3           1
   0.0000000000000000        0.0000000000000000        1.0000000000000000                1
 </init>
 <event>
           8           1   1.0000000000000000        223.13485917541837       -1.0000000000000000       0.11780000000000000     
           0          -1           0           0           0           0   0.0000000000000000        0.0000000000000000        500.00000000000000        500.00000000000000        0.0000000000000000        0.0000000000000000        9.0000000000000000     
           0          -1           0           0           0           0   0.0000000000000000        0.0000000000000000       -500.00000000000000        500.00000000000000        0.0000000000000000        0.0000000000000000        9.0000000000000000     
           0           0           0           0           0           0   0.0000000000000000        0.0000000000000000        84.358998813033693        84.358998813033693        0.0000000000000000        0.0000000000000000        9.0000000000000000     
           0           0           0           0           0           0   0.0000000000000000        0.0000000000000000       -147.55143517522762        147.55143517522762        0.0000000000000000        0.0000000000000000        9.0000000000000000     
         -92           1           0           0           0           0   0.0000000000000000        0.0000000000000000        415.64100118696626        415.64100118696626        0.0000000000000000        0.0000000000000000        9.0000000000000000     
          92           1           0           0           0           0   0.0000000000000000        0.0000000000000000       -352.44856482477240        352.44856482477240        0.0000000000000000        0.0000000000000000        9.0000000000000000     
          13           1           3           4           0           0   82.809523591046400        59.832219841918068        14.999658371775745        103.25847492362472       0.10565838899979969        0.0000000000000000        9.0000000000000000     
         -13           1           3           4           0           0  -82.809523591046400       -59.832219841918068       -78.192094733969668        128.65195906463663       0.10565838899979969        0.0000000000000000        9.0000000000000000     
 </event>
 <event>
           8           1   1.0000000000000000        255.88100275682038       -1.0000000000000000       0.11780000000000000     
           0          -1           0           0           0           0   0.0000000000000000        0.0000000000000000        500.00000000000000        500.00000000000000        0.0000000000000000        0.0000000000000000        9.0000000000000000     
           0          -1           0           0           0           0   0.0000000000000000        0.0000000000000000       -500.00000000000000        500.00000000000000        0.0000000000000000        0.0000000000000000        9.0000000000000000     
           0           0           0           0           0           0   0.0000000000000000        0.0000000000000000        214.23557777021864        214.23557777021864        0.0000000000000000        0.0000000000000000        9.0000000000000000     
           0           0           0           0           0           0   0.0000000000000000        0.0000000000000000       -76.405478788007514        76.405478788007514        0.0000000000000000        0.0000000000000000        9.0000000000000000     
         -92           1           0           0           0           0   0.0000000000000000        0.0000000000000000        285.76442222978136        285.76442222978136        0.0000000000000000        0.0000000000000000        9.0000000000000000     
          92           1           0           0           0           0   0.0000000000000000        0.0000000000000000       -423.59452121199246        423.59452121199246        0.0000000000000000        0.0000000000000000        9.0000000000000000     
          13           1           3           4           0           0   117.86973520315571        48.779501094229317        80.046704770898032        150.59946982721564       0.10565838896536818        0.0000000000000000        9.0000000000000000     
         -13           1           3           4           0           0  -117.86973520315571       -48.779501094229317        57.783394211313066        140.04158673101048       0.10565838896536818        0.0000000000000000        9.0000000000000000     
 </event>

[Juergen Reuter]

This is important and should better be done in rc2.

[Juergen Reuter]

This is important for users, and should be clarified.

[Juergen Reuter]

In r1735, colour flows for the particles have been added as well as the cross sections and their MC errors for the corresponding subprocesses in the header. What is still missing is the flavour information for the initial state.

[Juergen Reuter]

I tracked this down to the fact that the corresponding state_matrix_density does not contain the proper flavour information (for the incoming particles) which I actually don't understand. Trying to find out where it goes nuts.

[kilian]

Sorry for the confusion, this is not a bug but a feature ...

But it confuses the user. Even though the state matrix doesn't contain flavor info (on purpose), we might insert it in the LHEF record, or change the default behavior which is effected by the quantum-numbers mask applied on the intermediate states.

[Juergen Reuter]

Please do so. It costed me again one more night to understand what function is calling what... Right now, WHIZARD does not write proper LHEF event formats!!! This HAS to be in. Please, do so!

[Juergen Reuter]

On the other hand, beam remnants should NOT appear in those files. They are only for internal use.

[Juergen Reuter]

My comment to that:

beam remnants in the event file should a (non-standard) option for the user, the default should be without them. Partonic initial state flavours have to be assigned. Furthermore, we should think of implementing the option for resonances in the process, particles with the status code +2 in the LHE format (cf. MadEvent? event files). With the WHIZARD phase space info at hand, that should be feasible.

[kilian]

The resonances are already implemented (applies only to cascade decays). For the other comments, I agree. WK

[Juergen Reuter]

Ok, now I see the following in the LHEF file: a proton (?) with PDG 22 (which is non-existent), protons that carry color flow, the beam remnants are still in, and the resonances are missing. Just to summarize the status right now.

[kilian]

@JR: I didn't say that this is finished, otherwise I would have closed the ticket.

PDG=22 is a resolved photon for which lhapdf.sin applies the LHAPDF structure function, this is intended. I know about the spurious color lines.

[kilian]

r1760: the status codes are now ok. TODO:

• check color lines for beams (looks ok now, miraculously)
• suppress virtual particles, if any (LHEF has no comment entries)
• suppress beam remnants (special status code?)
• activate missing mother/daughter relations for beams

[kilian]

LHEF entries appear to be ok now [1767]. Closing the ticket.

[Juergen Reuter]

The color flows are still not correct. Daniel found out that everything is OK for Drell-Yan, if the partons in the initial state are qbar,q but for q,qbar there are "diagonal" color flow gluons in the event like 501/501 for col/acl.

[Juergen Reuter]

Furthermore, the protons (i.e. beam particles) should be taken out of the events, as they contain no further info, but they screw up the mother/daughter relations of the particles in the event.

[kilian]

there are "diagonal" color flow gluons in the event like 501/501 for col/acl

??? could you give an example (.sin)?

Furthermore, the protons (i.e. beam particles) should be taken out of the events, as they contain no further info, but they screw up the mother/daughter relations of the particles in the event.

The standard explicitly allows the beams in the event. The relations should be consistent with this. Of course, we could omit them. In the ILC case they will be needed (crossing angle etc.)

[sschmidt]

example input file for diagonal color flows

[sschmidt]

by Daniel:

example sin file added. If executing the sin file, the .lhef file contains events of the form

 <event>
           5           1   1.0000000000000000        48.516224385237180       -1.0000000000000000       0.11780000000000000
           2          -1           0           0         501           0   0.0000000000000000        0.0000000000000000        458.98831171806216        458.98831171
806216        0.0000000000000000        0.0000000000000000        9.0000000000000000
          -2          -1           0           0           0         502   0.0000000000000000        0.0000000000000000       -1.2820718787957428        1.2820718787
957428        0.0000000000000000        0.0000000000000000        9.0000000000000000
          13           1           1           2           0           0   7.5166235424375394       -19.615900231615694        246.63855398871806        247.53155485
456071       0.10565838905847451        0.0000000000000000        9.0000000000000000
         -13           1           1           2           0           0  -12.301536471788300        10.618316941065240        117.67901510535302        118.79578365
450826       0.10565838904976996        0.0000000000000000        9.0000000000000000
          21           1           1           2         502         502   4.7849129293507602        8.9975832905504536        93.388670745195284        93.943045087
788974      -1.51200901197979717E-006   0.0000000000000000        9.0000000000000000
 </event>
 <event>
           5           2   1.0000000000000000        113.24555861420640       -1.0000000000000000       0.11780000000000000
          -2          -1           0           0           0         501   0.0000000000000000        0.0000000000000000        141.24788562752317        141.24788562
752317        0.0000000000000000        0.0000000000000000        9.0000000000000000
           2          -1           0           0         502           0   0.0000000000000000        0.0000000000000000       -22.698669946222363        22.698669946
222363        0.0000000000000000        0.0000000000000000        9.0000000000000000
          13           1           1           2           0           0   38.773812272327639       -16.340350846170992        42.065574763646978        59.497389251
939509       0.10565838900450188        0.0000000000000000        9.0000000000000000
         -13           1           1           2           0           0  -48.269206937601027        13.162000389325796        79.551409277201884        93.976552790
138086       0.10565838899525619        0.0000000000000000        9.0000000000000000
          21           1           1           2         502         501   9.4953946652733840        3.1783504568451963       -3.0677683595480540        10.472613531
667935      -3.48399298307343222E-007   0.0000000000000000        9.0000000000000000
 </event>

so depending on the order of the quarks in the initial state in one case the color indices are correct in the other they aren't.

[sschmidt]

just another example of incorrect color connections:

process proc = g, t -> A, t
compile
sqrts = 7 TeV
beams = g, t
integrate (proc) { iterations = 1:1000 }

?write_lhef = true
$file_lhef = "proc.lhef"

simulate (proc) { n_events = 10 }

gives entries in the .lhef file like

 <event>
           4           1   1.0000000000000000        7000.0000000000000       -1.0000000000000000       0.11780000000000000
          21          -1           0           0         501         502   0.0000000000000000        0.0000000000000000        3497.8597421428572        3497.8597421428572        0.0000000000000000
0.0000000000000000        9.0000000000000000
           6          -1           0           0         502           0   0.0000000000000000        0.0000000000000000       -3497.8597421428572        3502.1402578571428        173.09999999999940
0.0000000000000000        9.0000000000000000
          22           1           1           2           0           0  -885.59085250802150        568.29041247082284       -3335.8353713502638        3497.8597421428572       2.11104809009348435E-005
0.0000000000000000        9.0000000000000000
           6           1           1           2         502           0   885.59085250802150       -568.29041247082284        3335.8353713502638        3502.1402578571428        173.10000000000068
0.0000000000000000        9.0000000000000000
 </event>

so the top has the wrong color connection in the final state. Exchanging g and t in the initial state leads to correct color connections in the final state though.

[kilian]

found the problem, fix follows later today

[sschmidt]

just another check: u u -> u u
About half of the events have the wrong color connections: both final quarks have the same color index.

.sin file:

process proc = u, u -> u, u
compile
sqrts = 7 TeV
beams = p, p -> lhapdf

cuts = all Pt > 10 GeV[u]

integrate (proc) { iterations = 1:1000 }

?write_lhef = true
$file_lhef = "proc.lhef"

simulate (proc) { n_events = 10 }

[kilian]

Solved in r1940. The function color_translate worked iteratively on the color array, sometimes translating colors twice. Introducing a temporary resolves the problem.

[Juergen Reuter]

Milestone v2.0-rc3 deleted