Impose steady-state solution as BC for transient evolution

[wehrad]

Hi everyone,

Application

simulating the elastic deformation of a material in different situations, I am first applying gravity to my domain at the first step to obtain a steady-state using a control as e.g. here.

My domain is infinitely long so I am using a periodic BC. However, because periodic, as soon as I apply a transient forcing resulting in the propagation of a deformation, this wave gets propagated through the boundary and back. This is expected, but problematic in my transient state because creating some fake deformation!

What I would like to do

I am currently loading my domain with periodic boundary conditions, and would like to use the solution of that steady state at the boundaries as boundary conditions for the rest of the simulation which is transient. And therefore turn off the periodicity after loading to prevent the periodic propagation of waves as described above. With the aim of having boundary conditions that actually makes sense, and that correspond to the loaded steady state.

What I have done so far

I am currently trying to achieve this with what sounds like a bad solution:

• Write out the solution after gravity loading
• Turn periodicity off
• Read the steady state solution and preset the displacement at the boundary

In practice, a sort of similar idea as in this Mastodon example where a csv file is used in a PresetAcceleration.... Except here the solution is nodal and not just a scalar...

But still, this solution sounds wrong and bad, writing out of MOOSE to read in again. I feel like there should be a way to extract the solution at a given timestep and given boundary, and preset it as a BC. All of that without I/O external to MOOSE.

Maybe there is something to do with a ADFunctionDirichletBC-like object but where the extracted time step at the boundary would be passed? Like a PostprocessorDirichletBC? But I can't find a way to extract my time step at boundary...

Any help/advice would be much appreciated! Thank you a lot in advance!

[GiudGiud]

Hello

There are a few options.
If you are ok with running both systems every time you may want to do a MultiApp setup.
The steady state will be a MultiApp and the transient solve will be the parent app. The steady state simulation will be executed at the beginning of the transient solve.
Then you integrate the steady state solution on both sides, using this for example
https://mooseframework.inl.gov/source/postprocessors/SideIntegralVariablePostprocessor.html

Then you transfer the output of this integration to a Receiver using these
https://mooseframework.inl.gov/source/transfers/MultiAppPostprocessorTransfer.html
https://mooseframework.inl.gov/source/postprocessors/Receiver.html

Then you use a PostprocessorDirichletBC if that is how this information is used in the transient solve boundaries.

Guillaume

[GiudGiud]

Yes you can set execute_on = initial on the multi app block for the steady state

[wehrad]

Oh yes I forgot about that one, thank you a lot! I'll to get this pipeline to work!

[wehrad]

Hi @GiudGiud, I have some time to work on this now again, and I think I'm making good progress into a multiApp to feed the steady state solution into the BC of the transient. However:

In practice, a sort of similar idea as in this Mastodon example where a csv file is used in a PresetAcceleration.... Except here the solution is nodal and not just a scalar...

Any ideas on this? You proposed using a https://mooseframework.inl.gov/source/postprocessors/SideIntegralVariablePostprocessor.html but I would ultimately like to pass the nodal values more than a scalar if possible?

Thank you a lot for your help!

[GiudGiud]

It's possible.
You just need to restrict a field transfer to a boundary, which will soon be straightforward but currently is not.

I see a few options:

• use a nearest node transfer with the boundary parameters
  https://mooseframework.inl.gov/source/transfers/MultiAppNearestNodeTransfer.html

• use a NodalValueSampler https://mooseframework.inl.gov/source/vectorpostprocessors/NodalValueSampler.html and save all the boundary values that you care about. Then transfer this vpp using this https://mooseframework.inl.gov/source/transfers/MultiAppVectorPostprocessorTransfer.html then write a custom auxkernel to move data from this VPP to your auxvariable. If it's a nonlinear variable instead it wont work

[wehrad]

Great thank you a lot for those/this option.s!

[wehrad]

Hi @GiudGiud,

I could implement the different points you shared to make a multiApp feeding the steady state solution into the BC of the transient. With a side integral for the moment.

I'm running transient_parent.i that uses steady_subapp.i and mesh.e. With cAr.sh which is a -dummy- wrapper for compilation and run, used here with ./cAr.sh -i transient_parent.i -c false -b 11.

However I get the following error:

*** ERROR ***
Unable to locate object: .

I found this issue but somehow can't understand because I don't see any multi_app parameter here... I struggle understanding this issue that I don't find extremely obvious, could you help on that? Is it because the default matching app_type is not found?

Thank you a lot for your help!

[GiudGiud]

Some parameter check must be failing in an obscure way. If you run this in a debugger it should point you to the object involved

[wehrad]

I am unfortunately a bit stuck in the debugging... I use gdb and set a breakpoint on abort, but then don't really know which variables to check.

Here is the gdb log:

*** ERROR ***
Unable to locate object: .

Stack frames: 15
0: libMesh::print_trace(std::ostream&)
1: moose::internal::mooseErrorRaw(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
2: void mooseError<char const (&) [26], std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const (&) [2]>(char const (&) [26], std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const (&) [2])
3: MooseObjectWarehouseBase<MultiApp>::getObject(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) const
4: FEProblemBase::getMultiApp(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const
5: FEProblemBase::addTransfer(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, InputParameters&)
6: AddTransferAction::act()
7: Action::timedAct()
8: ActionWarehouse::executeActionsWithAction(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
9: ActionWarehouse::executeAllActions()
10: MooseApp::runInputFile()
11: MooseApp::run()
12: /home/guschti/COEBELI/COEBELI_modelling/moose_projects/kiliffak/mastodon-dbg(+0xa7fb) [0x55555555e7fb]
13: __libc_start_main
14: /home/guschti/COEBELI/COEBELI_modelling/moose_projects/kiliffak/mastodon-dbg(+0xa089) [0x55555555e089]

Thread 1 "mastodon-dbg" hit Breakpoint 1, 0x00007fffe65af880 in PMPI_Abort ()
   from /home/guschti/mambaforge3/envs/moose/lib/libmpi.so.12

What I understand from the log is the problem is definitely coming from my transfer object trying to link to the subapp but fails, as expected initially.

[GiudGiud]

Can you paste the transfer and multi app blocks here? Looks like that s where the problem is. It might be due to the migration to the to_/from_multiapp parameter let’s check

…

Le 9 juin 2022 à 04:05, Adrien Wehrlé ***@***.***> a écrit :  I am unfortunately a bit stuck in the debugging... I use gdb and set a breakpoint on abort, but then don't really know which variables to check. Here is the gdb log: *** ERROR *** Unable to locate object: . Stack frames: 15 0: libMesh::print_trace(std::ostream&) 1: moose::internal::mooseErrorRaw(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) 2: void mooseError<char const (&) [26], std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const (&) [2]>(char const (&) [26], std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const (&) [2]) 3: MooseObjectWarehouseBase<MultiApp>::getObject(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) const 4: FEProblemBase::getMultiApp(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const 5: FEProblemBase::addTransfer(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, InputParameters&) 6: AddTransferAction::act() 7: Action::timedAct() 8: ActionWarehouse::executeActionsWithAction(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) 9: ActionWarehouse::executeAllActions() 10: MooseApp::runInputFile() 11: MooseApp::run() 12: /home/guschti/COEBELI/COEBELI_modelling/moose_projects/kiliffak/mastodon-dbg(+0xa7fb) [0x55555555e7fb] 13: __libc_start_main 14: /home/guschti/COEBELI/COEBELI_modelling/moose_projects/kiliffak/mastodon-dbg(+0xa089) [0x55555555e089] Thread 1 "mastodon-dbg" hit Breakpoint 1, 0x00007fffe65af880 in PMPI_Abort () from /home/guschti/mambaforge3/envs/moose/lib/libmpi.so.12 What I understand from the log is the problem is definitely coming from my transfer object trying to link to the subapp but fails, as expected initially. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[GiudGiud]

So since the data is in an auxiliary variable right now, we need some sort of CoupledDirichletBC that uses the coupleable interface to get the value of the auxxiliary variable at each local qp.

I dont see one in the framework, but I do see a coupledVarNeumannBC and regular dirichletBCs.

Could you try to make the coupledDirichletBC from there?

[wehrad]

Could you try to make the coupledDirichletBC from there?

I would be happy to try, yes, I will let you know how it goes! Thanks a lot.

[wehrad]

Hi @GiudGiud ! I ended up with an implementation that compiles successfully but being a new user of MOOSE I'm not sure of what I did at all. E.g. not sure CoupledVarDirichletBC should inherit from DirichletBCBase although it sounds like a good idea since the latter itself inherits from NodalBC, and I want to specify values at the node level. I brought the source and header file here: https://github.com/AdrienWehrle/moose/tree/next/examples/CoupledVarDirichletBC_dev (some variables in the header are not used in the source but for the moment I'm working mainly on the content rather than the form, which I will improve later).

I get somehow expected results but not completely (e.g. a weird small artifact of higher displacement in the next face parallel to the boundary in the domain as visible in the screenshot on the lower boundary).

Once I get to something I trust I will make a proper PR but just wanted to have your take on it before proposing something officially, if possible!

Thank you a lot for your help!

[GiudGiud]

CoupledVarDirichletBC inheriting from DirichletBCBase looks good to me.

Does the artefact go away with refinement?

[wehrad]

Does the artefact go away with refinement?

It looks like it did, yes! Or I mean, the interpolation on a coarse grid clearly amplified it. Thank you a lot for your precious help on this, I will propose a PR very soon for CoupledVarDirichletBC!