The Bretherton problem: An air finger propagates into a 2D channel
This tutorial discusses the solution of the classical Bretherton problem in which an air-finger is driven steadily into a 2D fluid-filled, rigid-walled channel.
The driver code listed below was originally developed as a test-bed for the paper
Hazel, A.L. & Heil, M. (2008) The influence of gravity on the steady propagation of a semi-infinite bubble into a flexible channel. Physics of Fluids 20, 092109 (pdf reprint)
in which we studied the elastic-walled equivalent, paying particular attention to the effect of transverse gravity which plays quite an important role in this problem.
Compared to other tutorials, there is no detailed discussion of the driver code itself because the implementation is somewhat messy. However, given that the driver code is (of course!) very well documented you should be able to figure out what's going on once you've read through the discussion of the problem formulation and our brief comments on the Implementation. Get in touch if you need more information.
The problem
The sketch below shows the problem setup: An (inviscid) air finger propagates at a steady speed into a 2D rigid-walled, fluid-filled channel of half-width . In the process it displaces some of the viscous fluid (of density , viscosity and surface tension ) and deposits a film of thickness on the channel walls. [Note that, for the sake of simplicity, we ignore the effect of transverse gravity in this discussion; the driver code listed below allows the specification of a gravitational body force which will break the up-down symmetry of the solution.]
Sketch of the problem setup
We non-dimensionalise the velocities on , the lengths on and the pressure on the viscous scale, and solve the problem in a frame moving with the velocity of the finger. The flow is then governed by the non-dimensional Navier-Stokes equations
and the continuity equation
where the Reynolds number is defined as . On the free fluid surface, whose outer unit normal we denote by , the fluid normal velocity vanishes,
We measure the fluid pressure relative to the bubble pressure . Then the dynamic boundary condition implies that
where is the non-dimensional interface curvature and the capillary number is a non-dimensional measure of the bubble velocity. The no-slip condition on the channel walls requires that at . Far behind the bubble tip, the fluid remains stationary on the walls. In the moving frame of reference, this corresponds to the plug flow profile as . The residual film thickness has to be determined as part of the solution and it determines the volume flux through the system. The Poiseuille velocity profile far ahead of the bubble tip,
is then determined by overall continuity.
Some results
Here are some pretty pictures of the computed flow field,
Velocity and pressure fields
and here is a comparison of the computational predictions for the bubble pressure and film thickness against Bretherton's famous asymptotic predictions (valid only for small capillary numbers!):
Bubble pressure and film thickness far behind the finger tip vs. capillary number; computed solution and Bretherton's predictions for small Ca.
Implementation
The discretisation of the problem is reasonably straightforward, the most (human-)time-consuming part being the creation of the spine mesh, discussed in another tutorial. The real complication arises from the fact that the application of the "inflow condition" (1) at the right end of the domain – superficially a Dirichlet condition for the velocity – depends on the non-dimensional film thickness at the left end of the domain. This introduces a non-local interaction between these degrees of freedom. We handle this by providing a templated wrapper class BrethertonElement (templated by the type of the "wrapped" fluid element) which allows the specification of the film thickness as external Data (i.e. Data whose values affect the element's residuals but are not determined by the element; see the discussion of oomph-lib's various types of elemental Data in the "bottom up" discussion of the library's data structure). Read the driver code listed below to see how it works!