Previous Next Table of Contents

7. Acknowledgments, References, and Program Notes

7.1 Acknowledgments

I mostly want to thank Matt Newville. He suggested writing the program in this manner and offered me several subroutines from Feffit for my use here. Matt and Daniel Haskel helped me test the code from its earliest incarnations.

7.2 Bibliography

  1. Bevington, Philip R., Data Reduction and Error Analysis for the Physical Sciences, McGraw-Hill, New York, (1969)
  2. software archive, AT&T
  3. Newville, M, Documentation for Feffit, , UWXAFS Project.
  4. Press, W.H., S.A. Teukolsky, W.T. Vettering, B.P. Flannery Numerical Recipes in Fortran, The Art of Scientific Programming, Cambridge University Press, (1992)

7.3 Copyright Issues

Phit uses the MINPACK package of subroutines from AT&T's Netlib repository. This is freely available software. Several other algorithms are taken from Numerical Recipes by Press, et al. By the terms stated in that book, the algorithms contained therein are freely available to anyone who transcribes them. The rest of routines in Phit are copyright of the University of Washington. Version numbers below 1.0 are not licensed software, but are only released to holders of the UWXAFS3.0 software license. The terms of that agreement apply.

7.4 Obtaining New Copies of FEFF or of the UWXAFS Analysis Programs

If you do not have a license to use FEFF or the UWXAFS analysis programs and are interested in obtaining one contact:

Ed Stern
c/o UWXAFS Project 
University of Washington 
Department of Physics, FM-15 
Seattle WA, 98195, USA 
phone: (206) 543-2023 
fax: (206) 543-0635 
electronic mail: stern@phys.washington.edu 
URL: http://krazy.phys.washington.edu/people/ed.html

or

John Rehr
c/o FEFF Project 
University of Washington 
Department of Physics, FM-15 
Seattle WA, 98195, USA 
phone: (206) 543-8593 
fax: (206) 543-0635 
electronic mail: jjr@phys.washington.edu 
URL: http://pauli.phys.washington.edu/~jjr/

You should request copies of the licensing agreements for FEFF and the UWXAFS programs. These are licensed separately. ATOMS is distributed with both packages.

7.5 To Do

If you have any good suggestions for expanding the functionality of Phit, please contact the author.

7.6 Source Code Parameters

Phit is shipped with the following hard-wired parameters:

      parameter (ndatx=2**13, nrangx=10, ndocx=19)
      parameter (ntitx=19, nfunx=100, nconx=300)
      parameter (nguesx=50, nsetx=300)
These parameters are defined as follows:
  1. ndatx: max number of input data points
  2. nrangx: max number of fitting range delimiters in input data
  3. ndocx: max number of documents in i/o data
  4. ntitx: max number of title lines
  5. nfunx: max number of input functions
  6. nconx: max number of constants to be encoded
  7. nguesx: max number of guessed values
  8. nsetx: max number of set values
If any of these are too small, they can be changed in the source code and the source code can be recompiled.

7.7 Code Portability and Code Compilation

The 1977 ANSI Standard for Fortran has been followed closely, so that Phit should easily compile on any machine and run without any problems. The only significant departures from Fortran 77 are the assumption of the ASCII character set and the use of integer*2 variables for the UWXAFS binary file handling routines.

There are, unfortunately, aspects of Fortran which are machine- and compiler-dependent by design. One such aspect occurs in Phit in the form of a compiler-dependent dimension for the ``word-length'' of the data in the UWXAFS binary files. The code cannot easily be made truly standard without significant changes to the UWXAFS binary file handling routines. The distributed code will, however, work on most machines, with the notable exception of a Vax or Alpha running VMS. Changing the second executable statement of Phit from vaxflg = .false. to vaxflg = .true. will optimize the code for a VMS machine.

The UWXAFS binary file handling routines also use character strings which are 2048 characters long. Though standard, some compilers need to be told to accept character strings this long. The notable example of such a compiler is xlf (for AIX, IBM's Unix flavor), which needs the compiler switch -qcharlen=2048. While compiling on any machine, we recommend including some form of array bounds checking. If you have any problems with the compilation, it may be worthwhile to turn off compiler optimization flags. There may be some persistent, benign compiler warnings when you compile Phit. There may also be ``comparison is always false'' warnings when using f2c. These can both be safely ignored.

7.8 Adding More Data Formats to Phit

If the two data file formats (UWXAFS, ASCII) are not acceptable or convenient to your needs (that is, if you prefer using some other format), other choices could be added with a minimal amount of coding. The input and output of data files is fairly well-isolated, with subroutine inpdat and outdat controlling which data format to use. If you'd like another file format either contact us about it or follow the example of the routines inpcol and outcol, which read and write files in the ASCII column data format.

7.9 About this document.

This document was composed using a mark-up language called linuxdoc-sgml. This is the documentation standard of the Linux Documentation Project. linuxdoc-sgml is an adaptation of the QWERTZ document type definition written by Tom Gordon. linuxdoc-sgml is available on the net.

The value of a Standard Generalized Markup Language (SGML) is that it can be processed into any number of formats from a common source. Using linuxdoc-sgml, a single marked up file can be used to produce LaTeX, PostScript, plain ASCII, HTML, TeXinfo, or dvi documentation.


Previous Next Table of Contents