Modeling Stokes flow in and around a droplet using the approach of step-46
Oded Yaakobi
Hello,
I am working on modeling a phenomenon that is similar to Stokes flow in and around a droplet. In my model there are two sets of Stokes equations that govern the flow in each one of the media that are made of different materials – one set for the flow in the droplet, and the other for the flow around the droplet. This phenomenon resembles problems of fluid-structure interaction, so I would like to design my code using a similar approach to the one of step-46.
However, in my case, the droplet exhibits large deformations, so the interface between the media is not going to keep coinciding with cell boundaries, as assumed in step-46, unless the mapping will be time-dependent, e.g. using a MappingQEulerian object. The problem is that there is no MappingQEulerian constructor that can accept hp::DoFHandler object as an argument, so it seems that I cannot implement the approach of step-46.
Does anybody have any idea how to overcome this obstacle?
Thank in advance,
Oded
Jean-Paul Pelteret
Oded Yaakobi
Hi Jean-Paul,
Following the correspondence between you and Tom in the last few weeks, I have realized that in my case, it might be more beneficial to actually move the triangulation vertices instead of using a MappingQEulerian object. I implemented this approach in my code, and so far, things seem to behave properly.
Now I encounter another aspect of my problem that I don’t know how to tackle – the matching conditions on the interface between the domains of the Stokes flow in the droplet and around it.
Attached is a description of the problem in detail. I would be happy to know if you or anyone else has some advice.
Thank you very much for your assistance,
Oded
Wolfgang Bangerth
> Now I encounter another aspect of my problem that I don’t know how to tackle –
> the matching conditions on the interface between the domains of the Stokes
> flow in the droplet and around it.
>
>
>
> Attached is a description of the problem in detail. I would be happy to know
> if you or anyone else has some advice.
equation by a test function and then you integrate (on each of the subdomains)
by parts. This yields terms that live on the boundaries of the subdomains,
including the interface between the subdomains. This is where you then need to
use the interface conditions.
In your code, this will lead to integrals over internal faces where these
faces sit at the interface.
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
Oded Yaakobi
Hi Wolfgang,
I know that the typical treatment of the interface matching conditions is along the lines that you noted. However, it is not clear to me how to follow these guidelines in the particular case that I am working on, which is described in the file that I attached to my previous email. In particular, in my case,
a) The matching conditions involve gradients of velocity and pressure, and not just the velocity and pressure fields.
b) The matching conditions involve time-dependent fields, so probably the explicit form of the constraints has to be updated each time step.
In order to address point a), I thought that maybe I should define additional degrees of freedom that correspond to the components of each one of the gradient terms that appear in my matching conditions (e.g. for the pressure gradient add DOFs P_i_x, P_i_y and P_i_z). I would then define the constraints with respect to those new DOFs, and would also have to assemble the corresponding equations (e.g. P_i_x = dP_i/dx).
Is this the recommended way to address point a), or is there another way which is better?
Thank you,
Oded
Jean-Paul Pelteret
Is this the recommended way to address point a), or is there another way which is better?
Oded Yaakobi
Hi Wolfgang and Jean-Paul,
It seems that one of Wolfgang’s replies to me was not shared through the user group, so I forward it here. My response is listed below it.
On 12/2/16, 6:18 PM, "Wolfgang Bangerth" wrote:
Oded,
I know that the typical treatment of the interface matching conditions is
along the lines that you noted. However, it is not clear to me how to follow
these guidelines in the particular case that I am working on, which is
described in the file that I attached to my previous email. In particular, in
my case,
a) The matching conditions involve gradients of velocity and pressure, and
not just the velocity and pressure fields.
If it doesn't fit into the weak form, and if it isn't easily described as
constraints on degrees of freedom (as we do for Dirichlet values) then I don't
know either. What do others who have published on these models do?
b) The matching conditions involve time-dependent fields, so probably the
explicit form of the constraints has to be updated each time step.
In order to address point a), I thought that maybe I should define additional
degrees of freedom that correspond to the components of each one of the
gradient terms that appear in my matching conditions (e.g. for the pressure
gradient add DOFs P_i_x, P_i_y and P_i_z). I would then define the constraints
with respect to those new DOFs, and would also have to assemble the
corresponding equations (e.g. P_i_x = dP_i/dx).
Correct. You need to update the ConstraintMatrix object in every time step.
Best
W.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Wolfgang:
I am working on generalizing a model that originally described only the interior domain by the equations that I wrote on my Friday’s notes. I am not familiar with anyone who solved the combined set of equations for the interior and exterior domains. However, a simpler problem should be common in other situations where the droplet is made of a single phase. In these cases, a matching condition in the form of Eq. 10 in my notes should be satisfied (with \Psi=0). In recent days I have surveyed the literature to learn how people deal with these situations, but still haven’t found an answer.
Jean-Paul:
I don’t understand exactly what you have suggested. Could you please elaborate more on how would you impose a matching condition such as Eq. 10 in a weak sense?
Best,
Oded
Wolfgang Bangerth
> I am working on generalizing a model that originally described only the
> interior domain by the equations that I wrote on my Friday’s notes. I am not
> familiar with anyone who solved the combined set of equations for the interior
> and exterior domains. However, a simpler problem should be common in other
> situations where the droplet is made of a single phase. In these cases, a
> matching condition in the form of Eq. 10 in my notes should be satisfied (with
> \Psi=0). In recent days I have surveyed the literature to learn how people
> deal with these situations, but still haven’t found an answer.
research you have to do.
I'm going to add this as a note: You can think of these interface conditions
as boundary conditions for one side if you knew the solution on the other side
of the interface; of as a boundary condition for the other side if you knew
the solution on this side. As a consequence, only certain kinds of interface
conditions actually make sense. For example, if you had a Laplace equation on
both sides of an interface, an interface condition of the kind
u|_\Omega_1 = u|_\Omega_2
make sense because it corresponds to Dirichlet boundary conditions for one of
the solutions if the other one were known. Likewise, the following all make sense:
partial_n u|_\Omega_1 = partial_n u|_\Omega_2
partial_n u|_\Omega_1 = u|_\Omega_2
(u + alpha partial_n u)|_\Omega_1 = u|_\Omega_2
...
because they correspond to Neumann or Dirichlet or Robin boundary conditions.
But, the following does not make any sense:
grad u|_\Omega_1 = grad u|_\Omega_2
That's because for the Laplace equation, you can't impose the gradient at the
boundary, only its normal component.
Of course, the types of interface conditions that are allowed are also the
ones that are typically easy to implement -- Neumann and Robin conditions go
into the weak formulation, Dirichlet conditions go into a ConstraintMatrix. If
the interface conditions you have do not easily fit into this pattern, then
that does not *automatically* mean that you formulation is ill-posed and may
not have a solution, but it would certainly make me *question* whether it is
ill-posed, and if necessary *prove* that it is well-posed before I would try
to implement it. There is nothing worse than spending the time implementing a
model for which it later turns out that there are no solutions :-)
Cheers