• MOOSE was originally created to solve fully-coupled systems of PDEs.
• Not all systems need to be / are fully coupled:
• Multiscale systems are generally loosely coupled between scales.
• Systems with both fast and slow physics can be decoupled in time.
• Simulations involving input from external codes might be solved somewhat decoupled.
• To MOOSE these situations look like loosely-coupled systems of fully-coupled equations.
• A MultiApp allows you to simultaneously solve for individual physics systems.

• Each "App" is considered to be a solve that is independent.
• There is always a "master" App that is doing the "main" solve.
• A "master" App can then have any number of MultiApps.
• Each MultiApp can represent many (hence Multi!) "sub-apps".
• The sub-apps can be solving for completely different physics from the main application.
• They can be other MOOSE applications, or might represent external applications.
• A sub-app can, itself, have MultiApps... leading to multi-level solves.

Input File Syntax

• MultiApps are declared in the MultiApps block.
• They require a type just like any other block.
• app_type is required and is the name of the MooseApp derived App that is going to be run. Generally this is something like AnimalApp.
• A MultiApp can be executed at any point during the master solve. You set that using execute_on to one of: initial, residual, jacobian, timestep_begin, or timestep.
• positions is a list of 3D coordinate pairs describing the offset of the sub-application into the physical space of the master application. More on this in a moment.
• You can either provide one input file for all the sub-apps... or provide one per position.

[MultiApps]
[./some_multi]
type = TransientMultiApp
app_type = SomeApp
execute_on = timestep_end
positions = '0.0 0.0 0.0
0.5 0.5 0.0
0.6 0.6 0.0
0.7 0.7 0.0'
input_files = 'sub.i'
[../]
[]


• If you are building with dynamic libraries (the default) you may load other applications without explicitly adding them to your Makefile and registering them.
• Simply set the proper Type in your input file (e.g. AnimalApp) and MOOSE attempt to find the other library dynamically
• You may specify a path (relative preferred) in your input file using the parameter library_path. This path needs to point to the lib folder underneath your application.
• You may also set an environment variable for paths to search: MOOSE_LIBRARY_PATH
• Note: You will need to compile each application separately since the Makefile does not have any knowledge of the dependent application.

TransientMultiApp

• Some of the currently-available MultiApp are TransientMultiApp and FullSolveMultiApp.
• A TransientMultiApp requires that your "sub-apps" use an Executioner derived from Transient.
• A TransientMultiApp will be taken into account during time step selection inside the "master" Transient executioner.
• By default, the minimum dt over the master and all sub-apps is used.
• However we have the ability to do "sub-cycling", which allows a sub-app to take multiple time steps during a single master app time step.

Positions

- The positions parameter allows you to define a "coordinate offset" of the sub-app's coordinates into the master app's domain. - You must provide one set of $$(x, y, z)$$$coordinates for each sub-app. - The number of coordinate sets determines the actual number of sub-applications. - If you have a large number of positions you can read them from a file using positions_file = filename. - You can think of the $$(x, y, z)$$$ coordinates as a vector that is being added to the coordinates of your sub-app's domain to put that domain in a specific spot within the master domain. - If your sub-app's domain starts at $$(0,0,0)$$\$ it is easy to think of moving that point around using positions. - For sub-apps on completely different scales, positions is the point in the master domain where that App is.

Parallel

• The MultiApp system is designed for efficient parallel execution of hierarchical problems.
• The master application utilizes all processors.
• Within each MultiApp, all of the processors are split among the sub-apps.
• If there are more sub-apps than processors, each processor will solve for multiple sub-apps.
• All sub-apps of a given MultiApp are run simultaneously in parallel.
• Multiple MultiApps will be executed one after another.