Re: [Gfs-devel] implementation of conservative momentum

[Daniel F. <df...@gm...>]

Thank you very much for your time Stephane

I do not know if I am helping you a lot but it is being a very good
curse for me. I am going to read the article and I will see what I can
do

best
Daniel


2008/8/12 Stephane Popinet <s.p...@gm...>:
> Hi Daniel,
>
>> 1) Is it sure that we do not need c_{n+1/2}? These values appear on
>> the RHS of equations 4 and 5 of my last doc. They are required to
>> evaluate the density.
>
> The RHS of equations 4 and 5 are the advection terms for momentum and
> tracer. These terms are computed by the Godunov (or VOF) advection
> scheme which will take care of reconstructing the values (on the
> faces) at time n+1/2 (see e.g. the gfs_cell_advected_face_values()
> function in advection.c and Popinet 2003). So, no we don't explicitly
> need c_{n+1/2}.
>
>> 2) You mention that we should start advancing the tracer using the
>> Godunov scheme instead of the VOF density advection. However, you have
>> not programmed it yet, haven't you?.
>
> Of course I have. This is the difference between GfsVariableTracer
> (uses Godunov advection scheme) and GfsVariableTracerVOF (uses VOF
> advection scheme).
>
>> In any case, when you say it is inconsistent , do you
>> mean that the momentum is not going to be preserved?
>
> The advection schemes are (almost for VOF) conservative. This means
> that momentum is always going to be conserved (if you advect it rather
> than velocity).
>
> However if you use different advection schemes for momentum and
> tracers, you are going to run into trouble when recovering velocity,
> particularly at high density ratios. This is because the two schemes
> will not advect both quantities (rho and rho*u) in exactly the same
> way. For example the Godunov scheme is diffusive and will diffuse some
> of the momentum of e.g. the heavy phase into the light phase.
> Meanwhile if you use a VOF scheme, the density will not diffuse from
> the dense to the light phase. When dividing momentum with density you
> will then end up with potentially very large velocities in the light
> phase...
>
>> 3) About applying the velocity boundary conditions for momentum, I
>> have no idea how to do that in the code. In fact, I do not understand
>> very well how it is organized the data.
>> In any case, I was thinking in adding a subroutine after
>> gfs_domain_bc. I guess that in this subroutine you save the boundary
>> conditions somewhere. Then,  I do not know if it could be possible to
>> traverse just the boundaries and to multiply the value of the BV
>> applied to  mpar.v[c] by rho.
>
> I think we can leave that for the moment and just look at cases with
> e.g. symmetry boundary condtions (i.e. no inflow) which will be ok
> with either momentum or velocity.
>
>> 4) The last question is silly, but why do you sometimes pass
>> FTT_DIMENSION as an argument (e.g.
>> gfs_centered_velocity_advection_diffusion) and some others this value
>> is already known inside the subroutine (e.g. momentum_from_velocity)
>
> FTT_DIMENSION is a macro which by definition is fixed at compilation
> time. This means that stuff in 2D dimensions cannot be mixed with
> stuff in 3D dimensions. Sometimes this is useful. In particular for
> the ocean version of Gerris. If you don't plan to use your routines in
> 2D and 3D simultaneously you don't need to pass the dimension as a
> parameter (i.e. you can use FTT_DIMENSION instead).
>
> Stephane
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gfs-devel mailing list
> Gfs...@li...
> https://lists.sourceforge.net/lists/listinfo/gfs-devel
>