Phase-field and Navier-Stokes Coupling

[Vitaliy]

Hello,
I would like to perform coupled phase-field (Cahn-Hilliard) and Navier-Stokes calculations. It is a very simple problem (for now), where Cahn-Hilliard eq. is solved for one variable taking into account velocity field (see attachment). Base upon my reading and the prior discussion one way is to use MultiApp approach with picard iteration. However, I have some difficulties to understand why do I need MultiApp, if I can combine both module in one input file and pass velocity (u) from Navier-Stokes to Cahn-Hilliard by using type = MatReaction that should work. Can anyone advice me if it is a correct way?

  [./u_grad_c]    
       type = MatReaction   
       variable = c   
       v = u    
       mob_name = 1
 [../]

Thanks,
Vitaliy

[Karim Elsayed]

MatReaction won't work, you need to add an advection kernel which in this case should also be able to take a coupled variable as long as you are going to solve for u and not prescribe it. 

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/2ddf2791-54b1-44ab-b12d-10e8db63e4ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Karim Ahmed

Assistant Professor

Department of Nuclear Engineering

Texas A&M University

205C AI Engineering Building

College Station, TX, 77843-3133

karim...@tamu.edu

office: 979-847-6192

Cell: 850-980-5317

[Vitaliy]

Thanks, Karim!
the logic is:
MatReaction add the term -L*v
params.addClassDescription("Kernel to add -L*v, where L=reaction rate, v=variable");

if 'v' is equal to non-linear variable 'c', and I will pass 'u' from the Navier-Stokes to 'L', then I will have my desire term -u*nabla_c. Or am I mistaken in that thinking?

Thanks,
Vitaliy

On Thursday, October 19, 2017 at 11:12:36 AM UTC-5, Karim Elsayed wrote:

MatReaction won't work, you need to add an advection kernel which in this case should also be able to take a coupled variable as long as you are going to solve for u and not prescribe it. 

On Thu, Oct 19, 2017 at 10:38 AM, Vitaliy <vityu...@gmail.com> wrote:

Hello,
I would like to perform coupled phase-field (Cahn-Hilliard) and Navier-Stokes calculations. It is a very simple problem (for now), where Cahn-Hilliard eq. is solved for one variable taking into account velocity field (see attachment). Base upon my reading and the prior discussion one way is to use MultiApp approach with picard iteration. However, I have some difficulties to understand why do I need MultiApp, if I can combine both module in one input file and pass velocity (u) from Navier-Stokes to Cahn-Hilliard by using type = MatReaction that should work. Can anyone advice me if it is a correct way?

  [./u_grad_c]    
       type = MatReaction   
       variable = c   
       v = u    
       mob_name = 1
 [../]

Thanks,
Vitaliy

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/2ddf2791-54b1-44ab-b12d-10e8db63e4ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Karim Elsayed]

Vitaliy, 

It will be just U*C not U*gard_C, that is the difference between reaction and advection kernels. There are a few advection kernels in MOOSE, you might want check them out.  

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c62c4432-86a5-4802-a876-a6ac34a68bb4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alexander Lindsay]

You can also use a conservative formulation for the advection kernel. Because if your strong form is:

div(U * c)

where U is the velocity vector and c is your concentration variable, then you can integrate by parts and the volume term of your weak form would be:

-grad(test) * U * c

However, particularly if your flow is incompressible (e.g. divergence free), then you can bring U outside the del operator and you get the weak form that Karim refers to:

test * U * grad(c)

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAEnTHenw1kHKrqQ6ET7hUGjzkJev7va75Z0ZNtQ_EVENiaEAOw%40mail.gmail.com.

[Alexander Lindsay]

Note that navier_stokes module already has the latter kernel implemented:

modules/navier_stokes/src/kernels/Advection.C

[Vitaliy]

Thank you, Karim and Alexander!
yes my flow is incompressible so I need u*grad_c. I checked advection implementation in the code, it looks promising. I will try to bring them all together.

Thanks,
Vitaliy

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c62c4432-86a5-4802-a876-a6ac34a68bb4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Karim Ahmed

Assistant Professor

Department of Nuclear Engineering

Texas A&M University

205C AI Engineering Building

College Station, TX, 77843-3133

karim...@tamu.edu

office: 979-847-6192

Cell: 850-980-5317

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

[Vitaliy]

Alexander,
I was wondering if you can help me with the understanding of the body and interfacial forces in the Navier-Stokes module. I need to add F as in the attachment, where non-linear phase variable from the phase-field module must be passed to the NS eq. together with gravity. Reviewing the NS module adding gravity is easy, also there is a possibility to use forcing_func in x,y-momentum. But, forcing_func can only be a mathematical expression defined in section [Function], where I cannot use non-linear variable from the other module. Now the question how do I add grad_c to the F? The other question, how are gravity and grad_c in this case related? Since, I need gravity in denominator.
Also, you have mentioned advection.c implementation, I can see the code, but is there an example how to use it?

Thanks,
Vitaliy

On Thursday, October 19, 2017 at 2:01:53 PM UTC-5, Alexander Lindsay wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c62c4432-86a5-4802-a876-a6ac34a68bb4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Karim Ahmed

Assistant Professor

Department of Nuclear Engineering

Texas A&M University

205C AI Engineering Building

College Station, TX, 77843-3133

karim...@tamu.edu

office: 979-847-6192

Cell: 850-980-5317

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

[Peterson, JW]

On Fri, Oct 20, 2017 at 9:34 AM, Vitaliy <vityu...@gmail.com> wrote:

Alexander,
I was wondering if you can help me with the understanding of the body and interfacial forces in the Navier-Stokes module. I need to add F as in the attachment, where non-linear phase variable from the phase-field module must be passed to the NS eq. together with gravity. Reviewing the NS module adding gravity is easy, also there is a possibility to use forcing_func in x,y-momentum. But, forcing_func can only be a mathematical expression defined in section [Function], where I cannot use non-linear variable from the other module. Now the question how do I add grad_c to the F? The other question, how are gravity and grad_c in this case related? Since, I need gravity in denominator.
Also, you have mentioned advection.c implementation, I can see the code, but is there an example how to use it?

If you just need a forcing function which is coupled to another nonlinear variable or it's gradient, this is a fairly straightforward thing to do in MOOSE. See, for example, the framework/src/kernels/CoupledForce.C kernel.

--

John

[Vitaliy]

thanks, this is indeed very straightforward.

Vitaliy

[Micah Johnson]

I did something similar for my masters thesis, during which I numerically studied natural convection in snow microstructure using the Moose app Pika. 

I didn't drive the phase field directly with velocity field but I attempted to advect the vapor field which in turn drove the phase of the snow microstructure through a forcing function. I ran into some numerical stability issues advecting those fields and never got to a fully coupled run that would converge. I was however able to continuously enforce a no slip condition using the phase variable which may be of interest.

If you are interested you can take a look at my thesis and my branch on github .  I would gladly answer any questions.

[Vitaliy]

Hi Micah,
thanks a lot for the info, it looks very promising. I will check your work in details.

Best,
Vitaliy

[Alexander Lindsay]

Note that we recently added streamline-upwind and pressure-stabilized petrov-galerkin methods to the incompressible part of the navier stokes models. These techniques allow study of much higher reynolds numbers and use of equal order elements for velocity and pressure respectively.

Alex

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/f6dbe70c-f26e-49cc-9886-078aedf7ffd2%40googlegroups.com.

[Vitaliy]

thanks, Alex! Since my current problem is gravity driven only I am trying to combine phase-field with the gravity.i example from the hydrostatic folder, but for some reasons when I switched that example to the transient problem (in the example it is steady state) I cannot get any solution. I tried many solver possibilities, but there is no even one time step solution. But I will work on it.
I have a small question now, if I will add forcing function to the NV equation and there will be gravity kernel present. How do they both contribute to the NV equation? Because I need to multiply them f_function*g=F.

Thanks,
Vitaliy

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

[Alexander Lindsay]

On Sun, Oct 22, 2017 at 6:28 PM, Vitaliy <vityu...@gmail.com> wrote:

thanks, Alex! Since my current problem is gravity driven only I am trying to combine phase-field with the gravity.i example from the hydrostatic folder, but for some reasons when I switched that example to the transient problem (in the example it is steady state) I cannot get any solution. I tried many solver possibilities, but there is no even one time step solution. But I will work on it.

Did you add INSMomentumTimeDerivative kernels for the velocity variables? Because I just took the hydrostatic example and switched to transient, adding the time derivative kernels, and I was able to take a time step just fine. Note that for dt=1, the simulation is at steady-state after one time step so it's fruitless to try and take more. Your solution should show no flow with a linearly increasing pressure as you dive deeper into the pool.

 

I have a small question now, if I will add forcing function to the NV equation and there will be gravity kernel present. How do they both contribute to the NV equation? Because I need to multiply them f_function*g=F.

So gravity is already built into the INSMomentum kernels as rho * g where gravity is specified as a three component vector in the input file. Are you saying you want to incorporate the gravity vector into an additional "body force" term? The simplest way to do this I think is just have a number of BodyForce kernels equal to the number of velocity components and have the respective gravity component built into whatever forcing function you're passing into BodyForce as the `function` parameter.

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/dff71e0a-18c8-4a1e-b907-d9639230477d%40googlegroups.com.

[Vitaliy]

I did not add INSMomentumTimeDerivative. Sorry this is a stupid mistake I am still learning the NS implementation in the MOOSE, since until now I was using only phase-field and mechanics modules. Concerning the BodyForce, thanks for an additional explanation. I'll try to follow it.
Thanks,
Vitaliy

[Vitaliy]

Hi,
maybe for you it will be an easy question, but why do we need to specify forcing function twice? First in the INSMomentumLaplaceForm and then again in BodyForce kernels.

Thanks,
Vitaliy

On Monday, October 23, 2017 at 8:36:46 AM UTC-5, Alexander Lindsay wrote:

[Alexander Lindsay]

This is something that is prone to accidental user error and something we should fix. Currently, the BodyForce kernel is the kernel that's truly applying the force. The forcing_function passed to the INS* kernels is used to add the the force's contribution to stabilization terms. I noticed this the other day, and I'll open a ticket.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/dcf2b5c4-f1eb-43bc-a5f8-4a85a4870762%40googlegroups.com.

[Vitaliy]

thanks, Alex! It did not mean to be a criticism of a code, I was just not sure about the meaning of it.

[Vitaliy]

Hello,

Was wondering how can I set Re number for the NS simulation?

When I set Re in the [GlobalParams] it returns me an error 

*** ERROR ***

unused parameter 'GlobalParams/Re'

Thanks,

Vitality

[Peterson, JW]

On Wed, Oct 25, 2017 at 12:55 PM, Vitaliy <vityu...@gmail.com> wrote:

Hello,

Was wondering how can I set Re number for the NS simulation?

When I set Re in the [GlobalParams] it returns me an error 

*** ERROR ***

unused parameter 'GlobalParams/Re'

Re isn't a parameter in the navier_stokes module, since we solve a dimensional version of the governing equations. Instead, you will need to decrease mu or increase the strength of the applied velocity field to increase the effective Reynolds number.

Have a look at our recent report which goes into more detail on the governing equations: http://arxiv.org/abs/1710.08898

--

John

[Vitaliy]

Thanks, John!

that report is REALLY good, I already printed it to read in details. This is what I was thinking about Re number, but I was a bit confused by the widget_dirichlet.i example, where Re in specified in the [GlobalParams]. So I was thinking we can give Re number by mu parameter or it is overwritten if Re in given in the [GlobalParams]

Thanks,

Vitaliy

[Peterson, JW]

On Wed, Oct 25, 2017 at 1:09 PM, Vitaliy <vityu...@gmail.com> wrote:

Thanks, John!

that report is REALLY good, I already printed it to read in details. This is what I was thinking about Re number, but I was a bit confused by the widget_dirichlet.i example, where Re in specified in the [GlobalParams]. So I was thinking we can give Re number by mu parameter or it is overwritten if Re in given in the [GlobalParams]

Sorry for the confusion. That parameter is specific to the "WedgeFunction" object used in that test.

--

John

[Alexander Lindsay]

Vitaliy, we also merged in the body force change, so if you pull down the most recent moose, you will no longer need BodyForce kernels in addition to your INSMomentum* kernels

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CANj%2BmwDU_mcUCBmCjZyi7UnXK%3D6dY7hJnBRUUtHaRYz6mGObkA%40mail.gmail.com.

[Vitaliy]

Alex,

thanks for the info, I see it is in the INSMomentumBase.C line 51. I will update the MOOSE right away.

FYI, I already coupled phase-field and the Navier-Stokes modules, it works very well. I did already coupling of the velocity from the NS to the Cahn-Hilliard, and now I am working on the passing of non-linear phase variable gradient to the NS forcing function. I use Advection.c as you have suggested. I have also read yours and John's report yesterday during my flight it is really good. 

Vitaliy

On Wednesday, October 25, 2017 at 3:16:56 PM UTC-4, Alexander Lindsay wrote:

Vitaliy, we also merged in the body force change, so if you pull down the most recent moose, you will no longer need BodyForce kernels in addition to your INSMomentum* kernels

On Wed, Oct 25, 2017 at 1:13 PM, Peterson, JW <jw.pe...@inl.gov> wrote:

On Wed, Oct 25, 2017 at 1:09 PM, Vitaliy <vityu...@gmail.com> wrote:

Thanks, John!

that report is REALLY good, I already printed it to read in details. This is what I was thinking about Re number, but I was a bit confused by the widget_dirichlet.i example, where Re in specified in the [GlobalParams]. So I was thinking we can give Re number by mu parameter or it is overwritten if Re in given in the [GlobalParams]

Sorry for the confusion. That parameter is specific to the "WedgeFunction" object used in that test.

--

John

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

[Alexander Lindsay]

Vitaliy, are you using Advection natively, e.g. without any modifications? We actually changed Advection into a test object yesterday, but we'll move it back if it's actually useful in your simulations :-)

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/9bd52e00-42e5-4c0d-9e12-a87e95ec687f%40googlegroups.com.

[Vitaliy]

Alex,

yes I use it without any modifications, but I already updated  the MOOSE as you have suggested. Let me first try the advection from the test object, it should do the same thing.

Vitaliy

[Peterson, JW]

On Thu, Oct 26, 2017 at 10:06 AM, Vitaliy <vityu...@gmail.com> wrote:

Alex,

yes I use it without any modifications, but I already updated  the MOOSE as you have suggested. Let me first try the advection from the test object, it should do the same thing.

Unfortunately, test objects can only be used within the testing App since they aren't registered otherwise... we would need to add the Kernel back if you are really using it.

That said, I suspect the scalar advection equation is not what you want for your "real" application, i.e. if you are computing a viscous flow there should probably be some diffusion in whatever species is being transported around by the flow.

--

John

[Vitaliy]

Oh, I confused it with the UserObject. Alright let me test my implementation first, since right now I have some problems with the python after the update. I use python 3.5 on the cluster, but TestHarness.py was changed to 2.7. 

The other question is about your paper, in particular, the results shown in Fig. 16. Is there an example input file on github?

Thanks,

Vitaliy

[Peterson, JW]

On Thu, Oct 26, 2017 at 11:35 AM, Vitaliy <vityu...@gmail.com> wrote:

Oh, I confused it with the UserObject. Alright let me test my implementation first, since right now I have some problems with the python after the update. I use python 3.5 on the cluster, but TestHarness.py was changed to 2.7. 

The other question is about your paper, in particular, the results shown in Fig. 16. Is there an example input file on github?

There is a results_generation branch in my fork with a test/tests/ins/flow_over_sphere directory that has the input file and mesh for that example.

--

John

[Vitaliy]

Hi,
I just want to shear some results. Following yours and Alex suggestions I have coupled phase-field and Navier-Stokes modules passing the corresponding velocities form the NS to the phase-field Cahn-Hilliard and Cahn-Hilliard forcing function to the NS, based upon CoupledForce.C (I have modified it for my needs). Now I have to get the correct normalization according to the real units and the adoptive mesh, you may see in the attachment the mesh is very coarse.

Vitaliy

[Vitaliy]

Hi,
How do I visualize velocity vectors as in Fig. 15b?

Thanks,
Vitaliy

On Thursday, October 26, 2017 at 1:23:36 PM UTC-5, jw.peterson wrote:

[Peterson, JW]

On Tue, Oct 31, 2017 at 1:26 PM, Vitaliy <vityu...@gmail.com> wrote:

Hi,
How do I visualize velocity vectors as in Fig. 15b?

In Paraview, you use the Glyph filter. It should pick up the velocity field due to the way we name the variables with _x, _y, etc.

--

John

[Vitaliy]

thanks, it looks very nice.

[Vitaliy]

Hi Micah,
a question about your model. The following term is to exclude moving bubble phase from the NS. Is that correct? This is kind of no-slip boundary condition on the moving phase. Do you know if there is something like that in the MOOSE Navier-Stokes module?

[ . / x n o s l i p ]
 type = PhaseNoSlipForcing
 v a r i a b l e = v x
 phase = phi
 h = 100
 [ . . / ]

Thanks,

Vitaliy

On Saturday, October 21, 2017 at 2:29:04 PM UTC-5, Micah Johnson wrote: