There are 2 input files if one runs in interactive mode. If one 
runs in batch mode, then other files that send these files to the 
batch queue need to be made as well. Their details will differ
for each particular system.

The two input files are:

prk.input
prk.dat

The file prk.input is read first and contains a list of names 
of files that are written as well as the name of the 
particular prk.dat file that is read next. The prk.input 
file also contains some other parameters including flags that 
specify whether this run is 
1) to write a file that would allow restarting at the time 
   step where this run ends, 
2) to read a file that would allow this run to restart at a 
   time step corresponding to the end of some previous run, or 
3) both of these possibilities.

The prk.dat file contains the information that defines the geometry
of the elements that define the fault plane, information about
which elements are the boundary condition elements, the value of
the velocity on the boundary condition elements, and a number of
parameters that specify the distribution of rate and state friction
parameters on the fault plane. There are some other parameters 
specified in this file as well.

Both the prk.input and the prk.dat files contain not only the types
of data described above, but on the right side of most lines they
also contain a list of the names of the parameters that are given
earlier in the line. The combination of this and the definition
of parameter names in the main program and the subroutines means
that it is easy to understand what each parameter in the two input
files represents, and what items need to be changed to alter the 
model for a different run.

The most complicated part of making up a data set is determining
the parameters that define the geometry of the elements. Studying 
the examples of the prk.dat files given for the First Code 
Improvement Milestone run will help one understand how it is done. 
Basically the elements are entered in a number of rectangular blocks, 
and the parameters that define each block is given in a separate 
line. The following is line 3 from the prk.dat file for the First 
Code Improvement Milestone run, namely prk.dat.150003, and is an 
example to show how defining the elements works. This line is the 
input for the first one of the blocks in this particular model:

   84   60 -135. -135.   2.6  1.    347. 45.   5040   5040  0.62222  0.4444   nx nz dxb dzb xulnum xuldenom zulnum zuldenom; num_in_blk cum_num dlx dlz : patch, 1/135 km fine part

The first 8 entries in the line are the data. The remaining
entries are to help one understand what the data means and to help 
in setting up the lines properly. Thus, the next optional entries 
after the first required 8 entries are:

5040   5040  0.62222  0.4444   nx nz dxb dzb xulnum xuldenom zulnum zuldenom; num_in_blk cum_num dlx dlz : patch, 1/135 km fine part

where the next entry in the line (5040) is the number of elements
in the block (num_in_blk = nx times nz). The next entry is the 
cumulative number of elements in the model up to the end of this 
block (cum_num). (It is also 5040 in this example, since this is 
the first block.) These two entries are made to help one keep track 
of how many elements are in the model as one constructs it. The 
following two entries (0.62222  0.4444) are the width (dlx) and 
height (dlz) in km of the block (namely the number of elements in 
each direction [nx or nz] times the dimension of each element [dxb 
or dzb]). These optional entities (num_in_blk, cum_num, dlx and 
dlz) are not actually used in the program, but are just here to 
help one construct and envision the geometry of the model.

The rest of the entries in this line are the names of the 8 input 
parameters and four optional parameters. The meanings of the 8
required input parameters are:

nx (=84)         is the number of elements in the x or horizontal 
                  direction in this block
nz (=60)         is the number of elements in the z or vertical 
                  direction in this block
dxb (=-135)      is the dimension (km) in the x direction of each 
                  of the elements in this block. If dxb is negative
                  as is the case here, then the dimension is the
                  reciprocal of the number given.
dzb (=-135)      is the dimension (km) in the z direction of each 
                  of the elements in this block. If dzb is negative
                  as is the case here, then the dimension is the
                  reciprocal of the number given.
xulnum (=2.6)    is the numerator of a fraction that gives the 
                  x coordinate (km) of the upper left corner 
                  of the block. The origin of the xz coordinate
                  system is at the Earth's surface above Middle
                  Mountain, i.e. at the nominal focus of past
                  Parkfield earthquakes. Plus x goes to the SE
                  along the San Andreas fault, and the view from the 
                  SW is the one that specifies which is the upper 
                  left corner.
xuldenom (=1.0)  is the denominator of a fraction that gives the 
                  x coordinate (km) of the upper left corner 
                  of the block. 
zulnum (=347.)   is the numerator of a fraction that gives the
                  z coordinate (km) of the upper left corner 
                  of the block. Plus z is downward. 
zuldenom (=45.)  is the denominator of a fraction that gives the
                  z coordinate (km) of the upper left corner 
                  of the block.  

The meaning of the 4 optional entry names (num_in_blk cum_num dlx dlz) 
is given in the paragraph above. The last entry (patch, 1/135 km fine 
part) is a verbal description of the block.

Subsequent lines that define other blocks do not have the nx, nz, dxb, 
etc. list, but simply an optional verbal description of the block.

All of the 8 data entries in this line, as well as the 
data entries in all other lines, are read with free form 
input rather than with a format statement. Thus, as long as
entries are separated by at least one space, they will be
read properly as only their position in the sequence matters.
However, it is helpful to lay out the data file so that entities
align in columns in order to keep better track of what is what.

The tricky part of laying out a model with this input method is
keeping track of where all the elements are so that there will be
no gaps or overlaps. One way to do this is just to lay it out on 
a piece of graph paper as you plan where you want the blocks, 
before starting to actually enter their coordinates. A useful way 
to verify that there are no errors in the model you have defined
is to make a computer generated plot of the element geometry 
based on this prk.dat file, so that visual inspection will show 
any errors.