Running benchmarks that require code
Running benchmarks that require code#
Some of the benchmarks require plugins like custom material models, boundary
conditions, or postprocessors. To not pollute ASPECT with all these
purpose-built plugins, they are kept separate from the more generic plugins in
the normal source tree. Instead, the benchmarks have all the necessary code in
.cc
files in the benchmark directories. Those are then compiled into a shared
library that will be used by ASPECT if it is referenced in a .prm
file. Let’s take the SolCx benchmark as an example (see Section The SolCx Stokes benchmark).
The directory contains:
solcx.cc
– the code file containing a material model “SolCxMaterial” and a postprocessor “SolCxPostprocessor”,solcx.prm
– the parameter file referencing these plugins,CMakeLists.txt
– a cmake configuration that allows you to compilesolcx.cc
.
To run this benchmark you need to follow the general outline of steps discussed in How to write a plugin. For the current case, this amounts to the following:
Move into the directory of that particular benchmark:
$ cd benchmarks/solcx
Set up the project:
$ cmake .
By default,
cmake
will look for the ASPECT binary and other information in a number of directories relative to the current one. If it is unable to pick up where ASPECT was built and installed, you can specify this directory explicitly this using-D Aspect\_DIR=$<$...$>$
as an additional flag tocmake
, where$<$...$>$
is the path to the build directory.Build the library:
$ make
This will generate the file
libsolcx.so
.
Finally, you can run ASPECT with solcx.prm
:
$ ../../aspect solcx.prm
where again you may have to use the appropriate path to get to the ASPECT
executable. You will need to run ASPECT from the current directory because
solcx.prm
refers to the plugin as ./libsolcx.so
, i.e., in
the current directory.