Build a SPARK problem simulator with a customized driver

The following diagram shows the operations involved in building a multi-problem simulator with a customized driver function implemented in the file mydriver.cpp. The resulting simulator mydriver.exe solves two different problems, described in the problem1.pr and problem2.pr files, respectively. To make matters more interesting in this example, the problem 1 is statically built whereas the problem 2 is dynamically built. Finally we note that the executable simulator relies on the dynamic solver library libsolver.dll at runtime.

The normal arrows indicate operations occurring before runtime whereas the bold arrows indicate the file dependencies at runtime when executing the simulator. Red font is used with system programs like the C++ compiler and linker. Blue font indicates the SPARK programs and files used in the build process.

Note:

• The dynamic solver library is called libsolver.so on UNIX/Linux platforms.
• The dynamic libraries containing the compiled atomic classes have the extension *.so on the UNIX/Linux platforms.
• The resulting executable simulator is called mydriver on the UNIX/Linux platforms.

Define a customized driver function

The overall build process essentially combines the static and dynamic build processes explained previously in Build a SPARK problem statically and Build a SPARK problem dynamically.

What's new concerns the process of explicitly specifying the driver function to be used by the executable simulator. First, the C++ source file mydriver.cpp where the driver function is implemented is compiled to produce the object file mydriver.o. Then the object file is linked along with the other object files for the atomic classes to generate the executable simulator mydriver.exe

To solve multiple problems in the same driver function, each problem topology must be described through a corresponding *.cpp file or *.xml file, depending on how the problem is to be built. There are no limitations as to how many different problem topologies (each defined in a different *.cpp file or *.xml file) can be used in the same driver function.

Of course, it is possible to instantiate multiple instances of the same problem topology (e.g., defined in the spring.xml file ) as long as each instance is assigned a unique name in the process space (e.g., one instance could be named "MySpring1" and the other instance "MySpring2").

Also, for each problem instance being simulated, corresponding *.run and *.prf files must be specified.

See Implementation of the SPARK Driver Function for more infomation on how to implement the driver function for a SPARK simulator using the problem driver API.

Automate the build process

The multiproblem.makefile automates this process of building a SPARK simulator involving multiple problems and a customized driver file. For example, in order to build the SPARK simulator from the driver function implemented in the file mydriver.cpp and involving the two problems named problem1.pr and problem2.pr, defined respectively in the directories ../problem1 and ../problem2, type at the command line:

     gmake -f multiproblem.makefile PROJ=mydriver SUBPROBLEMS="../problem1 ../problem2" <enter>

This will generate an executable simulator mydriver.exe as well as the needed dynamic libraries containing the compiled atomic classes. The makefile assumes that the problem files are located in directories with the same names.

See Multi-problem command file for a more detailed explanation of the multiproblem makefile.

Execute the simulator

The command line operation of the resulting simulator depends on the way main function and the customized driver function have been implemented in the source file mydriver.cpp.

---