Grid Sequencing

[lindsayad]

Reason

My motivation is for solving variational inequality problems, but as @fdkong points out grid sequencing can be generally useful for solving highly nonlinear problems. For VI problems, as noted by @bueler a solver is often unable to move the boundary of constraint activity by more than one grid cell per nonlinear iteration. As a consequence, the number of nonlinear iterations required to solve VI problems often scales with the number of grid cells or mesh elements. We can see this in action by running this input file on a progressively finer mesh. Here is a table of results for the number of non-linear iterations required to solve timestep 2 which is the first timestep where constraints become active:

nx	nls
100	5
200	9
400	17
800	34

@bueler has shown that using grid sequencing, which is the process of solving on progressively finer meshes using coarse grid solutions as starting points, the number of nls required to solve on progressively finer meshes more or less remains constant at least when using -snes_type vinewtonrsls.

Design

I think there might be multiple ways to do this. We could probably do this simply just using libMesh and MOOSE data structures, e.g. using Adaptivity. However, we could also probably leverage some of the newer libMesh interfaces to PETSc DM introduced in https://github.com/libMesh/libmesh/pull/2047#.

Impact

Make solution of inequality and/or highly non-linear problems more robust.

To-do list

• [ ] handle old solution data manually so we can do grid sequencing with PDEs involving time derivatives
• [ ] test grid sequencing on advection-diffusion problem (perhaps steady INS)

[fdkong]

It is scalable

[lindsayad]

Ok @fdkong I ran the vi-bounding.i problem with nx=400 for the sub-app and nx=800 for the master app. Solved the sub-app in 17 non-linear iterations which is consistent with the table above...and then after interpolating the sub-app solution to form the initial guess for the fine-mesh master application, that non-linear solve took 1 non-linear iteration 😄 😂

[lindsayad]

Taking it one step-further, I made a sub-app for the sub-app. The sub-sub-app ran with nx=200. So:

• 9 non-linear iterations on the nx=200 mesh
• 2 non-linear iterations on the nx=400 mesh after interpolating from the nx=200 solution
• 1 non-linear iteration on the nx=800 mesh after interpolating from the nx=400 solution

[fdkong]

Cool!

[lindsayad]

@bwspenc @dschwen @tophmatthews I believe this concept could be huge for mechanical contact problems

[tophmatthews]

huh....I'm in!

[friedmud]

Problem that I see with this is that in NL land the coarse grid might give a very different solution from the fine grid for real problems. Think about a BISON problem... the coarse grid would have a different temperature distribution and therefore would have different swelling/relocation which would cause contact to happen sooner/later than the fine mesh.

I'm having trouble seeing how this would help in any non-trivial application.

[lindsayad]

I'm having trouble seeing how this would help in any non-trivial application.

This seems like a sweeping statement without having tried it. As @fdkong mentioned solveing highly non-linear problems using grid sequencing is a standard practice. The point of the coarse grid solution is to generate an initial guess. A guess obtained from a coarse grid is certainly better than no guess at all. Sure it's not a "real" problem but if I just solve a diffuson-reaction problem with a reaction term of u^10 with no flux on the left and Dirchlet 1 on the right, I get 6 nonlinear iterations on a 400 element mesh. If I solve the 200 element problem first, and then use that as an initial guess for the 400 element problem, it takes 2 nonlinear iterations. I definitely think this shows enough promise to move forward and to at least try it on real applications before getting down on it.

[lindsayad]

Also even for a linear deformation problem with contact, resolving an active constraint can be difficult and this grid sequencing method shows clear promise for that case.

[bwspenc]

@lindsayad I agree about this potentially helping out a lot on mechanical contact problems, especially for frictional contact. I have observed the behavior you're talking about where the number of NL iterations is proportional to the size of the mesh. We often have cases where an initially stuck surface is pulled from one side, and could end up going to a completely slipping state in a single step. However, to transition to that state, you have to 'unzip' it from one side. In the worst case, a single new node on the edge of the stuck zone switches to a slipping state during each NL iteration. If you have a fine mesh, that can be a lot of NL iterations. This is the fundamental issue preventing us from widely using frictional contact in fuel problems.

As @friedmud points out, the solution on a coarse grid is probably different from the fine grid solution, but most of the time, it's probably close enough to greatly accelerate the iterations.

[lindsayad]

As @friedmud points out, the solution on a coarse grid is probably different from the fine grid solution, but most of the time, it's probably close enough to greatly accelerate the iterations.

👍

[fdkong]

I guess it should be fine to use a coarse mesh solution slightly different from the true solution because it is an initial guess. It will help Newton as long as it is still in the basin region. I am optimistic on this.

[friedmud]

@bwspenc I'm highly skeptical of using this for real problems (like for BISON). The coarse problem could contact earlier or later. There could be more or less axial swelling, more or less relocation, etc.

What do you do when the coarse problem goes into contact... but the fine problem isn't in contact yet (or vice-versa)?

[friedmud]

In general: mesh fidelity doesn't really seem to be the problem with getting things to converge with BISON. Really coarse meshes are already used...

[lindsayad]

We'll find out soon enough. I'm building a contact example right now.

[lindsayad]

Frictional contact problem with timestep 3 solution that looks like this:

Time to solve:

• no grid sequencing: 1m43s
• grid sequencing: 54s

Number of nls on fine grid:

• no grid sequencing: 12
• grid sequencing: 4

[fdkong]

three times faster

[lindsayad]

I'm actually going to reopen this, because there is currently a big flaw that I'm remembering. Currently during restriction/prolongation we lose information in _u_old and _u_older. This needs to be fixed per the discussion on the libmesh-users list.

[lindsayad]

So to be clear the grid sequencing code currently in MOOSE will not work any time _u_old or _u_older is involved in the function computation, e.g. if there are TimeDerivatives

[lindsayad]

I think this could help with limited finite volume problems where the limiter introduces significant nonlinearity. Currently convergence rates for HTR-PM are very slow with limiters. So I'm going to add this to TA support