1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/README.previous	Wed Sep 26 17:50:53 2007 -0400
     1.3 @@ -0,0 +1,89 @@
     1.4 +The Fractal Realizer (FR) code was originally developed under DEC Fortran
     1.5 +under ULTRIX (Yeah, incredible, huh?).
     1.6 +
     1.7 +I have updated the Makefile to work well with the Portland Group Fortran
     1.8 +77 compiler under RedHat 7.2 Linux.
     1.9 +
    1.10 +Since this is a research code, I assume that users have some facility
    1.11 +with compilation and Makefiles.  The FR code consists of a visualization
    1.12 +portion, written in C, and the FR model itself, written in Fortran.
    1.13 +The Fortran portion is a subroutine called by the main C program.
    1.14 +The visualization portion is based on the XPM extension to X windows
    1.15 +(http://koala.ilog.fr/lehors/xpm.html),
    1.16 +written by Arnaud Le Hors.  The XPM extension is already present in
    1.17 +(almost) all recent versions of operating systems which include X windows,
    1.18 +so it is not necessary to get anything new.
    1.19 +
    1.20 +When using non-Portland compilers, change pgf77 in the Makefile to
    1.21 +whatever your installation may have.  Since the C piece is main, many
    1.22 +Fortran compilers need to be given a "nomain" switch, or they get very
    1.23 +confused.  Since the syntax for this switch varies among compilers, you
    1.24 +may have to look up the equivalent switch for your particular compiler.
    1.25 +Since we use a lot of common blocks, a switch to align these on common
    1.26 +boundaries is helpful also.
    1.27 +
    1.28 +Another typical cross-language problem is the number and placement of
    1.29 +underscores in the names.  Some compilers want "_MAIN_", while others
    1.30 +want "_MAIN" or other variants.  Since there is no universal solution,
    1.31 +you may have to mess with these names manually.
    1.32 +
    1.33 +Function prototyping may be a problem, but shouldn't be if you use an
    1.34 +ANSI-compatible C compiler.  We have included a local strdup function,
    1.35 +but that shouldn't be a problem either.
    1.36 +
    1.37 +It should be possible to get g77 to work, but I have not pursued this.
    1.38 +If you get g77 to work, or modify the Makefile to get other compilers to
    1.39 +work, please let me know (hnw@fire.esd.ornl.gov) so that I can incorporate
    1.40 +your improvements back into this distribution.
    1.41 +
    1.42 +If you don't understand any of the above, don't worry -- you probably
    1.43 +don't have to.  JUST TRY IT AND IT WILL PROBABLY WORK.
    1.44 +
    1.45 +
    1.46 +Say "make depend"  and then "make fast"  to get an FR executable called
    1.47 +"realizer"
    1.48 +
    1.49 +If you modify or do further development, you may wish to say "make debug"
    1.50 +or "make profile" to get debug and profile versions of the executable,
    1.51 +respectively.  This is not necessary to run the present version.
    1.52 +
    1.53 +Then try it out with any of the included script files (*.scr) like this:
    1.54 +
    1.55 +./realizer < whatever.scr
    1.56 +
    1.57 +When the FR runs, it writes an input script called input.scr, so if you
    1.58 +just want to change one or a few things, you can rename and edit input.scr
    1.59 +and rerun it easily.  The order and nature of the question prompts asked
    1.60 +by the FR are answer-driven and input-dependent, so larger manual changes
    1.61 +to input.scr may not work -- rerun ./realizer without redirected input
    1.62 +and answer new questions to regenerate a correct input.scr.
    1.63 +
    1.64 +After the FR runs, it makes two output files called landscape.xpm and
    1.65 +ties.xpm
    1.66 +
    1.67 +You can use the XPM utility sxpm, available on most systems, to view these
    1.68 +(xv will also work).
    1.69 +
    1.70 +sxpm landscape.xpm
    1.71 +
    1.72 +The FR program uses a heap sort to sort the entire map to find the
    1.73 +highest probability sites, so execution time will increase rapidly as
    1.74 +the size of the map is increased.  Execution time also increases with
    1.75 +increasing numbers of categories in the map.  Because of the midpoint
    1.76 +displacement algorithm for generating (pseudo)fractals, the maps must be
    1.77 +square, with sides of (2**n)+1.  However, the use of constraint masks
    1.78 +will permit oddly-shaped and smaller synthetic maps to be generated
    1.79 +while still preserving both p and the fractal dimension of each category.
    1.80 +
    1.81 +We hope that the FR will prove useful (or at least stimulating) to you.
    1.82 +Please be sure to cite our Conservation Ecology paper in all work stemming
    1.83 +from the use of the FR, and be sure to let us know of any improvements
    1.84 +or suggestions that you may have ...
    1.85 +
    1.86 +     ____                             Oak Ridge National Laboratory
    1.87 +      /  )      /  /      /  /        P.O. Box 2008, M.S. 6407
    1.88 +     /--<   o  /  /      /--/         Oak Ridge, TN  37830-6407
    1.89 +    /___/__<__/__/_     /  / _        (865) 241-2748
    1.90 +   William W. Hargrove                (865) 574-4665 (fax)
    1.91 +   FedEx/UPS, use "Bethel Valley Rd." http://research.esd.ornl.gov
    1.92 +   hnw@fire.esd.ornl.gov              http://research.esd.ornl.gov/~hnw