Step 27: First run of NeoKinema!

Since we have not yet created any stress-direction dataset (s*.nki file) yet,
line #14 of your NeoKinema-parameter file (p*.nki) should be changed to “none”.

When you run NeoKinema, there is only one question to answer: the name of the parameter file (p*.nki).
This file includes the names of all other input files that will be needed; they must also be available in the current folder.

As NeoKinema is running, it reports various messages to the screen. 
If you are not available (or not fast enough) to read them in real-time,
this is not important; they are all placed in the log-file (t*.nko) as well.

Each time NeoKinema prepares to perform more dynamic memory allocations, it puts a message on the screen (and in the log-file)
about the new array to be allocated, and its memory demand (both incremental, and total-for-the-run-so-far).
This means that, in the unlikely case that NeoKinema should run out of memory and abend,
you will have a message in the log-file giving some clue about what the problem was.
(For example, users of 32-bit Windows will probably not be able to allocate more than ~1.5 GB of total memory.)
If you have to deal with an out-of-memory abend, there are basically just two options:
(a) Run the same problem on a 64-bit Windows computer with lots of memory chips installed; or
(b) Return to Steps 20~26 of this Guide, and design a new F-E grid (.feg file) with fewer nodes.

There are many possible error messages that can occur when first reading the input files;
in general, you might want to compare your data against the Fortran 90 source code in NeoKinema_v5.1.f90 that is doing the reading.
Also be sure that any Fortran FORMAT you provided in your input files is correct.  (Check the number, type, and widths of its entries.)

Two special problems may arise when re-using older NeoKinema input files:
(1) Older parameter (p*.nki) files may lack the new line #15, just after the name of the stress dataset, that selects how it should be interpolated.
            (This line is now required in the parameter file, even if the preceding line says “none” for the name of the stress dataset!)
(2) Older geologic fault-offset-rate datasets (f*.nki) which probably lack the (optional) last two columns with hard limits on offset rate [Step 14],
            still need to specify a Fortran FORMAT with enough entries to describe those two new columns (in case they might be present)!

In addition, one error message associated with the .gps dataset of benchmark velocities is very common:

CAUTION: Found unsafe benchmarks, defined as any located in
the same finite-element with any fast-slipping ( >1 mm/a ) fault.
E_longitude  N_latitude  Element  FastFault1  Benchmark
-----------  ----------  -------  ----------  -------------
   -120.379      40.176     1047    F1953R    0225_GPS
   -119.994      40.245     1046    F1953R    0226_GPS
   -115.423      35.541       93    F1850R    0801_GPS
   -117.329      35.978     6502    F3406R    0914_GPS
   -119.697      39.285      601    F2227L    10BB_GPS
            ….. [list may be quite long!] …
-----------  ----------  -------  ----------  -------------
Such coincidences may cause errors in the velocity solution
(and fault heave-rate solution) which are comparable in size
to the fault heave rate!
I suggest that you stop now, and either:
   (1) edit the .FEG in OrbWin to shrink these elements,
       using utility program GPS_2_DIG to plot benchmarks; or
   (2) delete these benchmarks from the .GPS & .GP2 (if any),
       using utility program Delete_Cracked_Benchmarks; or
   (3) move these benchmarks outside these elements.

The shorthand name for this problem is “cracked benchmarks,” meaning that an active fault runs through them, or too close to them.
The reason this is not allowed is, that NeoKinema does not actually model a discontinuity in velocity at the fault trace;
instead it approximates this with a steep gradient in velocity within the fault-corridor finite-element(s) containing the fault trace.
If the fault has a high offset rate (> 1 mm/a) this approximation would cause ficticious GPS-related errors, and
also bias the NeoKinema velocity solution in an unpredictable and unacceptable way.
The solutions to this problem could include:
(1) Returning to Step 22 of this Guide and creating fault-corridors (if you did not already do so); and/or:
(2) Deleting the “cracked benchmarks,” in the next step of this Guide.

If you are lucky enough to avoid this problem (perhaps because you are not using any GPS data?),
you can skip the next step of this Guide, and go directly to Step 29.