Problem 211 - Linux results depend on optimisation
Summary: Linux results depend on optimisation
Status: CLOSED LATER
Alias: None
Product: Examples/Basic and Novice
Classification: Unclassified
Component: N02 (show other problems)
Version: 2.0
Hardware: PC Linux
: P2 normal
Assignee: John Apostolakis
URL:
Depends on:
Blocks:
 
Reported: 2001-01-30 07:57 CET by Steve.ONeale
Modified: 2007-04-08 18:47 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this problem.
Description Steve.ONeale 2001-01-30 07:57:28 CET
The tracking of the first track of Run 1 (the second run) is different
for the debug and optimised versions (only) on Linux since the
tag exampleN02-V02-00-00 (November 2000).
.
In the directory /afs/cern.ch/sw/geant4/stt/testlogs/logs accessible to
members of geant4 (zb:collaborators) the results of the system testing
of examples/novice/N02 diverged on Linux for the optimised and debug
code.

This was first seen for tagset 192 corresponding to the introduction of
./examples/novice/N02           exampleN02-V02-00-00
and
./source/geometry/magneticfield         field-V02-00-01
./source/geometry/management            geommng-V02-00-02
./source/materials              materials-V02-00-01
and has remained.

The file sizes are enough to show the results are different.
tkdiff is quite useful for comparing outputs.
.
274574 Nov 10 04:18 stt.geant4-02-00-cand-01+tags191/Linux-g++.debug/test102.out
274574 Nov 10 04:03 stt.geant4-02-00-cand-01+tags191/Linux-g++.optim/test102.out
266196 Nov 10 15:41 stt.geant4-02-00-cand-01+tags192/Linux-g++.debug/test102.out
393632 Nov 10 15:06 stt.geant4-02-00-cand-01+tags192/Linux-g++.optim/test102.out
Comment 1 Gabriele Cosmo 2004-05-06 11:44:59 CEST
It has been verified that output is perfectly reproducible on gcc-3.2 if one
associates chip's specific compilation options of the kind (for Pentium-4):
  -march=pentium4 -mfpmath=sse
which forces the usage of the SSE unit for scalar floating-point arithmetics
which is said to solve some numerical instability problems happening in the
default 387 floating-point coprocessor, where temporaries are handled in 80bit
precision.