FREQUENTLY ASKED QUESTIONS

Frequently asked questions about flux and related programs.

Please submit further questions, and answers, to p.j.m.smulders@home.nl

Some answers without questions:

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.

INSTALLATION PROBLEMS

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 install

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

debugging

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'.

Some errors during compilation and testing

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 install

PGPLOT

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.

Is it possible to simulate PIXE/channeling dips with flux?

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 vibation 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.

defining tilts in FLUX7

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'.

How to run the programs fluxchk and flux7.

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.

How to run the programs fluxchk and flux7 , lesson 2.

 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.

ELCORE

 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.

DEDX VALENCE

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.

Can you explain the translation vectors in FLUX7 to me?

 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.

About multilayer targets.

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.bat.

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.

About different depth steps in multilayer targets.

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.

About layer thicknesses.

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.

How to obtain frequency distributions of interesting parameters.

see coord