Contrib multiSolver/programming
Contents
1 Programming with multiSolver
1.1 solverDomains
A solverDomain is an individual solver loop. It is assigned a name, and the list of names is static. All solverDomains must appear in the case/system/multiControlDict file.
1.2 Order of execution
In the simple example on the main page, all the solverDomains execute in sequence, once per superLoop. This is not necessary: you can enclose them in conditionals; they can execute in any order; they can miss entire superLoops; however, they cannot execute more than once per superLoop. Use: multiRun++ between solvers to increment the superLoop number if necessary.
1.3 runTime must go out of scope
Looking at the include files specified in the simple example on the main page, you will notice that the entire solver loop is enclosed in its own set of braces { }, starting at #include "createTime.H". This is necessary because runTime, the mesh, and all fields must go out of scope before multiSolver initializes another solverDomain.
1.4 Support classes
There are a few additional classes that were written to support multiSolver. These include:
- tuple2List class;
- timeCluster class;
- timeClusterList class; and
- dummyControlDict class.
tuple2List
This is a sortable list of paired values was created. It is sortable by first or second value, and currently can be any combination of scalar or label.
timeCluster
timeCluster is to multiSolver what instant is to runTime. Basically an object that can catalogue all the time data within a multiSolver-enabled application.
timeClusterList
Again, similar to instantList, for multiSolver.
dummyControlDict
In order to allow runTimeModification of multiSolver's multiDicts, multiSolver required an objectRegistry that doesn't dissappear between solverDomains, when runTime goes out of scope. Therefore it needed its own objectRegistry. Hence, multiDictRegistry_ is a Time object. Time was never intended to be a member variable, therefore its constructors do not allow initialization without a controlDict. The object dummyControlDict was introduced as a self-initializing, minimal controlDict. Ultimately it was necessary for global runTimeModification.
2 Implementation of multiSolver
2.1 storeFields
Some solverDomains may not need to use all the fields required by other solverDomains. Rather than carry the unused fields in memory and write them out at every output point, storeFields can be declared. storeFields works by copying the fields into the first time directory of that solverDomain for every superLoop. When the next solverDomain is initialized, the stored field is retrieved and pasted into the starting time directory for that superLoop.
storeFields is a wordList defined in multiSolverDict, under each solverDomain. One problem arises if the initial solverDomain has store fields - multiSolver would have no idea where to look for the storeFields. Therefore, the initial solverDomain must have all storeFields defined in its 0/0 directory.
