Home
Latest version 0.6.0, released August 29, 2013
Known to work with:
- OpenFOAM 1.6-ext
- OpenFOAM 1.7.x
- OpenFOAM 2.0.x
- OpenFOAM 2.1.x
- OpenFOAM 2.2.x
multiSolver is an extension to OpenFOAM® that allows you to create a superSolver composed of multiple solvers within a superLoop. All solvers operate on the same dataset in sequence. For example:
- icoFoam - runs to completion;
- data is handed over to scalarTransportFoam;
- scalarTransportFoam - runs to completion;
- data is handed back to icoFoam, and the superLoop repeats.
You should not use multiSolver to combine the physics of two solvers. For example, say you want to model bubbles in a porous medium. That's like combining porousSimpleFoam with bubbleFoam. You might be tempted to use multiSolver for that, but don't.
Each time it switches between solvers, multiSolver writes everything to disk, clears the memory, then reloads everything all over again. This is not efficient. If you plan to switch between solvers at every timestep, multiSolver is not a good idea. Rather, you should write a single solver that combines them within its algorithm.
- Multiple solvers - multiple solvers can be used in sequence on the same data set.
- Changing boundary conditions - the boundary conditions can change at distinct time intervals.
- Independent time - each solver can operate with an independent time value, although universal time can still be used.
- Single case directory - the settings for all solvers are stored within a single case directory using a "multiDict" dictionary format.
- Easy data management - All the data output is sorted into subdirectories corresponding to the solver, and can be loaded / unloaded using the post processing utility.
- Store fields - To save memory and hard drive space, not all solvers have to use all the fields. Rather, they can "store" any unneeded fields, leaving more memory and disk space. The next solver retrieves all stored fields, and no data is lost.
A fundamental assumption in the design of OpenFOAM is the existence of a universal time. Therefore the time object is the top-level objectRegistry (i.e. runTime hosts the database for your simulation). This design works for nearly all simulations imaginable, except for those that require more than one time frame. For these situations, multiSolver will come in handy.
The capabilities of multiSolver are useful for:
- multi-step processes to be modelled within a single application, e.g. fluid injection, followed by settling;
- modelling of a flow problem characterized by two different timescales, e.g. stirring with biochemical reactions; and
- changing boundary conditions mid-run.
- frequently copying data between case directories;
- frequently stopping and changing the simulation details, then restarting; or
- using runTime++ more than once in your solver,
- "I'm sold, let me install it!" - Check out the installation sub-page.
- "I'm a user. How do I work with a 'superSolver'?" Check out the user's guide sub-page.
- "How do I post-process a 'superSolver'?" Check out the post processing sub-page.
- "One processor is for losers. How do I work with it in parallel?" Check out the parallel sub-page.
- "I'm a developper. How do I program with multiSolver?" Check out the programming sub-page.
NOTE: At this time, multiSolver allows for mesh motion, provided the mesh returns to its original position between solvers. This functionality is planned for the future.
- 2010-07-23: Initial import
- 2011-03-29: Minor bug fix for 1.6-ext and 1.7.1
-
2011-04-05:
- Major upgrade
- Now works for parallel simulations
- Major upgrade
-
2011-06-03:
- Minor bug fix:
- Parallel decomposing no longer omits the initial directory
- Minor bug fix:
- 2011-07-01: Overhauled documentation; no change to code
-
2012-10-25: Version 0.5.0
- Moved to git
- Enabled boundary switching
- Introduced version numbers to keep track of changes
-
2013-08-29: Version 0.6.0
- Uploaded to github and OpenFOAM-extend
- Restructured applications and tutorials directories for consistency
- Made opening splash optional