MercuryDPM
Alpha
|
A driver file usually contains a class derived from Mercury3D in which the concrete parameters of the application are defined, such as species, particles, walls, boundaries, time step, ..., and a main function where the class is declared and the time integration routine (solve) is called. Thus, the basic setup looks like this:
This file defines a class named Example
, that is derived from Mercury3D
. It overrides the function setupInitialConditions (which is empty by default) with a function where the simulation objects (particles, walls, boundaries, species) are defined.
Then the main function is defined (which is the function that is executed when you run the executable): First, the Example class is instantiated (a concrete instance of the class is created and stored in memory). Then, the global variables are set, such as name, gravity, spatial/temporal domain. Finally, the time integration routine (solve) is called.
The following global variables should be set:
The first command sets the name variable to Example, so the output files will be named Example.data
, Example.restart
, ... The next six commands set the dimensions of the system that are used in displaying the output. Finally, the final time and the time step are set.
There are additional global parameters that can be set here, such as
A species can be defined as follows:
Other contact laws are possible; see the documentation of Species for more details.
A particle can be defined as follows:
See the documentation of BaseParticle for more details.
A planar bottom wall at the bottom of the domain can be defined as follows:
Other walls are possible; see the documentation of WallHandler for more details.
A periodic boundary in x-direction can be defined as follows:
Other boundaries are possible; see the documentation of BoundaryHandler for more details.
In some cases it is not enough to define suitable initial conditions. This is done by overriding certain functions in the Mercury3D class, just as we are overriding setupInitialConditions.
For example, to define a criterium to stop the simulation, one can override the
In this case, the simulation is stopped as soon as the kinetic energy drops below 0.00001 times the elastic energy stored in the contact springs (a useful criteria to determine arresting flow).
For more examples, see Overriding functions.
While the above example works, we advise you to avoid the number of explicitly used parameters such as the tolerance inside the class definition. A good coding guideline is to define all parameters in one place (the main function), with the exception of the particles, walls and boundaries, so they can easily be found and changed later.
You can start a new driver code by creating your own user directory. First, chose a UserName
, then add a folder to the user directory and create a new source file, e.g. Example.cpp
, which for convenience is copied here from the file Tutorial1.cpp
. cd ~/MercurySource/Drivers/USER svn mkdir UserName cd UserName svn cp ../../Tutorials/Tutorial1.cpp Example.cpp
Now write your code in the Example.cpp file. Note, you cannot yet execute your code, as the Makefiles in your build directory doesn't know about the new file. To update your Makefiles, use cmake. Note, the file name of your source file has to be unique, otherwise you get error messages. cd ~/MercuryBuild cmake .
Now you can build and execute your new code: cd ~/MercuryBuild/Drivers/USER/UserName make Example
Note, as we currently only support MercuryDPM on Linux/Mac OS, these instructions are only valid for such systems.