Rather than solving a problem directly, SPARK builds a program that carries out the solution. This approach is taken in an effort to maximize solution efficiency. The overall process of generating the solution sequence for a SPARK problem expressed using the SPARK language is discussed in this section. The process of building a SPARK simulator for the generated solution sequence and of solving it is discussed in the following sections.
Several programs of the SPARK distribution are used in this process:
- the parser program, and
- the setupcpp program. The principal output of the build process are the problem.xml and problem.cpp files that describe the problem topology and the solution sequence to be used by the SPARK solver.
As the problem.pr file is parsed, various declarations of atomic (*.cc) classes and macro classes (*.cm) are found. The specified class paths are searched for these classes. If a macro class is found, it is parsed, and if the macro refers to other macros, they are parsed. This continues recursively to any depth.
The result is to resolve all macros to atomic objects so that, at run time, SPARK can operate entirely on atomic classes. This exposes individual equations and variables to the graph theoretic algorithms for organizing an efficient solution sequence. The principal output of the parser is the setup file, problem.stp. This file is a different expression of the problem, with the principle difference being that the macros have been resolved.
The parser command line is:
parser [options] filename <enter>
Parser options can include:
class_path is a list of directories separated by commas, e.g., c:\vspark200\hvactk, c:\vspark200\myClasses These directories are searched in the given order to find classes needed by the problem. If omitted, the environment variable SPARK_CLASSPATH will be used in the same manner.
Sets level at which parser will report errors. E.g., e1 will result in report of errors only. Higher numbers give increased verbosity: 1 = errors 2 = warnings 3 = information 4 = more information. The default is -e2.
Sets level of verbosity in the created setup file. Lowest is 1, with increasing verbosity up to 6. The default is -s2.
If -l logFileName is specified, the diagnostic messages are sent to logFileName. If -l is given without logFileName, the messages are sent to the file parser.log.
Extensive debugging output will be generated.
The next step is carried out by the setupcpp program. The main function of setupcpp is to perform the graph theoretic analysis of the problem, producing a compact, efficient solution procedure expressed either in C++ or in XML format. The C++ representation is emitted in the problem.cpp file whereas the XML representation is emitted in the problem.xml file. Depending on the problem build process selected at runtime either file will be needed by the simulator.
In addition to the problem.cpp and problem.xml files, setupcpp produces two other files. One is essential to final problem execution, namely problem.prf. This file serves to transmit needed information from the setup process to the solution process. Default solution settings can be specified in the default.prf file in the current working directory. If this file is not found, then setupcpp uses hard-coded default solution settings to populate the problem.prf file. The other produced file is problem.eqs. This file is a human readable expression of the solution sequence. It is not used by SPARK, but is sometimes helpful in debugging when numerical difficulties are encountered.
The setupcpp command line is:
The setupcpp program loads the setup file named problem.stp and performs the graph theoretic analysis to produce the problem.cpp and problem.xml files containing the solution sequence.
See Document Type Definition file for more information on the set of grammar rules used to generate the XML problem description.
The next step in the process is to build a SPARK simulator for the problem description obtained after the setup step. A simulator consists of a driver function (i.e., the main program or entry point) and of the solver fixed library, referred to as libsolver.
The default driver in the SPARK distribution solves a single problem using:
- the run controls specified in the *.run file, and
- the solution settings specified in the *.prf file.
There are two ways of loading the problem description for the driver function to solve the set of equations:
The static build approach consists in compiling and linking the problem.cpp file with the solver library and the driver function in order to produce a self-contained executable simulator. The atomic classes that appear in the solution sequence also need to be compiled and linked along. This approach is referred to as static build because the solution sequence is "constructed" during the compilation and linkage steps before runtime.
The dynamic build approach consists in loading the problem description at runtime from the problem.xml file. Then, the C++ funtions defined in the atomic classes appearing in the solution sequence are retrieved by solver using explicit linking of the dynamic libraries. This approach is referred to as dynamic build because the solution sequence is "constructed" dynamically at runtime.
