Opened 15 years ago
Closed 15 years ago
#331 closed defect (fixed)
LHEFiles init information incomplete
Reported by: | dwiesler | Owned by: | kilian |
---|---|---|---|
Priority: | P1 | Milestone: | v2.0.3 |
Component: | core | Version: | 2.0.2 |
Severity: | major | Keywords: | lhef event formats |
Cc: |
Description
Once again, there's something wrong w/ the LHEFiles. A simple 2->2,3,4 jet example such as
model = SM alias q = u:d:s alias Q = U:D:S alias j = u:d:s:U:D:S:g process jets2 = e1, E1 => j, j process jets3 = e1, E1 => j, j, g process jets4 = e1, E1 => j, j, g, g compile cuts = all Dist > 0.7 [j, j] and all Pt > 10 GeV [j] sqrts = 500 beams = e1, E1 integrate (jets2, jets3, jets4) n_events = 10000 $sample = "test" sample_format = lhef simulate (jets2, jets3, jets4)
produces an LHEF file which only contains two subprocesses in the init block
<init> 11 -11 250.00000000000000 250.00000000000000 -1 -1 -1 -1 3 2 1.4658333066084708 2.85396717780171281E-004 1.0000000000000000 1 0.94017830549578474 3.58998070524468643E-003 1.0000000000000000 2 </init>
instead of three as anticipated. I'll try to have a look into this...
Change History (3)
comment:1 Changed 15 years ago by
Priority: | P3 → P1 |
---|---|
Severity: | normal → major |
comment:2 Changed 15 years ago by
In r2604 I changed the heprup_init call in event_files.f90 to use the size of the process_id array instead of the current event_file_list type (only in my branch).
Works4me, to be confirmed before merging into trunk...
comment:3 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
r2605. The assignment of n_processes was garbage, it was effectively assigned to n_in (number of incoming particles).
Note: See
TracTickets for help on using
tickets.
This is a regression probably influencing all LHEF output files. Therefore should have highest priority.