Ordering of Subapps in a MultiApp System

[freiler]

Hello all,

I want to solve a problem of 3 equations in a decoupled manner using a Multiapp.

Subapp1 solves Equation 1. It needs u1 and provides u2.
Subapp2 solves Equation 2. It needs u2 and provides u3.
Subapp3 solves Equation 3. It needs u2 and u3, and provides u1.

Then, I would like to have a Master that calls the three subapp solves and dictates the ordering of the solves. It is important that the 3 equations are sequential.

Could someone please lead me to the way this can be done? Or maybe guide me to a good example that follows the same idea?
Thank you in advance,

Ramiro

[YaqiWang]

You can have a main app set equation 2 as the subapp, then add equation 1 as a subapp of the equation 2 subapp on timestep_begin, add equation 3 as a subapp of the equation 2 subapp on timestep_end. Eq. 1 and Eq. 3 input are on the same level of app tree, i.e. both subapps of the first level subapp of Eq. 2.

[zachmprince]

Yaqi's comment might be a little confusing, so here is a visualization:

              u1               u3
[ SubApp1 ]<------[ MainApp ]----->[ SubApp2 ]
[ (Eq.1)  ]------>[ (Eq.2)  ]<-----[ (Eq.3)  ]
              u2               u1

For the ordering, set SubApp1 execute_on = timestep_begin and SubApp2 execute_on = timestep_end

[freiler]

This makes sense. Thank you very much for your answers!

[freiler]

Following @zachmprince comment above:

Yaqi's comment might be a little confusing, so here is a visualization:

              u1               u3
[ SubApp1 ]<------[ MainApp ]----->[ SubApp2 ]
[ (Eq.1)  ]------>[ (Eq.2)  ]<-----[ (Eq.3)  ]
              u2               u1

For the ordering, set SubApp1 execute_on = timestep_begin and SubApp2 execute_on = timestep_end

I would like to transfer u1 in the scheme above to SubApp1 before the timestep ends, so that u1 is available for the upcoming timestep to properly solve for u2.

Is there any way to do this?

Thank you!

[freiler]

The transfer in order should happen in the following way:

u2 From SubApp1 to MainApp
u3 & u2 From MainApp to SubApp2
u1 From SubApp2 to SubApp1 (somehow)

Then a new iteration may start.

[zachmprince]

As long as you don't set the execute_on flag in the transfer, the order of operation should be:

1. Transfer to_multiapp
2. Solve multiapp
3. Transfer from_multiapp

So if your input looks like this in the mainapp:

[MultiApps]
  [SubApp1]
    type = FullSolveMultiApp
    input = sub1.i
    execute_on = timestep_begin
  []
  [SubApp2]
    type = FullSolveMultiApp
    input = sub2.i
    execute_on = timestep_end
  []
[]

[Transfers]
  [u1_to_sub1]
    type = MultiAppCopyTransfer
    multiapp = SubApp1
    direction = to_multiapp
    to_variable = u1
    from_variable = u1
  []
  [u2_from_sub1]
    type = MultiAppCopyTransfer
    multiapp = SubApp1
    direction = from_multiapp
    to_variable = u2
    from_variable = u2
  []
  [u2_u3_to_sub2]
    type = MultiAppCopyTransfer
    multiapp = SubApp2
    direction = to_multiapp
    to_variable = 'u2 u3'
    from_variable = 'u2 u3'
  []
  [u1_from_sub2]
    type = MultiAppCopyTransfer
    multiapp = SubApp2
    direction = from_multiapp
    to_variable = u1
    from_variable = u1
  []
[]

The order of operations will be:

1. Transfer u1 to SubApp1 from MainApp
2. Solve SubApp1
3. Transfer u2 to MainApp from SubApp1
4. Solve MainApp
5. Transfer u2 and u3 to SubApp2 from MainApp
6. Solve SubApp2
7. Transfer u1 to MainApp from SubApp2

Repeated until convergence

[freiler]

@zachmprince thank you so much! I think I got it now.

[freiler]

@YaqiWang @zachmprince Thank you both for your answers Yaqi and Zach. This solves my current problem.

A follow-up question on this would be if there is another way to order a sequence of subapps than using the "execute_on" option. My question aims at what would happen for example if we needed to solve multiple uncoupled equations (at least more than 3). The 'execute_on' option for multiple decoupled equations seems limited for a hypothetical case of this kind.

Thanks again,

Ramiro

[zachmprince]

execute_on is the only way to order the apps from the main app. But you can use a nested multiapp structure to facilitate more control on the ordering. Something like in this image: https://mooseframework.inl.gov/workshop/?_ga=2.38902757.731230092.1603987117-130448754.1603987117#/51/3

[ragusa]

Thanks. To avoid repeating this until convergence, I suppose we can limit the Picard iterations. This should be done at the master input, I think. In which block and what’s that syntax? Thanks! —jean ragusa http://multiphysics.engr.tamu.edu http://nustem.engr.tamu.edu -.-.- iPhone, iTypo, iApologize. On Nov 13, 2020, at 12:50 PM, Zachary Prince <[email protected]> wrote:  As long as you don't set the execute_on flag in the transfer, the order of operation should be: 1. Transfer to_multiapp 2. Solve multiapp 3. Transfer from_multiapp So if your input looks like this in the mainapp: [MultiApps] [SubApp1] type = FullSolveMultiApp input = sub1.i execute_on = timestep_begin [] [SubApp2] type = FullSolveMultiApp input = sub2.i execute_on = timestep_end [] [] [Transfers] [u1_to_sub1] type = MultiAppCopyTransfer multiapp = SubApp1 direction = to_multiapp to_variable = u1 from_variable = u1 [] [u2_from_sub1] type = MultiAppCopyTransfer multiapp = SubApp1 direction = from_multiapp to_variable = u2 from_variable = u2 [] [u2_u3_to_sub2] type = MultiAppCopyTransfer multiapp = SubApp2 direction = to_multiapp to_variable = 'u2 u3' from_variable = 'u2 u3' [] [u1_from_sub2] type = MultiAppCopyTransfer multiapp = SubApp2 direction = from_multiapp to_variable = u1 from_variable = u1 [] [] The order of operations will be: 1. Transfer u1 to SubApp1 from MainApp 2. Solve SubApp1 3. Transfer u2 to MainApp from SubApp1 4. Solve MainApp 5. Transfer u2 and u3 to SubApp2 from MainApp 6. Solve SubApp2 7. Transfer u1 to MainApp from SubApp2 Repeated until convergence — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/idaholab/moose/discussions/16141*discussioncomment-128906__;Iw!!KwNVnqRv!Wsz1WSRVbPh_dl643bnIVRrOM6i_pmtwhfq7yOUvba5j4owMbMKZJjX2hgEFXzxG8w$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAEMAJG6BQ5HW2QASKBAN5DSPV5VPANCNFSM4TQ27IVQ__;!!KwNVnqRv!Wsz1WSRVbPh_dl643bnIVRrOM6i_pmtwhfq7yOUvba5j4owMbMKZJjX2hgF_TbPCaA$>.

[zachmprince]

Here are all the options regarding picard iterations:

You can find more details here

[zachmprince]

Oh sorry, this is in the [Executioner] block