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 a constant stopping cross section i.e. the energy dependence of the stopping power is neglected. If this approximation is not acceptable it should not be too difficult to introduce energy dependence.
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.
As of version 7.7 there is an option for a structure with
random vacancies, or a mixed structure with two kinds of atoms
occupying similar sites ( Ge_x Si_(1-x) ).
(As of version 7.8.5 this may also be more then two kinds).
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.
How to install.
Assuming you managed to obtain flux7.z.tar.bz2, type:
tar -jxvf flux7.z.tar.bz2
This should produce directory tree FLUX7.
Read through the installation instructions INSTALLATION in the install page
Now you may be in trouble since your type of Unix is not in the script 'makemake'. What to do?
- see what your machine says to command ``uname'', something like ``DEC-alpha'' maybe.
- edit file ``makemake'' and insert two lines:
elif [ $machine = XXXX ] ; then defsfile=makedefs.dec
where XXXX stands for the "uname" output.
- Now you still need a file named ``makedefs.dec'' 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 MinGW. 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 = touch If 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 = /usr/lib/libX11.so
The right hand side of this equation is the name of the X11
library. It might be /usr/lib/libX11.a or something else.
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.
Send me the 'makedefs' file once you got things working.
If all else fails:
You should be able to get flux7 itself, as well as fluxchk to run since they don't depend on pgplot. Try
'make -i -k' (this causes errors to be ignored) and see how far you get
Using default values of DFLAGS and LFLAGS makes optimized versions. One may specify specific values to facilitate debug versions, e.g. make flux7 DFLAGS=``-g'' LFLAGS=``''
Look in the man pages of your installation for debugging programs, such as 'xdb', 'dbx', 'gdb', 'xxgdb'.
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 Loader PATH in the install page
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, i.e. go to this directory, and do the configuring and 'make'ing while in this directory. For some reason the pgplot files don't like to be moved around after they are made.
Flux7 assumes that you have selected at least the X11 and PostScript drivers. I would suggest to uncomment the following in file drivers.list:
NUDRIV 0 /NULL Null device (no output) Std F77 PSDRIV 1 /PS PostScript printers, monochrome, landscape Std F77 PSDRIV 2 /VPS Postscript printers, monochrome, portrait Std F77 PSDRIV 3 /CPS PostScript printers, color, landscape Std F77 PSDRIV 4 /VCPS PostScript printers, color, portrait Std F77 XWDRIV 1 /XWINDOW Workstations running X Window System C XWDRIV 2 /XSERVE Persistent window on X Window System C
You should keep in /usr/local/pgplot at least the files
grfont.dat libpgplot.a pgxwin_server rgb.txt after cleaning up, and it is wise to also keep drivers.list makefile
Furthermore you have to define a few environment variables:
PGPLOT_DEV=/xwin PGPLOT_DIR=/usr/local/pgplot/ PGPLOT_BACKGROUND=white PGPLOT_FOREGROUND=black PGPLOT_XW_WIDTH=0.6
for 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 ? > EOI
short 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 @|
/______|
theta0
In 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.ini
The 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 the coord page