Simulation Class ReferenceThe fundamental object of the simulation.
More...
#include <simulation.h>
Inheritance diagram for Simulation: 
[legend]Collaboration diagram for Simulation:
[legend]List of all members.
Detailed Description
The fundamental object of the simulation.
The Simulation class controls the execution of the simulation and organizes the information and data relating to the simulation. Each simulation contains exactly one instance of the Simulation class, which is declared in the lbflow::main() function. Most class within the simulation have access to the base simulation instance either directly (through a member pointer) or indirectly.
It makes sense to ask what the value of a variable is for the simulation (typically average value throughout the lattice) so Simulation inherits from VariableUser.
Constructor & Destructor Documentation
| Simulation::Simulation |
( |
|
) |
|
|
|
|
Creates an instance of Simulation.
Creates a new instance of the time controller (Simulation::tc) and starts the wall clock. Creates three new variables and adds them to Simulation::variables:
'i' the iteration number't' the physical time'm' the available memory
These are the 'global variables'. Other variables are defined by the modules that are loaded at runtime. - See also:
- Variable
VariableUser
section 2.3. Variables and dimensionality of the documentation overview
|
| Simulation::~Simulation |
( |
|
) |
|
|
|
|
Cleanly destroys an instance of Simulation.
|
Member Function Documentation
| void Simulation::addModuleAction |
( |
Module * |
m, |
|
|
void(*)(void *) |
action |
|
) |
|
|
|
|
Adds a module action to the internal list.
An action is a module method that is called at each iteration by Simulation::run(). Typical examples, for a module that defines a nodegroup would be the method which controls collision, and the method which controls propagation. A module may have other methods too, for example, one which defines a solid wall may also compute shear stress at the wall. It is important that the actions are carried out in the correct order; all collision actions must be carried out before the propagate action can be called for any module. Since it is not known until runtime which modules are to be loaded, or what actions the modules will define, LBflow provides a mechnism by which modules add their own actions to the simulation in the correct order.
When a module is initialized (via its initialize() method), this typically causes the module to add its actions to Simulation::actions by calling this method with a pointer to itself and a pointer to the action as arguments. The action is added to a std::map, with a pointer to the module as key. If this is the first action that the module has added, it will be in the map pointed to by the first position in the std::vector Simulation::actions. If it is the second, it will be put in the map in the second position etc. The position of an action can be controlled by 'padding' the actions vector with calls to functions that do nothing. - Parameters:
-
| m | a pointer to a module which has actions defined |
| action | a pointer to a function in module m (an action) |
- See also:
- Simulation::run()
section 2.2. Modules, Nodegroups and Nodes of the documentation overview
|
| void Simulation::addNodegroup |
( |
Nodegroup * |
ng |
) |
|
|
| void Simulation::addSteeredParameter |
( |
Steered * |
st |
) |
|
|
|
|
Adds a steerable parameter to the internal list.
The parameters that can be steered within LBflow are instances of the Steerable class. Steerable is templatized which makes it problematic to pass generically. To avoid this problem, Steerable implements the Steered interface, which is not templatized. When a Steerable parameter is declared, the constructor Steerable::Steerable() calls this function with a pointer to itself (polymorphically resolved as a pointer to the abstract superclass) as argument. This function adds the pointer to the std::vector Simulation::steered_parameters.
Simulation::outputModInfo() and Simulation::writeToSim() use the list of steered parameters to inform the user, respectively, which parameters may be steered and which parameters are being steered in this simulation.
NOTE: all steerable parameters are added to the list of steered parameters, regardless of whether or not that are actually steered in this simulation. - Parameters:
-
| st | a pointer to a steerable parameter |
- See also:
- Steerable
Steered
section 3.1.1. Steerable parameters of the documentation overview
|
| void Simulation::addVariable |
( |
Variable * |
v |
) |
|
|
|
|
Adds a variable to the internal list.
The variables used within the simulation are defined in Simulation::Simulation() (global variables) and the constructors of loaded modules. When they are defined, this function is called with a pointer to the variable as argument. The variable pointer is added to the std::map Simulation::variables with the variable symbol as key. Before the variable is added, the map of variables is checked for variables with the same symbol. If a variable is found with the same symbol, but an incompatible definition, an informative Exception is thrown.
- Parameters:
-
- See also:
- Simulation::getVariable()
Variable
section 2.3. Variables and dimensionality of the documentation overview
|
|
|
Adds a component which uses variables to the internal list.
The components of the simulation for which it makes sense to ask the value of a variable implement the VariableUsers interface. The major ones (typically modules) add themselves to the std::vector Simulation::variable_users. They do this by calling this method from their constructors with a pointer to self as argument. This allows the simulation to determine the value of a variable throughout the entire domain, usually for output. - Parameters:
-
- See also:
- Simulation::getVariableUser()
Simulation::updateValueInVariable() (and Simulation::getVariableValue())
section 2.3. Variables and dimensionality of the documentation overview
|
| void Simulation::createLattice |
( |
Parser * |
p |
) |
[private] |
|
|
|
Read a lattice from the input simulation file.
An auxiliary method which determines from the simulation file which lattice is required, then creates and returns it. - Parameters:
-
| p | a parser encapsulating the input simulation file |
- See also:
- Simulation::read()
Simulation::
|
| list< Event * > * Simulation::getEvents |
( |
|
) |
|
|
|
|
Get a list of the events defined for the simulation.
- Returns:
- a pointer to Simulation::events
|
| Lattice * Simulation::getLattice |
( |
|
) |
|
|
| Mapping * Simulation::getMapping |
( |
|
) |
[static] |
|
| Nodegroup * Simulation::getNodegroup |
( |
string |
label |
) |
|
|
|
|
Get a nodegroup defined for the simulation.
A label should be defined for each nodegroup in the input simulation file so that the nodegroup can be referred to elsewhere in the file. This can be used to place other nodes, or to specify nodegroup specific output - Parameters:
-
| label | the label for the nodegroup, as defined in the input simulation file |
- Returns:
- a pointer to the corresponding nodegroup. If the label is not found, an Exception is thrown
- See also:
- Locus and Locus::labels
|
| vector< Nodegroup * > * Simulation::getNodegroups |
( |
|
) |
|
|
|
|
Get the time controller used by the simulation.
- Returns:
- a pointer to Simulation::tc
|
| Variable * Simulation::getVariable |
( |
string |
v |
) |
|
|
|
|
Get a variable defined for the simulation.
- Parameters:
-
| v | the symbol for a variable (e.g. 't' is the simulation time) |
- Returns:
- a pointer to the variable corresponding to the symbol v
- See also:
- Simulation::hasVariable()
|
| string Simulation::getVariableValue |
( |
Variable * |
v |
) |
[virtual] |
|
| void Simulation::haltSimulation |
( |
string |
why_stopped |
) |
|
|
| bool Simulation::hasVariable |
( |
string |
v |
) |
|
|
| void Simulation::initialize |
( |
|
) |
[private] |
|
| bool Simulation::isHalted |
( |
|
) |
|
|
| Module * Simulation::loadModule |
( |
string |
s |
) |
[private] |
|
| void Simulation::outputModInfo |
( |
string |
mod |
) |
|
|
|
|
Write information about the module to standard out.
Loads the module and interrogates is for information about the variables and steerable parameters it defines, and any other helpful information it holds. Outputs this information to the command line. This allows users to determine salient information about a precompiled module when they do not have access to the code. Invoked using the command: lbflow -m /path/to/module
- Parameters:
-
| mod | a string giving the path to a module e.g. /home/user/me/lbflow/modules/mod_a |
- See also:
- Module::info()
|
| void Simulation::read |
( |
Parser * |
p |
) |
|
|
|
|
Reads the input simulation file.
The parser p encapsulates the input simulation file. This method uses the parser to read the input and sets up the simulation accordingly. The method parses the file for keywords. When a keyword is read, the parser is typically passed on to another method or class which parses the relevant information. Calls initialize() when the parsing is complete, then deletes the parser.
If an illegal token is encountered, Parser::chuck() is called, causing an Exception to be thrown. Some commands must be carried out before others can be parsed. If commands are encountered out of order in the simulation file, an informative Exception is thrown.
NOTE: legacy code is included to allow parsing of old simulation files. Support for deprecated commands may be removed in a later release. - Parameters:
-
| p | a pointer to a Parser for the input simulation file |
- See also:
- section 3.1. Input of the documentation overview
|
| void Simulation::readEvent |
( |
Parser * |
p |
) |
[private] |
|
|
|
Read an event from the input simulation file.
An auxiliary method called by Simulation::read() to deal with the reading of events. Creates new events and adds them to Simulation::events - Parameters:
-
| p | a parser encapsulating the input simulation file |
- See also:
- Simulation::read()
|
| void Simulation::readModule |
( |
Parser * |
p |
) |
[private] |
|
| void Simulation::removeModule |
( |
Module * |
mod |
) |
|
|
| void Simulation::removeNodegroup |
( |
Nodegroup * |
ng |
) |
|
|
| string Simulation::updateValueInVariable |
( |
Variable * |
v |
) |
[virtual] |
|
|
|
Calculates the current value of a variable.
Updates the variable v to reflect the current value of the variable within the simulation. If the variable is one of 'i' 't' or 'm' the value is updated locally. For other variables, the updateValueInVariable() method is called for each VariableUser in the Simulation::variable_users vector in turn, with the variable as argument. Note that calls to this method may be expensive for these variables because the variable may have to be updated for every node in the simulation. - Parameters:
-
| v | a pointer to the variable to be updated |
- Returns:
- a string representation of the updated value of the variable, in physical units, to five significant figures
- See also:
- section 2.3. Variables and dimensionality of the documentation overview
Variable for a discussion of the meaning of the arguments to the Variable::getValue() function
Reimplemented from VariableUser. |
| string Simulation::whyStopped |
( |
|
) |
|
|
| void Simulation::writeToSim |
( |
ostream & |
os |
) |
|
|
|
|
Writes the simulation (checkpoint).
A valid simulation file encapsulating the current state of the simulation is written to the output stream os. This facilitates checkpointing, i.e. the simulation can be restarted from the written simulation. Output will usually be in response to a user-defined output(simulation){...} block specified in the original input simulation file, in which case this method is called by the OutpuSimulation::writeDetails() method.
The output starts with metadata describing the version of LBflow and modules loaded. The current values of parameters that are steered are also written. The components of the simulation are then written sequentially by calling their writeToSim() methods. Components are written in the order: lattice, mapping, modules, timecontroller, events.
- Parameters:
-
| os | a reference to the output stream to which simulation is written |
- See also:
- OutputSimulation
sections 3.2.2. User-specified outputs and 3.2.3. Checkpoints of the documentation overview
|
Member Data Documentation
|
|
Why the simulation ended.
If the simulation is about to end, a description of the reason for halting, else, an empty string |
|
|
Discrete lattice on which the simulation takes place.
|
|
|
Handles the mapping between simulation units and physical units.
Only one mapping is allowed in the simulation. Static to allow access from static contexts. - See also:
- section 2.3. Variables and dimensionality of the documentation overview)
|
|
|
Deals with timing within the simulation.
|
|
|
List of variables used in the simulation.
std::map of variables with variable symbol as key, e.g. 'i' is the key for the iteration number variable. - See also:
- section 2.3. Variables and dimensionality of the documentation overview
|
The documentation for this class was generated from the following files:
|
