whizard is hosted by Hepforge, IPPP Durham

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#441 closed defect (fixed)

StdHEP files corrupt when PYTHIA shower/hadronization active

Reported by: kilian Owned by: kilian
Priority: P1 Milestone: v2.0.6
Component: core Version: 2.0.5
Severity: major Keywords:
Cc:

Description

Reported by Jan Strube.

For easier debugging, there are now (r3606) the formats hepevt_verbose and lha_verbose which print out a readable form of the common blocks, as they are used by StdHEP.

Change History (8)

comment:1 Changed 12 years ago by kilian

This should be checked now since #442 is solved.

comment:2 Changed 12 years ago by Juergen Reuter

Priority: P2P1

comment:3 Changed 12 years ago by sschmidt

Resolution: fixed
Status: newclosed

apart from some duplicates in the output solved in r3628.

comment:4 Changed 12 years ago by Juergen Reuter

Resolution: fixed
Severity: normalmajor
Status: closedreopened

Sry, but this duplicate issue has to be resolved, and it MUST be until tomorrow. Otherwise there will be no more release this year....

comment:5 Changed 12 years ago by Juergen Reuter

Owner: changed from sschmidt to kilian
Status: reopenednew

comment:6 Changed 12 years ago by sschmidt

Most of the duplicates are now (r3632) removed. The only remaining source for duplicates is as follows: if one set of parents is distributed over the particle set with some but not all parents at the end, particle_set_to_hepevt_form will append the complete set of parents although it is unnecessary to add duplicates for the partons that were already at the end of the particle set. This happens in hadronic collisions with showering enabled, there the final state partons from the matrix element are duplicated. Any opinions if this is a flaw that should be fixed? This could be solved by only adding partons that are inside the particle set or by adding a check searching for these duplicates at the end of particle_set_to_hepevt_form.

comment:7 Changed 12 years ago by kilian

Resolution: fixed
Status: newclosed

I would keep it as it is now, if it communicates with the external software as intended. The rearrangement algorithm should be kept as simple as possible.

Now, beam particles are _always_ included. It appears that

  • no problem for HEPEVT since these are just 'decayed' entries
  • PYTHIA accepts it in HEPEUP. I now remember that I removed the beams from the event record because PYTHIA 6.2 explictly disallowed them. Has probably been fixed in later PYTHIA versions
  • beam entries are expected in HepMC

Another last-minute change: virtual particles are ISTUP=3 now, as they should be.

BTW: In the PYTHIA(6.2) manual I also read that in the ISR shower backward evolution, PYTHIA generates daughter entries that are not contiguous.

So, I close the ticket.

comment:8 in reply to:  7 Changed 12 years ago by sschmidt

Replying to kilian:

  • PYTHIA accepts it in HEPEUP. I now remember that I removed the beams from the event record because PYTHIA 6.2 explictly disallowed them. Has probably been fixed in later PYTHIA versions

PYTHIA still expects the first two particles in HEPEUP to be the incoming particles of the hard-scattering process and not the protons. Therefore I had to introduce a

call particle_set_reduce(particle_set, pset_reduced) 
call particle_set_fill_hepeup(pset_reduced) 
call hepeup_set_event_parameters(proc_id=1) 

in the PYTHIA interface to remove the beam particles and the beam-remnants, so that the incoming particles of the hard-scattering are the incoming particles in the HEPEUP COMMON BLOCK.

Note: See TracTickets for help on using tickets.