2nd order time stepping

[abarret]

We need to be more careful about how we compute the right hand side for time stepping. Currently, the pressure and divergence terms are included when computing the RHS. We can not use strictly the same operator for computing the RHS as we do for computing the solution of the system.

@bindi-nagda, take a look at the branch fix_rhs_timestepping. I've been able to get first order accuracy in time. Try it out with the test problems that you have and see if you can also get first order accuracy. For some reason, I still can't get second order accuracy.

[bindi-nagda]

Using that branch, I also get first order accuracy with the test problem I have (variable Thn).

[bindi-nagda]

@abarret Do we need to evaluate the pressure term at half_time?

[abarret]

No. The pressure at time $t_{n+1}$ should be independent of the pressure at time $t_n$. It's only role is to enforce incompressibility.

The only thing that needs to be time stepped is the viscous terms and the drag.

[bindi-nagda]

Okay. I was thinking that since we're using the midpoint rule for the forcing functions, we could treat grad P in the same manner.

[bindi-nagda]

So I think I've found the (really simple) correction needed. I changed the lines below https://github.com/abarret/multiphase-stokes/blob/6091d6ace981884d2cfecac73de0072d34dbaeda/INSVCTwoFluidStaggeredHierarchyIntegrator.cpp#L636-L638

to the following:

    if (d_f_un_fcn) d_f_un_fcn->setDataOnPatchHierarchy(f_un_idx, d_f_un_sc_var, d_hierarchy, half_time);
    if (d_f_us_fcn) d_f_us_fcn->setDataOnPatchHierarchy(f_us_idx, d_f_us_sc_var, d_hierarchy, half_time);
    if (d_f_p_fcn) d_f_p_fcn->setDataOnPatchHierarchy(f_p_idx, d_f_cc_var, d_hierarchy, new_time);

which makes sense given our system of equations.

Now I get 2nd order accuracy for problems with variable Thn and with more complicated problems with uniform Thn.

[abarret]

Nice catch. Hopefully the time stepping fixes the issues with the four roll mill.

[bindi-nagda]

Thanks! Yeah, I am not seeing symmetry-breaking in the simulation anymore, and the pressure remains symmetric. Do you want to push the change to fix_rhs_timestepping and then we can merge to timestepping?

[abarret]

Sure. I can clean it up. How is the performance of the solver?

[bindi-nagda]

The solver stalls out at 10e-6 for each time step. If the rtol is set to 10e-5, then it takes the solver 3-4 iterations per time step to converge to this value.

[abarret]

The solver stalls out at 10e-6 for each time step. If the rtol is set to 10e-5, then it takes the solver 3-4 iterations per time step to converge to this value.

That could make doing adequate convergence tests difficult (because the solution can't get more accurate than the solver tolerance).

It should mean that we're not completely smoothing the solution. One thing to check is that we are generating the correct coarsest level with the multigrid solver. Assuming that we are, we then need to assess the performance of F_cycle vs V_cycle and determine how many sweeps will adequately smooth the solution.

[abarret]

Closed by #38