MultiApp Execution Order Control: At initial step $t_0$ solve $μ$ first, then Stokes; later steps only solve Stokes once at the end

[bo-qian]

Desired timeline:

• At initial step $t_0$:

  1. Given $C^0$, first solve $\mu^0$ (run once, sub_app_1),
  2. Then solve Stokes with $C^0, \mu^0$ to get $u^0, p^0$ (sub_app_2),
  3. Then proceed with normal time stepping.

• At step $n \ge 1$:

  1. Based on $u^{n-1}, p^{n-1}$, the parent CH app computes $C^n, \mu^n$,
  2. Only at TIMESTEP_END solve Stokes to get $u^n, p^n$.

In short: at $t_0$, $μ$ must be solved before Stokes; later Stokes should only run once at TIMESTEP_END.

---

My current setup and issue

Input file snippet:

[MultiApps]
  [./Mu_Initial]
    type = FullSolveMultiApp
    input_files = ${mu_input}
    execute_on = 'INITIAL'
    clone_parent_mesh = true
  [../]
  [./Stokes]
    type = FullSolveMultiApp
    input_files = ${stokes_input}
    execute_on = 'INITIAL TIMESTEP_END'
    clone_parent_mesh = true
  [../]
[]

[Transfers]
  [./CToMu]
    type = MultiAppCopyTransfer
    to_multi_app = Mu_Initial
    source_variable = c
    variable = c
  [../]
  [./MuToC]
    type = MultiAppCopyTransfer
    from_multi_app = Mu_Initial
    source_variable = mu 
    variable = mu
  [../]
  [./CHToStokes]
    type = MultiAppCopyTransfer
    to_multi_app = Stokes
    source_variable = 'c mu c_mid'
    variable = 'c mu c_mid'
  [../]
  [./StokesToCH]
    type = MultiAppCopyTransfer
    from_multi_app = Stokes
    source_variable = 'u v p' 
    variable = 'u v p'
  [../]
[]

Log output at initial step:

Currently Executing
  Performing Initial Setup
    Finished Initializing MultiApps                                                      [  2.02 s] [ 1109 MB]

Transfers on INITIAL To MultiApps:
-----------------------------------------------------------
|    Name    |         Type         |  From  |     To     |
-----------------------------------------------------------
| CToMu      | MultiAppCopyTransfer | Parent | Mu_Initial |
| CHToStokes | MultiAppCopyTransfer | Parent | Stokes     |
-----------------------------------------------------------
Transfers on INITIAL Are Finished

No Transfers on INITIAL Between MultiApps

Executing MultiApps on INITIAL
Warning:  This MeshOutput subclass only supports meshes which have been serialized!
Warning:  This MeshOutput subclass only supports meshes which have been serialized!
Mu_Initial0:     |residual|_2 of individual variables:
Mu_Initial0:                          mu: 791.908
Mu_Initial0:  0 Nonlinear |R| = 7.919081e+02
Mu_Initial0:       0 Linear |R| = 7.919081e+02
Mu_Initial0:       1 Linear |R| = 4.564458e-12
Mu_Initial0: default_nonlinear_convergencenl0: Converged due to relative/normalized residual norm 5.75848e-15 < relative tolerance (1e-08)
Mu_Initial0:     |residual|_2 of individual variables:
Mu_Initial0:                          mu: 4.56018e-12
Mu_Initial0:  1 Nonlinear |R| = 4.560185e-12
Mu_Initial0:  Solve Converged!
Subapp Mu_Initial0 solve converged!
Stokes0: default_nonlinear_convergencenl0: Converged due to residual norm 0 < 1e-07
Stokes0:     |residual|_2 of individual variables:
Stokes0:                           u: 0
Stokes0:                           v: 0
Stokes0:                           p: 0
Stokes0:  0 Nonlinear |R| = 0.000000e+00
Stokes0:  Solve Converged!
Subapp Stokes0 solve converged!
Finished Executing MultiApps on INITIAL

Transfers on INITIAL From MultiApps:
-----------------------------------------------------------
|    Name    |         Type         |    From    |   To   |
-----------------------------------------------------------
| MuToC      | MultiAppCopyTransfer | Mu_Initial | Parent |
| StokesToCH | MultiAppCopyTransfer | Stokes     | Parent |
-----------------------------------------------------------
Transfers on INITIAL Are Finished

From this log it is clear that:

• Both CToMu and CHToStokes are transferred at INITIAL,
• Both Mu_Initial and Stokes sub-apps are executed together at INITIAL,
• Finally both transfers back (MuToC, StokesToCH) happen.

As a result, Stokes does not use the $μ$ computed by Mu_Initial, but instead the parent’s initial $μ$, leading to wrong results.

---

My questions

1. Is there a way to enforce strict execution order of MultiApps at INITIAL (e.g. run Mu_Initial before Stokes)?

2. If execution order is not guaranteed with execute_on = INITIAL, do I need to restructure:

   • Split into two Stokes MultiApps (Stokes_init for $t_0$ only, Stokes_step for later steps), or
   • Use a nested MultiApp (Stokes as a child of Mu_Initial)?

3. The documentation explains execution order for TIMESTEP_BEGIN and TIMESTEP_END, but is less clear about INITIAL. What is the recommended practice to enforce this strict $t_0$ sequence?

Thanks!

[GiudGiud]

Hello

Is there a way to enforce strict execution order of MultiApps at INITIAL (e.g. run Mu_Initial before Stokes)?

No there are no execution order groups for multiapps.
What you could do is not solve Stokes on initial, just solve it on timestep_begin (could be an option? It s right after INITIAL) or end (then the initialization behavior is different).

You could also set start_time/end_time parameters in each multiapps to make sure the first one is executed before the second.
It's roughly the same thing as suggested above though.

We have a need for this #31573, but it has not been developed yet

[bo-qian]

Thank you, I used two layers of sub-programs to solve the initial time step sequence issue.