PDS_VERSION_ID = PDS3 RECORD_TYPE = FIXED_LENGTH RECORD_BYTES = 80 OBJECT = TEXT PUBLICATION_DATE = 1998-08-04 NOTE = "Description of the SOFTWARE directory contents for the Viking Lander rock distribution archive" END_OBJECT = TEXT END The SOFTWARE directory contains FORTRAN 77 source code for one program that may be useful in working with the Viking Lander rock distribution archive. The SOFTWARE directory also contains this file (SOFTINFO.TXT), an ASCII file which describes the contents of the directory. The program name is rockana and the source included here is ROCKANA.F. The source is an ASCII file with variable length records. Each record is delimited by an ASCII carriage-return line-feed pair, which may need to be converted to the default delimiter on the local machine before use. The program does a statistical analysis of a table of Mars rock data. It produces number density and areal coverage functions versus rock diameter for rock populations at the Viking Lander 1 or Lander 2 sites. The program was compiled at Stanford under SunSoft FORTRAN 77 4.0 and executed under Solaris 2.5.1. During PDS peer review of the data set, it was also compiled (but not run) using Fortran PowerStation 4.0 under Windows95 and using an unspecified FORTRAN compiler on a SunOS 4.1.4 system. Usage ===== rockana There are no arguments. To compile and run under Solaris, rename the source file to rockana.f and type f77 -u -c rockana.f f77 -o rockana rockana.o Move the data file into the same directory. Its name should be the first (and only) line in file rockana.in (also in the same directory). Then type rockana Input File ========== The input file is rockana.in and it contains only the name of the file of input rock data; do not include a path name. If the file name is not VL0ROCKS.TAB, VL1ROCKS.TAB, or VL2ROCKS.TAB, the program will fail at about line 295. You must add a new option to the IF statement at that point giving the areas of the drift, far field, and near field surfaces. Output Files ============ There are four output files. The file rockana.out is the most readable and probably the most useful. For each surface type and burial state it shows: (a) the surface area covered by rocks in each size range, where rocks have been binned according to their average diameter (b) the average axial ratio of rocks in each bin (computed for each pair of axes) For each burial state it repeats the above by summing over surface types (drift material, far field, and near field). For each surface type it sums over burial states. And, finally, it gives both the raw number distribution and area covered as a function of rock diameter as well as normalized values (per square meter) after adjusting far field statistics to have the same distribution of small rocks as were found in the near field. rockana.tab is a variation on the format above which allows simple conversion to PDS TABLE objects. rockana.arrays is (a) and (b) above for each surface type and burial state; there have been no accumulations over surface types or burial states. rockana.db is an expansion of the original data file (VLnROCKS.TAB) showing the individual axial ratios and areas for each rock. Possible Variations =================== Users interested in trying other binning schemes for rock distributions should be able to do so. The number of bins (ndbins) is defined as a parameter at the top of the declarations section; the bins themselves are set up in the Initializations section at the top of the computational part of the program. An old initialization for equally spaced 5 cm bins remains in the code, but commented out of action. The program was never fully exercised with anything but sqrt(2) geometrically increasing bins; so it's possible there could be unpredictable results with even the equally spaced bins. Advisory ======== This program is not guaranteed to do anything. After limited testing, it executed under both SunOS and Solaris, and it appeared to reproduce results reported by [MOORE&KELLER1990] and [MOORE&KELLER1991]. It was designed to do a very simple task initially and grew, without much regard for software aesthetics, into a much larger package.