[Gfs-devel] Update on Mass Transfer Across the Interface

[Manoj Kumar Tripathi]

Hi Gael, Jose, Stephane and Daniel,

I was going through this thread and saw Gael's post regarding a patch that implements vertex divergence filtering. Sadly, I couldn't find the patch. Could anyone of you please post the patch here?

Thanks

Manoj Tripathi

email: ma...@iith.ac.in

[Gael Guedon]

Hi Manoj,

I attached the patch I did at the time. The aim of the filtering was to couple pressure and velocity in the particular case of non-moving or slow-moving interfaces with volume source (the decoupling does not happen otherwise, or is negligible). I tested it on a non-moving interface and it kind of worked... but I am not sure about the moving interface case, if I remembered well I had some issues...

Unfortunately I have no clear idea on how to solve the problem yet, but we may discuss about it.

Cheers

Gael

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

[Manoj Kumar Tripathi]

I was searching for some VOF codes simulating evaporation and tried implementing Jan Schlottke's numerical method ( here is the paper, http://www.sciencedirect.com/science/article/pii/S0021999108000740 ), but couldn't get far. I don't have much knowledge of Gerris's programming, so I just used GfsInit{istep = 1}{} to calculate the mass source and the continuity source term as described in their paper. 

According to them (and it makes sense for VOF), the source term for continuity equation (i.e. S in \nabla u = S ) cannot be naively written as ms*(1/rho_v - 1/rho_l), where ms is the mass source per unit area per unit time, rho_v is the vapour density and rho_l is the liquid density. The reason being the mass averaged nature of the velocity obtained in the VOF framework, instead of a volume averaged one. Therefore an equivalent source term corresponding to the divergence of the mass-averaged velcoity field need to be calculated.

I noticed that Stephane pointed to this paper in a previous post, and Jose showed some interest in following it up. In spite of this I didn't see anyone worrying about this. Has there been any progress since then (The last post I saw was dated 2012).

For now, Gaurav's suggestion seems the easiest to me i.e. moving the source term to the nearest neighbouring cell normal to the interface, though I am not sure what kind of normalization needs to be done in order to make this new mass source consistent with the sharp interface one. Any suggestions?

Gael's and Jose's efforts were the most significant (and encouraging) to get me going on this quest(though I am still a newbie). Of course, not to mention, Stephane's Gerris, with its interactive gfsview is the best thing I have ever seen.

Thanks for your time.

On Thu, Oct 2, 2014 at 11:34 PM, <gfs-deve...@lists.sourceforge.net> wrote:

Send Gfs-devel mailing list submissions to
        gfs-...@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/gfs-devel
or, via email, send a message with subject or body 'help' to
        gfs-deve...@lists.sourceforge.net

You can reach the person managing the list at
        gfs-dev...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gfs-devel digest..."


Today's Topics:

   1. Update on Mass Transfer Across the Interface
      (Manoj Kumar Tripathi)
   2. Re: Update on Mass Transfer Across the Interface (Gael Guedon)


----------------------------------------------------------------------

Message: 1
Date: Thu, 2 Oct 2014 22:12:53 +0530
From: Manoj Kumar Tripathi <ma...@iith.ac.in>
Subject: [Gfs-devel] Update on Mass Transfer Across the Interface
To: gfs-...@lists.sourceforge.net
Message-ID:
        <CALJr5xLgz86dzocex75fbydLFpDWUtAAjCAyEd6=GnKJr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Gael, Jose, Stephane and Daniel,

I was going through this thread and saw Gael's post regarding a patch that
implements vertex divergence filtering. Sadly, I couldn't find the patch.
Could anyone of you please post the patch here?


Thanks

Manoj Tripathi
email: ma...@iith.ac.in

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Thu, 2 Oct 2014 20:04:23 +0200
From: Gael Guedon <gaelg...@gmail.com>
Subject: Re: [Gfs-devel] Update on Mass Transfer Across the Interface
To: GFS developper discussion list <gfs-...@lists.sourceforge.net>
Message-ID:
        <CAHFO+csHiSTWXkCOGF2EYxodCE-XxML2A4=S58vfbu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_on_masstransfer_across_the_interface.zip
Type: application/zip
Size: 101272 bytes
Desc: not available

------------------------------

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

------------------------------

_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

End of Gfs-devel Digest, Vol 61, Issue 1
****************************************

--

Manoj Kumar Tripathi

email: ma...@iith.ac.in

[Gael Guedon]

The implementation of Jan Schlottke's numerical method is very interesting. As far as I understood their implementation, the momentum conservative formulation they used lead them to the necessity of modifying the definition of the velocity divergence term. In Gerris this is slightly different and I do not think such correction is required as far as you do not modify the discretization of the momentum equation.

For the VOF advection, there are differences between their method and my and Jose methods. In their method, the velocity of the liquid phase is used to transport the color function (which can be recovered using the method explained in the paper) while in our methods the advection is performed with the solved velocity (i.e. of the mixture). The correct way depends on how you decide to include the source term due to mass transfer. To my opinion, it is better to advect using the liquid velocity field and then find a way to include the source term due to mass transfer (such as suggested by José). My last findings are that including such source term is not that trivial in general, but its magnitude in the case of evaporation may be small enough (due to the high liquid density) that overshoots and undershoots may have a small impact on the solution.

If I remember well, the method proposed by Gaurav is similar to the one proposed by Hardt and Wondra (2008) and implemented in OpenFOAM by Christian Kunkelmann during his PhD (2011). The main drawback is that you loose the benefit of having a sharp interface representation, which in the end is one of the principal advantage of using a VOF method.

I hope this helps

Gael

[Manoj Kumar Tripathi]

Hi Gael,

If you don't mind, I have some questions about your patch on mass transfer across the interface.

As you said, you obtained the interface velocity after several trial and error procedures (the convection term (u_vapour + u_liquid)/2) because we do not have access to the exact vapour and liquid velocities in VOF method. This works fine for a growing vapour bubble, but it doesn't seem to work for droplet evaporation.

For density ratios close to one, your patch works fine for droplet evaporation, but it fails as I increase the density ratio (even to 10). Do you have any suggestions regarding what should be the interface velocity in this case? I guess, for high density ratio droplet evaporation, the liquid velocity may be neglected and just the vapour velocity (from cells lying in the outer fluid) be used in that formula for interface velocity. However, I am not sure how to do this.

On Fri, Oct 3, 2014 at 1:06 AM, <gfs-deve...@lists.sourceforge.net> wrote:

Send Gfs-devel mailing list submissions to
        gfs-...@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/gfs-devel
or, via email, send a message with subject or body 'help' to
        gfs-deve...@lists.sourceforge.net

You can reach the person managing the list at
        gfs-dev...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gfs-devel digest..."


Today's Topics:

   1. Update on Mass Transfer Across the Interface
      (Manoj Kumar Tripathi)
   2. Re: Update on Mass Transfer Across the Interface (Gael Guedon)

...

End of Gfs-devel Digest, Vol 61, Issue 2
****************************************

[Gael Guedon]

Hi Manoj,

the problem of transporting the interface is actually more subtle than this, and my patch is quite wrong on this regards.

In my patch, there should be two things to consider which are linked to how the interface velocity can be expressed. If you follow the paper of Esmaeeli and Tryggvason (2004, Part I) you should be able to see that the interface normal velocity can be expressed as the sum of two terms: the first one represent the fluid advection (U_V + U_L)/2 and the second one represents the contribution from mass transfer (1/rho_V + 1/rho_L)*mdot/2, where mdot is the mass transfer flux.

In the actual implementation, it is possible to recover the contribution of the first term by "smoothing" the interface specific area (A_int / Volume) when calculating the volume source term. To do so, instead of using A_int from the PLIC interface and the cell volume, you use the gradient of the volume fraction. This is not a rigorous approach because as you mentioned it was obtained after trial and errors... also taking the gradient of volume fraction to estimate the interface specific area is less accurate than taking the PLIC reconstruction.

In order to understand why the transport is wrong when the PLIC interface area is used, you may consider a cell partially field with liquid phase in one dimension (volume fraction c = 1 means liquid and c = 0 means vapor in the following). On the left side you have liquid which is moving at velocity U_L. On the right side you have vapor moving at U_V = U_L + U_jump, where U_jump is the jump in velocity due to mass transfer. Since we are using the PLIC interface area, the estimate of liquid velocity on left side and vapor velocity on right side should be exact (the volume source is present only on the cell considered). At this point, if you consider the cell with few liquid (c < 0.5) you will have that the volume fraction is transported with U_L due to the geometric advection scheme, while when the cell is mostly filled with liquid (c > 0.5) you will have that the volume fraction is transported with U_V, again due to the geometric advection scheme. For this simple one-dimensional case you therefore see a continuous change in the interface velocity as it moves. On the other hand, when you use the "smoothed" version, you somehow always advect the color function with an averaged velocity. This is working quite well in one-dimension but this may not be the case in more than one dimension.

This was for the first contribution from fluid advection. For the second term, you need to add the correction which should be included in the patch. But again there are some issues like a liquid droplet can never disappear and also that the mass transferred is not conservative (i.e., you expect X mass of liquid transferred to vapor and you get something else in terms of volume fraction).

This is the way I tried to implement the volume fraction advection by considering the interface velocity as the sum of an average velocity and a mass transfer contribution. However you can also transport the volume fraction in a different way, like the one presented in the paper of Schlottke (2008). In this case you can consider the volume fraction transported by the liquid velocity only plus a source due to mass transfer. This approach should be mass conservative but as I said there is the issue of estimating the source term and coupling it with the advection scheme.

To come back to your observations, if you consider what I just wrote, it may not be surprising that you have found wrong results. As a suggestion, in the case of droplet evaporation the interface is almost not moving, i.e., it follows mainly the liquid phase. So you may find a way to advect the volume fraction using only the liquid velocity. This is explained briefly in Schlottke (2008).

Good luck with your work!

Cheers,

Gael

[Manoj Kumar Tripathi]

Thanks Gael, for taking out time from your busy schedule, to answer my question in such a detail. This clears up a lot of things for me. It is not as easy as I thought it to be.
I think I will come back to implementing the things you mentioned when I have enough knowledge of Gerris programming (It looks really hard to learn it on my own).

Thanks again!