• The principal input file is a text file which must be named input for proper execution. (1)

• All secondary input files, whose names are user defined, are defined in the input file. The filenames must be all lowercase. (2)

• The input file can be created or modified with any text editor.

• The input file is divided into cards (3), lines (4) and fields (5).
• Cards are named and identified with a “~” prior to the card name in the card title line (6) (Card names without the preceding “~” are not interpreted by the simulator).
• Input lines for each card are located immediately below the card title line. 
• Cards may be sequenced in any order within an input file BUT the input within any particular card must follow the described syntax.
• If a card type is repeated within an input file only the first card will be read by the simulator; the other cards of similar type will be ignored.
• Some cards are required and others are optional or unused depending on the operational mode and the type of problem being simulated.
• Input cards contains lines (4), always ending with a comma, and delimited with a line return.
• Input lines comprise fields (5), delimited by commas. A closing comma is always required to identify the end of the field.
• Blank lines within a card structure are not permitted, but any line with a “#” or “!” as the first character is considered to be a comment line (7). 
• All leading and trailing spaces in a field input are ignored. Fields are parsed by their starting and ending commas.
• Input fields may be one of four types:
  1. keywords (8)
     1. Keywords are used to identify cards or select options (model formulations, solution schemes, initial condition variables, boundary condition types, or output requests).
     2. Keywords are case insensitive, which means that a field entry of "Pressure" is equivalent to that of "pressure." 
  2. character strings (9)
     1. Character strings are used to name entities (e.g., rock/soils, solutes, or reactive species) or specify units, associated with dimensional variables.
     2. Character string entries are case insensitive, which means that a field entry of "Shale" is equivalent to that of "shale." 

     3. Unit inputs can be any combination of the recognized units; where spaces between units imply multiplication of units and only a single division symbol can be used within the character string. The “^” is used to represent exponential notation in the input file (e.g., m^2 = m²). 

  3. integers (10)
     1. Integer entries must be an integer value without decimals or scientific notation.
  4. real numbers (11)
     1. Real number entries can be specified as integers, or numbers with decimals and/or scientific notation (e.g., 9.9832e+2, 998.32, 99.832E+01).

Internally, STOMP uses the International System of Units (SI); where, the base units are length in meters (m), time in seconds (s), mass in kilograms (kg), temperature in degrees Celsius (˚C), and molar mass in kilomole (kmol). However, unit inputs can be any combination of the recognized units and need not be consistent within an input file. The user may specify output units that are different from those used for input, and they need not be consistent (for example, one may request output for length in meters and pressure in psi).

Some cards are required and others are optional or unused. The number of required cards depends on the operational mode. If an attempt is made to execute the simulator using an input file with an incomplete set of required cards, an error message will be generated and the code execution will stop.

Optional cards are used to specify STOMP capabilities that may be required to execute a particular problem or generate desired output data. These cards are considered optional, because the capabilities accessed through these cards are not needed to execute the code. Execution of the simulator with input files that have an incomplete set of optional cards yields warning messages, which will note the missing optional cards but allow the execution to continue.

Input file card descriptions, syntax, and examples are provided for each card and each operational mode of STOMP. To determine which operational model to apply to a specific problem, please see the section on governing equations and operational modes.