Possible to access MultiApp parameters from a sub-app?

[aprilnovak]

Hi all,

First, thanks for the responsiveness with all my questions related to wrapped apps recently, I appreciate it!

Per a previous discussion (#16680), I would like to only send a heat flux from a master app into a nekRS multi app if on the first time step of that subcycled nekRS app. We need to do a global communication and CPU->GPU copy on the nekRS end, so skipping that when interpolate_transfers = false will be helpful. Basically, what I'd like to do in syncSolutions is something like this:

neks_multi_app = somehowGetMultiappInMasterFile();

if (!neks_multi_app->firstStep() && !nekrs_multi_app->interpolateTransfers())
  return;

where I would add those functions to TransientMultiApp, such as:

bool TransientMultiApp::firstStep() { return _first; }

My master app input file looks like

[MultiApps]
  [nek]
    type = TransientMultiApp
    app_type = NekApp
    input_files = 'nek.i'
    interpolate_transfers = false # how to get this in NekApp?
  []
[]

Is it possible to access the TransientMultiApp from within NekProblem? Nothing in FEProblemBase or MooseApp stood out to me as allowing you to access a MultiApp not "below you." Maybe that's part of the design of MOOSE, for sub-apps to run with minimal knowledge of "where" they are in a tree to keep things agnostic.

[loganharbour]

April,

I do this a bit with MOC + DSA. You're correct with:

Maybe that's part of the design of MOOSE, for sub-apps to run with minimal knowledge of "where" they are in a tree to keep things agnostic.

I do it a bit dirty, in which that information can be passed within a transfer. Within my master application problem, I've got some additional checking that attempts to cast all of the transfers to my transfer of choice. If it is found - I've then got an interface to the other MultiApps. You could also have this transfer as an input to the problem.

I'm not sure that this is the best behavior, but with the idea of keeping all of the applications truly separate and only connecting them through transfers, I couldn't find a better solution.

[loganharbour]

Actually - disregard all of this. This the wrong direction 😆 (master seeing child), I believe you want child seeing master.

[aprilnovak]

Well I think a transfer could still be done into the child, like into a postprocessor or something? Like a Receiver, that receives "true" every time I'm at the transfers into nekRS at TIMESTEP_END, so then I could grab a postprocessor value from within NekProblem to get the information I need.

It definitely feels hacky, but I think it could work for my needs. But I feel that as the ExternalProblem interface sees more use in the future, that other users might run into similar barriers where they want the external problem synchronization (i.e. syncSolutions) to be more tied to the transfer of data than the solution of the external app. That might require some significant code design changes, though.

[aprilnovak]

FYI this ended up working, thanks for the inspiration! I ended up just having a Receiver (default = 1) postprocessor sent from master to child on timestep_end (which is when I run nekRS), that nekRS then overwrites internally with something like

if (_transfer_in_pp == true)
  setPostprocessorValueByName("transfer_in", false, 0);
else
  return;

// send heat flux in... 

[loganharbour]

Heh - glad to send you down the right path at least.

But I feel that as the ExternalProblem interface sees more use in the future, that other users might run into similar barriers where they want the external problem synchronization (i.e. syncSolutions) to be more tied to the transfer of data than the solution of the external app.

I definitely agree with this. I like the simplicity that comes with using Transfers for the overwhelming majority of synchronization between applications, but there probably needs to be some framework at the lower level like you need.