Robustness of solver

[abarret]

It seems the solver works decently in #44, so in the interest of progress, we should proceed with what works. However, I don't understand why the changes that were implemented improve the solver, so it would be good to fully understand what the changes are doing. I'll summarize questions here.

The main changes are the introduction of different synchronizations inside the VCTwoFluidStaggeredStokesOperator::apply() function. There are three additional synchronizations, controlled by preprocessor flags.

1. USE_DIV synchronizes coarse-fine interfaces of the side centered quantity (ths*us + thn*un) before computing the divergence of the velocities. This seems to be necessary for solver convergence at coarse-fine interfaces.
2. USE_SYNCHED_INTERP uses a synchronized node and side interpolated version of the volume fractions to compute derivatives in the momentum equations. I don't think this is necessary, but I'm leaving it in for now.
3. POST_SYNCH performs an extra synchronization step at the end of the apply() function. Note this synchronization is not related to the coarse-fine interfaces. It is synchronizing the coarse level with the fine level. This also seems to be necessary for performance on L-shaped domains.

Case 3. above is my primary source of confusion. It makes sense to me that the underlying coarse level should be synchronized with the fine level, however, from what I can tell, no other solver in IBAMR performs this synchronization. We should investigate what change this is actually performing, and whether a similar step is occurring in IBAMR.

[bindi-nagda]

There is stalling when running target time_stepping and time_stepping_thn with our manufactured test problems (both constant and variable Thn) with refined regions. For example, if time_stepping_thn is executed with the input file input2d.advect_network with refined regions, we see the solver stalling at each time step.

A potential work around: Change/ simplify the test problem so that they look more like the ones in input2d.var_theta.var_vel, input2d.const_theta.var_vel, and input2d.timestepping.all_t.

[abarret]

There is stalling when running target time_stepping and time_stepping_thn with our manufactured test problems (both constant and variable Thn) with refined regions. For example, if time_stepping_thn is executed with the input file input2d.advect_network with refined regions, we see the solver stalling at each time step.

Following up on this after an email discussion: there is another stability constraint in addition to the advective CFL constrain. In particular, there is a restriction that involves the magnitudes of the viscosities and drag coefficient. Reducing the viscosity for our test cases should be sufficient to avoid this stability constraint.

[bindi-nagda]

@abarret FYI, I'm working on identifying which synchronization changes are improving the solver.

[abarret]

@bindi-nagda Did you ever determine which of these flags (if any) are important?

[bindi-nagda]

@bindi-nagda Did you ever determine which of these flags (if any) are important?

I kept getting side-tracked because of the manuscript but I will prioritize this item on my to-do. I'll probably need at least a week. I might be able to do more specific unit tests in the process.

[abarret]

Ok. I'm about to refactor the operators. I will keep the flags.

[bindi-nagda]

@abarret USE_DIV is definitely needed. POST_SYNCH is needed for L-shaped refined regions like the one used for testing time_stepping_thn.

To the extent that I tested, POST_SYNCH isn't necessary for AMR with target frm. But I think we should leave it because maybe at later times this flag will help with convergence.

USE_SYNCHED_INTERP helps reduce some error_norms slightly, so we could remove this one.

[abarret]

Note that #72 kept the code corresponding to the flags being true. It would appear that the only reason to remove the code corresponding to USE_SYNCHED_INTERP being true is if the code runs significantly faster. We should document this in the code. (This flag corresponds to the use of preinterpolated data to node and side centers)