The densities tabulated in file HFCHARGE.DAT were not properly extrapolated to r=0. Hence the treatment of atom-ion collisions in the Hartee-Fock potential broke down for very small impact parameters and lead to unphysical results such as negative kinetic energies.
For ion-atom collosions with impact parameter larger than about 0.01 angstrom the impact of this bug is negligible.
solved in flux7.9.6
The screening radius was calculated incorrectly as BB=3.3E-5*Z1*Z2*(Z1**(2/3)+Z2**(2/3))**0.5
However in Fortran the integer division (2/3) is evaluated as 0!
solved in flux7.9.6
Some parts of 3D-plots were omitted, for some software systems
solved in flux7.9.6
RBSIM did not process flux files from multilayer samples correctly
solved in flux7.9.0
Line 159 in prelimi.f was not correct for lattice configuration from COMBI4.FIG These are the more exotic non-cubic crystals such as GaN2113. The effect of the error was to overestimate the effect of the surrounding strings by a large factor ( in one case 16 ). The error also shows up by an overestimate of the critical angle ( by a factor of 4 in the same case ).
The error does not occur with lattice configurations from COMBIN.FIG
solved in flux7.8.6
Thanks to Andres Redondo for reporting this problem
In the following '$FLUX' is the directory FLUX7 of the flux7 directory tree.
In file $FLUX/FLUXLIB/dvtm.f remove the line (line 23) that reads
write(6,*)'dvtm: call romberg',XSI0,XSI1,ZZD,U2A,RHOA,XUNA
This line is left over from some test (probably around the year 1999) and may cause excessive amounts of useless output in some cases.
solved in flux7.8
The label of a lattice type must be < 10000 (4 digits). The lattice types for SiC were mistakenly labeled '60001', which has one digit too many.
Remedy: change '60001' to '6001', in file $FLUX/TAB/COMBIN.FIG (2 times) and in $FLUX/flux7.f (3 times).
solved in flux7.8
The problem seems to happen only with output of some compilers.
solved in flux7.8
Program show does not always calculate the average over different atom species of the yield and other quantities when the user expects it to do so. Specifically when 'SPECTRUM all' and 'ATOM SPECIES average' are selected averaging only took place for the first spectrum! (after that atom species 1 was used).
solved in flux7.8
In the file $FLUX/makedefs.linux cpu-type is set to pentium4. This is of course no good if your processor is other then Pentium4.
The choices for cpu-type are i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp and athlon-mp.
Edit file makedefs.linux accordingly. It is worth the while to use this directive (it speeds up the flux calculation by about 10%, but if not sure about the cpu, leave it out altogether
In version flux7.72.1 it is assumed the user defines an environment variable with name FLUX and value the top directory of the flux7 directory tree (see above). However in the script $FLUX/BIN/makeflx a variable named FLUX was already defined.
Remedy: change 'FLUX' to 'FLUXPROG'in file $FLUX/BIN/makeflx (4 times)
solved in flux7.8
in directory $FLUX: make clean makemake make
Feb. 2001, corrected in flux7.71
I have recently come across a bug in program flux that has lived a hidden live for about 10 years. It is already present in version flux3, and in versions derived by Luis Rebouta (Flux4) and Ulrich Wahl. In the erroneous versions there appear, in subroutine FFIELD, the following lines
DO 30 JY=1,NFY
YJ = ( FLOAT(JY) - 0.5 ) / FLOAT(NF)
DO 20 JX=1,NFX
JXJY=JXJY+1
XJ = ( FLOAT(JX) - 0.5 ) / FLOAT(NF)
This should be:
DO 30 JY=1,NFY
YJ = ( FLOAT(JY) - 0.5 ) / FLOAT(NFY)
DO 20 JX=1,NFX
JXJY=JXJY+1
XJ = ( FLOAT(JX) - 0.5 ) / FLOAT(NFX)
i.e. the FLOAT(NF) should be changed to FLOAT(NFY) and FLOAT(NFX), respectively.
The impact of this is, that the correction due to the force field of surrounding strings, is completely bogus. I therefore urge you to make the change indicated above in all versions of flux that you might use, or, better still, upgrade to the latest version of flux.
In the original flux1 collisons with atoms of only one row were treated as binary collisions, while the surrounding atom rows were treated in the continuum string approximation.
In flux3, and later versions, the binary collision treatment is extended to several rows. This strongly diminishes the effect of the surrounding rows, which now, as a rule, are more than 2 angstroms away from the ion path. Only because this effect is so small, the fact that it was wrongly evaluated could go unnoticed for so many years! In a few tests cases, checked by Louis Selen and me, we did not notice any significant influence on the simulation results. Thus it may not be necessary to retract all scientific papers where flux was used! However, please do make a few checks, whenever possible.
Versions of RBSIM prior to 7.71 (February 2001) contain a bug that causes an error in the depth - energy relation on the ingoing path. At a certain depth the error in the energy is of the order of the energy straggling.
Some versions contain a bug that causes the energy loss to be divided by 2 in certain cases, i.e. when a monoatomic crystal, such as Si, is modelled by a diatomic lattice, such as GaAs. This bug was 'introduced' probably around 1997 and eliminated in version 7.7.
Please do check previous results whenever possible.