whizard is hosted by Hepforge, IPPP Durham

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#737 closed defect (fixed)

Understand PYTHIA numerics inside WHIZARD

Reported by: Juergen Reuter Owned by: kilian
Priority: P0 Milestone: v2.2.7
Component: core Version: 2.2.6
Severity: normal Keywords:
Cc:

Description

For real corrections, momenta are not set for real corrections, decay errors are not working and PYTHIA output is not working wuth ifort 16 beta v2.

Change History (7)

comment:1 Changed 9 years ago by Juergen Reuter

Problem is that the [Real] term in smtest_16 has a NaN momentum, and the point where this is set is nowhere to be found.

comment:2 Changed 9 years ago by Juergen Reuter

In r7118, all open issues with smtest_16 are solved, and we are down to 6 failing functional tests.

comment:3 Changed 9 years ago by Juergen Reuter

With r7119, also decay_err_2 is working, another allocate-on-assignment.

comment:4 Changed 9 years ago by Juergen Reuter

The five functional tests that are not working are pythia6_{1,2,3,4} and mlm_matching_pythia6.The reason is the output from PYTHIA6 which doesn't agree with what comes out with the gfortran and NAG compilers. Of course, the exact number of shower particles and their momenta is not infrared-safe and does depend crucially on the numerics, but nevertheless this is a surprise. JRR checked that the random numbers given to PYTHIA are identical (calculated by the floor function from a WHIZARD random number), and at a first glance also the LHE file that goes into PYTHIA seems the same. So the worst case is that PYTHIA internally does something different with the Intel compiler. JRR tries to find out what. Any comment or help is highly welcome.

comment:5 Changed 9 years ago by Juergen Reuter

Summary: Real corrections, decay errors and PYTHIA broken with ifortUnderstand PYTHIA numerics inside WHIZARD

Now, the topic here is to understand the numerics of PYTHIA inside WHIZARD: do the differences with the gfortran/NAG vs. ifort come from a non-portability of the random number generator, or small numerical differences in the shower evolution that get blown up?

comment:6 Changed 9 years ago by Juergen Reuter

Resolution: fixed
Status: newclosed

All the tests (unit and functional ones) are working now. Besides the issues with the allocate-on-assignment, the missing things in PYTHIA is a rather weird behavior of gfortran: if there is a condition depending on a random number, cond(rand), then in an if-clause if (cond1. and. cond(rand)) then in case that cond1 does not evaluate to .true., cond(rand) is not evaluated, and hence no random number called. This hiccuped the random number sequence compared to the ones in the ifort code. Workaround in the PYTHIA code. BACN's extended shower tests are partially working, ext_shower_1, ext_shower_2, ext_shower_3_bb. Curious what the others will do. Closing this for now.

comment:7 in reply to:  6 Changed 9 years ago by kilian

Replying to jr_reuter:

[...] is a rather weird behavior of gfortran: if there is a condition depending on a random number, cond(rand), then in an if-clause if (cond1. and. cond(rand)) then in case that cond1 does not evaluate to .true., cond(rand) is not evaluated, and hence no random number called. This hiccuped the random number sequence compared to the ones in the ifort code. Workaround in the PYTHIA code.

NB: If this description is correct, than this is undefined behavior, i.e., a bug in the code. The result must not depend on the fact whether the second condition is evaluated, the compiler is free to evaluate it (or not).

Note: See TracTickets for help on using tickets.