Step 26: Choose boundary conditions

Perhaps you have previously used some dynamic (forward) F-E program, like my 2-D thin-shell program Shells?
If so, you will be familiar with the idea that every boundary node requires some kind of boundary condition: either specified velocity, or specified force.

NeoKinema is a kinematic (inverse) F-E program, so the choices for boundary conditions on boundary nodes are different: specified velocity, or free.
(However, NeoKinema also provides a choice of two different ways to specify a fixed velocity.)

Fortunately, a previous step (Step 24) explained two methods for getting an ordered list of boundary nodes, in which each line already includes:
boundary-sequence-number (BC#), node-number, latitude, longitude.

Now, you must edit this list to create a boundary conditions (b*.nki) file.
Use any word processor that can save plain-ASCII text with no formatting, such as NotePad or EditPad Pro.

The first line of your b*.nki file should usually be changed (from the column-headers currently in the .per file) to a descriptive title.
This can be any brief text that helps you to remember the concepts and hypotheses that you used when choosing specific boundary conditions.

There are as many following lines as there are boundary nodes.
(The node at the beginning of the circuit is not listed again at the end.)
In each line, insert a boundary condition index-code (and any associated data) between the node-number and the (latitude, longitude) coordinate pair.
Your choices of index-code are:

· 0: This node is left free.  (No additional data are needed after code “0”.)

· 2: This node has fixed velocity; the velocity-magnitude (in units of m/s = meters/second; not mm/a!) and velocity azimuth (in degrees clockwise from North) must follow the “2”.

· 4: This node has fixed velocity and is attached to a rigid plate of the PB2002 model [Bird, 2003]; the two-letter plate code enclosed in quotes (e.g., “PA”) follows; velocity will be computed for you!

Assuming that you use some boundary-conditions of type 4 (and most people do), NeoKinema will create a short table
(in its text-output file, t*.nko) of the Euler poles that were used to compute these velocities:

    Table of Euler poles used to compute type-4 velocity boundary conditions:
    (Note that all are relative to current reference plate NA.)
    PLATE  N_latitude E_longitude  Degrees/Ma  Note       
    -----  ----------  -----------  ----------  ------------
    JF-NA     -22.495       68.419      0.7715  built-in   
    NA-NA       0.000        0.000      0.0000  stationary 
    PA-NA     -49.890      102.989      0.7660  built-in   
    -----  ----------  -----------  ----------  ------------

If you wish to change one of the Euler poles used in the PB2002 model, or if you want to add plates, this is easy to do!
Just use plate-name abbreviations that are not found in the PB2002 model (e.g., “P1” or “P2” as alternatives to “PA”).
Then NeoKinema will prompt you to add the Euler pole data (longitude, latitude, rotation-rate) for any new plates at run time,
and this little table of Euler poles in the t*.nko file will be a record of your choices.
This option can be very useful later in the project, when you want to find out whether your results are sensitive to
small changes (uncertainties) in the Euler pole(s) that determined the boundary velocities?

When you are done creating boundary-conditions, Save your work with a file-name
such as b_yourFEGridName.nki, where yourFEGridName is the name of your (renumbered) .feg file.

Then, enter this name of your new b*.nki file into line #21 of your NeoKinema-parameter file (just below the name of your renumbered .feg file).

Note that NeoKinema will count how many fixed-velocity nodes (type-2 or type-4) there are in your b*.nki file.
If less than 2 fixed-velocity nodes are counted, then NeoKinema will issue a warning:
In the absence of a .gps data file, your problem will be “singular” (non-unique) and cannot be solved numerically!
If you are using a .gps data file, and if the benchmarks are well-distributed across the .feg grid area, then you could try an experiment, of ignoring this warning(?).
(However, results in such cases can be confusing, especially if the current NeoKinema weighting parameters are not well-chosen.)