Message: Re: Irreproducible results Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: Irreproducible results 

Forum: Multithreading
Re: Question Irreproducible results (Tom Roberts)
Date: 27 Feb, 2015
From: Tom Roberts <Tom Roberts>

I have discovered that the problem is DATA DEPENDENT. This is very strange.

With my StepLimiter set to the usual 100mm, about 10% of events have compare errors; with it set to 1mm only 0.2% of events have compare errors. Here a compare error means that at least one step of the event had different values of {x,y,z,t,KE} when comparing the MPI and the non-MPI runs.

If I generate all tracks parallel to the Z axis, there are no compare errors with either StepLimiter. But not being parallel to Z does not mean a track will get a compare error, and most of them don't.

In all cases, if an event gets any compare errors, the first one always comes in the very first step inside the LH2; all following steps have compare errors (no surprise). That is, initial steps in Vacuum never get compare errors (consistent with no compare errors at all if the LH2 is replaced by Vacuum).

    (This makes me suspect the problem is related somehow to per-track
     process initialization.)

If the primary track has a compare error, all secondaries do also (no surprise as the secondaries are created after the first compare error of the primary). If the primary has no compare errors, neither do any of its secondaries.

For all events, the printed values of RandGauss::shoot() from BeginOfEventAction() and from EndOfEventAction() compare equal, regardless of whether the event's track steps have compare errors.

    (This makes me think the two runs use the same sequence of random
     numbers for each event, unless some Geant4 Process uses some other
     random number generator, or some distribution other than RandGauss
     that needs to be reset -- but if this were the case, why doesn't
     every event have compare errors?)

What plausible mechanism is there that makes the likelihood of generating a compare error be proportional to the step length in the LH2, and yet if it happens at all in an event it happens in the very first step in the LH2?

    (Remember the two runs being compared use the same executable file.)

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Ok: Re: SOLVED Irreproducible results   (Tom Roberts - 28 Feb, 2015)
(_ Note: Re: SOLVED Irreproducible results   (Andrea Dotti - 28 Feb, 2015)
 Add Message Add Message
to: "Re: Irreproducible results"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews