Difference between revisions of "Contrib multiSolver/programming"
(Created page with '== Programming with multiSolver == === solverDomains === A solverDomain is an individual solver loop. It is assigned a name, and the list …') |
(No difference)
|
Revision as of 16:43, 26 June 2010
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.
