Drag force for two-phase solver based on VOF

[hgopalan]

Adds the drag force for two-phase solver based on VOF.

Please check the type of change introduced:

• Bugfix
• [X ] Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

Checklist

The following is included:

• new unit-test(s)
• [X ] new regression test(s)
• documentation for new capability

[mbkuhn]

This is a good start, but it's going to need some work. Mainly just to get rid of some of the stuff that was assumed in terrain drag that doesn't apply here. For example, in the terrain drag / terrain_is_waves context, the target levelset and velocity fields are the actual wave quantities enforced globally. But in the multiphase context, those fields are only valid in the wave forcing region (near the inlet). To do something globally, it should be based on the actual velocity and the vof field. I can get into the code and start making some of these changes, if that's ok with you.

[hgopalan]

Sure you can do that. I just wanted an interface of what's required and you know it better.

[mbkuhn]

I have a more big-picture question. This change adds the form drag induced by the waves. Since we are representing the waves on the mesh, are we adding this twice? The solver should naturally produce the drag from the waves.

I know I incorporated this from Manuel's work into the terrain approach, but I'm having my doubts about that as well. Not about the validity of Manuel's approach, but his is typically applied as a BC to a domain that has a flat bottom boundary. We actually have the waves in the domain, so this would seem redundant. Like if you were solving for the flow around a sphere and you also added the theoretical sphere drag to the flow.

[hgopalan]

It depends on the wave amplitude and the refinement used. I assumed we need 6-12 points to represent the wave amplitude/length. This term would account for cases in which we do not sufficiently resolve the wave amplitude. If we have sufficient points to resolve the wave amplitude, we can ignore the form drag portion.

[mbkuhn]

as a result of our discussion of the form drag and the merging of #1558, we should remove the form drag from this implementation. The viscous drag is still good to have, but I think in the case of multiphase simulations, there is no scenario where adding the analytical form drag makes sense.

I'll go ahead and take it out.

[mbkuhn]

@hgopalan could you remind me of the difference between Dxz, Dyz and bc_forcing_x, bc_forcing_y?

[hgopalan]

Dxz adds the shear stress at the surface while the bc forcing forces the wind speed at the computation point to approach the log-law.

[mbkuhn]

I think the implementation is set up now. I haven't done much investigation into how things look in a simulation, though. I'm noticing that the linear solvers are struggling to converge in the reg test. The same thing happens in the ordinary ow_linear reg test, though. I'll try to figure that out separately to make sure that the drag model isn't introducing any problems.

[mbkuhn]

I think the implementation is set up now. I haven't done much investigation into how things look in a simulation, though. I'm noticing that the linear solvers are struggling to converge in the reg test. The same thing happens in the ordinary ow_linear reg test, though. I'll try to figure that out separately to make sure that the drag model isn't introducing any problems.

Figured out that I needed to specify a lower absolute tolerance for the mac projection, now no convergence issues. Feel free to check this and try it out, @hgopalan.

[hgopalan]

Thank you for doing this.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.