Frequently asked questions about flux and related programs.
Please submit further questions, and answers, to p.j.m.smulders@home.nl
1. The program assumes by default a constant stopping cross section i.e. the energy dependence of the stopping power is neglected. If this approximation is not acceptable, see "energy dependent energy loss" in flux7 and "ENERGY DEPENDENT STOPPING" in input
2. The program is not capable of simulating double alignment. Only the incoming or only the outgoing trajectories are considered.
3. The program assumes a perfect single crystal, or, a domain structure with perfectly crystalline domains. There is an option for a structure with random vacancies, or a mixed structure with several kinds of atoms occupying similar sites ( Ge_x Si_(1-x) ). So far, I have not incorporated other structural imperfections in the host lattice. One possible approach is to give the ion 'random' displacements in the xy plane (thus simulating random displacements of the host atoms). This would work if you have sensible assumptions for the spatial distribution of such displacements.
4. If you have different versions of flux7 on your system it is important that environment variables FLUX and PATH point to the version you want to use! Give command "which flux7" to check.
Read through the installation instructions "INSTALLATION" in install
Start up a terminal window and go to directory $FLUX. If your system is Linux of Mingw64 you can just give the command "makemake" without argument, otherwise give "makemake <makedefsfile>.
You may have to prepare your own makedefs file. The idea is to put machine-dependent features in here. This should be a variation on the ones present. In directory $FLUX you will find makedefs files for Linux and for MinGW64:. Some obsolete versions are in directory "archive". A few things that might need attention:
FC = gfortran
CC = gcc
Insert here the compiler commands to be used
RANLIB = touchIf your system requires command 'ranlib' to create an archive symbol table after using command ar, this line should be changed to read "RANLIB = ranlib". Most Unices don't require this anymore. Maybe "man ar" will tell you.
XLIB = -lX11
This equation specifies the X11 library. If the above fails, check for
XLIB = /usr/lib/libX11.a or
XLIB = /usr/lib/libX11.so
Try command
find /usr -name "libX11.*"
to get possible choices.
SYSTIMSRC=systim.f
Another option is suntim.f
Look in directory FLUXLIB at file systim.f and suntim.f and
at the documentation of your Fortran to see what works.
If you change this line, change the next one
SYSTIMOBJ=systim.o
accordingly.If all else fails:
Try
'make -i -k'
(this causes errors to be ignored) and see how far you getYou should be able to get flux7 itself, as well as fluxchk to run since they don't depend on pgplot.
Unsupported compiler flags. For example the flag "-fforce-mem" is not supported in some versions of gcc. Solution: edit the makedefs file (not the Makefile!) and rerun makemake
LFOPEN error ... STATUS=OLD, IOSTAT=2
For gcc-g77 this is equivalent to "file not found". A possible reason may be that the environmental variable FLUX was not defined or has the wrong value, or $FLUX/BIN was not added to the PATH variable. See "PATH variable" in install
Carefully read the pgplot documentation about installation in Unix. It is necessary to do the actual build in the target directory e.g. $HOME/PGPLOT, different from the directory where the pgplot tar file was unpacked. Go to this directory, and do the configuring and 'make'ing while in this directory.
You should keep in the directory PGPLOT_DIR at least the files
grfont.dat
libpgplot.a
pgxwin_server
rgb.txt
after cleaning up, and it is wise to also keep
drivers.list
makefileFurthermore you have to define a few environment variables:
PGPLOT_DEV=/xwin
PGPLOT_DIR=$HOME/PGPLOT
PGPLOT_BACKGROUND=white
PGPLOT_FOREGROUND=black
PGPLOT_XW_WIDTH=0.6for things to work smoothly.
There are provisions in FLUX for taking the PIXE or NRA cross sections into account. All that is required is a table of cross section versus bombarding energy. An example, for 18O(p,alpha) in silver, is present in directory FLUX6/INPUT/AG of the files I sent you. (This was published in Segeth et. al. Phys. Rev. B39 (1989) 10725).
The vibration amplitude influences the depth, and to a lesser extent the width of the dip. The value to be used for PIXE, should be the quadratic sum of the vibration amplitude and the effective inner shell radius. (See Comedi, Kalish and Barrett NIM-B 63(1992) 451 and my article NIM-B 94 (1994) 595). In FLUX you can specify the vibrational amplitude indirectly via the Debye temperature, but also directly by given minus its value in angstrom, instead, of the Debye temperature.
What are the 'ANGLES' (theta and phi) in the input file? How do I change the tilt angle with respect to planes in which the beam is channeled ?
> NLAYER
> 2
>
> LATTICE
> GAAS110
[ ... ]
> ANGLES
> 1
> 5.0 0.0 *** Can this line be changed to just "5.0 0.10" to tilt by
> 0.10 degrees away from channeling alignment with the
> horizontally running (110) planes ?
> EOIshort answer: use option ANGLES_P
long answer:
The program FLUX works with a Cartesian coordinate system, fixed to the crystal, with z-axis along a major crystal axis close to the beam direction. The x y and z axis are specified through the input parameter LATTICE and are determined by the contents of the corresponding entry in file COMBIN.FIG. To check how these axes are chosen, run program plotfig3. The angles above (theta=5, phi=0) are POLAR ANGLES in a coordinate system fixed to the crystal, with its z axis along the [110] axis and the x axis in the (110) plane. These axes are defined in file COMBIN.FIG.
We then have the relations:
x = r sin(theta) cos(phi)
y = r sin(theta) sin(phi)
z = r cos(theta)
These define the angles theta and phi used in the FLUX input.Now, suppose you are channeling in the plane phi= phi0, at an angle theta= theta0 away from the z-axis. In the example above theta0 = 5 and phi0 =0. Subsequently you would like the beam to be tilted an angle alpha away from channeling alignment. The answer to this question may be found by some spherical geometry. Consider the following spherical triangle:
/|
/ |
/ |
theta / |alpha
/ |
/phi @|
/______|
theta0In a spherical triangle the sides are segments of great circles on a unit sphere, and there exist a number of relations ( I always look them up in edition 50 of the Handbook of Chemistry and Physics)
We want to determine theta and phi; @ is 90 deg. This may be done as follows: a) cos(theta)= cos(theta0) cos(alpha) + sin(theta0) sin(alpha) cos(@) b) sin(phi) / sin(alpha) = sin(@) / sin(theta)
Now we have chosen cos(@)=0 and sin(@)=1 which simplifies things and we obtain: theta = acos(cos(theta0)*cos(alpha)) phi = asin(sin(alpha)/sin(theta))
Applying this with theta0 = 5 deg, alpha = 0.10 deg we obtain: theta = 5.001 deg phi = 1.147 deg
A reasonable small angle approximation is obtained by theta = theta0 phi = alpha/sin(theta0) but one might as well use the correct algorithm.
For non-zero phi0, just replace phi by (phi-phi0) in the above.
The algorithm described above has been implemented in option 'ANGLES_P'.
I do not think it is a good idea to place the input/output files in the BIN directory. Rather I would suggest to reserve this directory for excutable programs. You might make different subdirectories in FLUX7/INPUT and put the stuff for each case in a separate subdirectory. This presupposes the directory FLUX7/BIN is in your environmental variable PATH.
Assuming you have prepared an input file name 'linoleum100.inp'
To use 'fluxchk' either type:
ini -t linoleum100
(without the extension .inp)or, prepare yourself a file called 'linoleum100.ini' (or 'batflux.ini') containing the names of relevant files and a few other items, For the structure of this file see AAREAD.ME, around line 207 and below. Then type:
fluxchk
or
fluxchk linoleum100.iniThe first form, of course, to be used when the file was called 'batflux.ini'. For program flux7 it works the same way. In the first method, leave out the '-t'. In the second method, just replace the word fluxchk by the word flux7. The command 'ini' is just a script to make things easier. You should browse through it with an editor and maybe adapt a few things to your setup.
As you suggested, I typed 'fluxchk linoleum100.inp'
But it is not working. It shows
"invalid number: incomprehensible list input
apparent state: unit 2 named linoleum100.inp
last format: list io
.....etc.As explained, the above does not work, since the command line argument should not be the inputfile 'linoleum100.inp' but the startupfile 'linoleum100.ini', or nothing at all when this file happened to have the name batflux.ini. This method can be used with compilers that do not support command line arguments.
We are trying to simulate 2MeV He tranmitted through thin Si layers.
What are the correct values of ELCORE for this?
Presumably these are different from those for protons ...ELCORE contains the impact parameter dependent part of the energy loss. Besides there is a uniform energy loss, described by 'DEDX VALENCE'. Both of these are dependent on the energy and on the ion, as you already guessed.
ELCORE is a table of 'energy loss per collision' in eV, as a function of the impact parameter, in 50 steps, from impact parameter 2/50 to 2 angstroms.
Estimates for these may be calculated using the program 'dettmann'. Some examples of input files are present in directory FLUX7/INPUT/DET. For the case of 2MeV alpha particles in Si, copy the file detsialf1.inp to a file detsialf2.inp, then change in this file the energy from 1 to 2 (I think it is line 3). Subsequently run the command 'dettmann < detsialf2.inp > detsialf2.out' All the way at the end of file detsialf2.out you should find the data you want.
There is a program 'dedx' included to obtain estimates for these parameters.
If your experiment is sensitive to details of the energy loss process a better model for the impact parameter dependent energy loss may be required. If not, the only thing that matters is that the total average stopping power matches the experimental stopping power. This is something that should be checked in all cases. The program fluxchk may be used to determine the 'random' stopping power as follows from the input parameters of flux7. As a first approach we might use the values for ELCORE from dettmann's approximation, and split the difference with the experimental stopping power evenly over DEDXVP and DEDXVL.
I am using the GAAS110 input file, and a planar channeled beam
with angles such > as 3,0 as theta,phi, so
the beam is channeled in the horizontally running (110) planes. If I
want to put a translation of the lattice at a bilayer interface
such that a planar channeled beam in the top layer experiences
a vertical translation of the lattice, so that the initially channeled
beam bumps into the lattice walls of the second layer, which of the
three numbers do I change ?. Presumably if I want to shift by a quarter
of the (110) lattice spacing in y the translation vector would be:
0 (0.25*1.92A) 0. Is this correct ?As you may see in the flux7.f source file (which is the only authority to rely on) the input vector is *added* to the (x,y,z) position of the channeling ion at the interface, in the frame of the crystal lattice. Thus in the frame of the ion, the lattice shifts in the opposite direction. The xyz axis are defined by file COMBIN.FIG, and for this case correspond to what you describe above, if I remember correctly. Run program plotfig3 if in doubt.
If the sample has three or more *different* types of sublayers the channeling simulation has to be split up into different runs of program flux7, using the options EXITCOORD and CFILE.
This is also true if the depth step is different for different sublayers, see below.
For a simple test case, see file TEST/fluxtest.sh.
As long as there are only 2 kinds of sublayers it is not necessary to do the flux7 calculation in parts. But it is also not forbidden.
For a multilayer with a *repeating* structure of 2 kinds of sublayers the option INTERFACE alone will do.
The above is true if also the thicknesses repeat. Otherwise, i.e. for a case where the lattice types repeat, but the thicknesses do not repeat, the option THICKNESS should be given in addition to interface.
There is a problem with arrays such as the nuclear encounter probability and energy as a function of depth, (the arrays RAAK, DAV, DDAV) Here the bin width, and therefore the apparent depth scale, may be different for different layers.
1) The binwidth (for arrays RAAK etc) is determined by NDELZ. NDELZ is one and the same value independent of the current layer! It is set in file FLUXLIB/prelimi.f. This part not been properly adapted to the most general multilayer case. This just means that one bin of RAAK, DAV, DDAV corresponds to the same number of depth steps (and thus possibly a different depth interval) for each of the layers. This is not a disaster, if in further processing of these arrays this possible difference is taken into account (program show does *not*!!)
2) A more problematic thing is that the same value NDELZ is also used to determine the total number of steps required in the main loop of program flux7!!! This is bound to lead to problems when the depth step is different for different layers.
In conclusion, flux 7 is only useful for multilayer targets if the depth step used varies only slightly for each sublayer. In other cases the simulation should be split up in parts.
A simulation will always change from one layer to another at the interface locations as prescribed by the input file, with an accuracy of one depth step.
see coord