Operations on numbers of scalar components of systems of equations.
Operations on numbers of scalar components of systems of equations, e.g. multiple equation sets of a physical model or a set of (stochastic ordinary or partial differential) equations of different kinds.
Problem: We are given a type that is a tk::
Example: An example is to define storage for systems of stochastic differential equations as in walker::
Solution: Looping through elements of a tuple is done via Brigand's [MetaProgramming Library]. Such operations on types happen at compile-time, i.e., the code runs inside the compiler and only its result gets compiled into code to be run at run-time. Advantages are abstraction and generic code that is independent of the size and order of the tags in the tuple (and the associated vectors). Though it is not of primary concern for this data structure, this solution also generates efficient code, since part of the algorithm (for computing the offset, the total number of components, etc.) runs inside the compiler. All of this is kept generic, so it does not need to be changed when a new pair of tag and system of equations are added to the underlying tuple. Thus, the main advantage is that changing the order of the vectors in the tuple or adding new ones at arbitrary locations will not require change to client-code.
An alternative approach: Of course this could have been simply done with a purely run-time vector of vector of integers. However, that would not have allowed a tag-based access to the different systems of equations. (Sure, one can define an enum for equation indexing, but that just adds code to what is already need to be changed if a change happens to the underlying data structure.) As a consequence, a component in a vector of vector would have had to be accessed as something like, ncomps, which is more error-prone to read than ncomps< tag::dirichlet >( 3 ). Furthermore, that design would have resulted in double-loops at run-time, instead of letting the compiler loop over the types at compile-time and do the run-time loops only for what is only known at run-time. Additionally, and most importantly, any time a new system is introduced (or the order is changed), all client-code would have to be changed.
template<typename... Tags>class tk::ctr::ncomponents
- Number of components storage.