# div(phi,U) in an incompressible solver

 Register Blogs Members List Search Today's Posts Mark Forums Read

 June 8, 2011, 11:47 div(phi,U) in an incompressible solver #1 Member   fisch Join Date: Feb 2010 Posts: 97 Rep Power: 7 Hi Foamers, does anybody know if div(phi,U) in an incompressible solver (like simpleFoam) is calculating the "full" divergence term of phi*U or is it directely introducing the incompressibility conditions that the calculation would be reduced to the half. For a better understanding what i mean i will write it analytical for 2D motion (i will leave out the density): Option a) div(U,U) = u*( du/dx+dv/dy) + u*du/dx + v*du/dy Option b) div(U,U) = u*du/dx + v*du/dy (because the term in the brackets satisfies div(U)=0) Which option is openFoam using? Thanks a lot, rupert

 June 8, 2011, 13:44 #2 Senior Member     Santiago Marquez Damian Join Date: Aug 2009 Location: Santa Fe, Santa Fe, Argentina Posts: 418 Rep Power: 15 Rupert, FOAM solves the "weak" form if this term. When you use FVM, integrals are volumetric at the beginning but using the Gauss Theorem you don't have to use any derivatives but only values at faces, because you have a surface integral: int_{Omega} div(U*U) dOmega=int_{Gamma} U*U&d_Gamma=sum_f U_f*U_f&S_f=sum_f U_f*phi_f where & is the dot product, Omega is the control volume and Gamma is its border and f indicates quantities at faces. phi is the flux U_f&S_f. Regards. __________________ Santiago MÁRQUEZ DAMIÁN, Ph.D. Post-doctoral Fellow Research Center for Computational Mechanics (CIMEC) - CONICET/FICH-UNL T.E.: 54-342-4511594 Ext. 1005 Güemes 3450 - (3000) Santa Fe Santa Fe - Argentina http://www.cimec.org.ar

 June 9, 2011, 07:21 #3 Senior Member   Paulo Vatavuk Join Date: Mar 2009 Location: Campinas, Brasil Posts: 111 Rep Power: 8 Hi Rupert, Just complementing Santiago's answer, this means that, for the x momentum equation, you have alternative a) integrated over the cell volume. Paulo

 June 9, 2011, 07:46 #4 Member   fisch Join Date: Feb 2010 Posts: 97 Rep Power: 7 Hi Paulo and Santiago, thanks for the reply. Both answers are helping me. So if i want to add to an equation one more term i have to integrate it over the cell volume or just multiply the cell center value with the Volume of the cell, right? For example if i want to add a value S (like a source term) i have to integrate this value over the cell volume, too, right? Thanks rupert

 June 9, 2011, 07:51 #5 Senior Member     Santiago Marquez Damian Join Date: Aug 2009 Location: Santa Fe, Santa Fe, Argentina Posts: 418 Rep Power: 15 Rupert, the integration is part of the method and is implied using FOAM. Adding S to the equation starts a chain of events that finally integrate the source over each cell. The other option is to use the fvm::Sp(). Regards. __________________ Santiago MÁRQUEZ DAMIÁN, Ph.D. Post-doctoral Fellow Research Center for Computational Mechanics (CIMEC) - CONICET/FICH-UNL T.E.: 54-342-4511594 Ext. 1005 Güemes 3450 - (3000) Santa Fe Santa Fe - Argentina http://www.cimec.org.ar

 June 9, 2011, 09:34 #6 Member   fisch Join Date: Feb 2010 Posts: 97 Rep Power: 7 Hello Santiago, does that mean that the integration is implied in the discretization schemes (like in e.g. div(phi,U)) or is it automatically implied while solving an equation??? The difference would be that i don't have to integrate my source term my own if it is done by the solve() procedure... Can you understand what i mean?? As far as i get it out of the source code the Sp() function is anyhow multiplying with the cell Volumes; but i had no success to use it right :-/ ... Further: what is wrong if i type: volScalarField meshVols = U.mesh().V(); There is a compiler error: error: conversion from ‘const Foam:imensionedField’ to non-scalar type ‘Foam::volScalarField’ requested Maybe you have some answers. thanks a lot, rupert

June 10, 2011, 11:32
#7
Member

Sabin Ceuca
Join Date: Mar 2010
Location: Munich
Posts: 42
Rep Power: 7
Quote:
 Originally Posted by fisch Further: what is wrong if i type: volScalarField meshVols = U.mesh().V(); There is a compiler error: error: conversion from ‘const Foam:imensionedField’ to non-scalar type ‘Foam::volScalarField’ requested Maybe you have some answers. thanks a lot, rupert
Hi Rupert,

tmp<volScalarField> cellVolume
(
new volScalarField
(
IOobject
(
"cellVolume",
runTime.timeName(),
mesh,
IOobject::NO_WRITE
),
mesh,
dimensionedScalar("zero",dimensionSet
(0, 3, 0, 0, 0, 0, 0), 0.0)
)
);
cellVolume().internalField() = mesh.V();

This part should store the volumes of your cells. I don't really understand why you call your volume like U.mesh().V ?

Regards,
sabin

June 14, 2011, 01:42
#8
Member

fisch
Join Date: Feb 2010
Posts: 97
Rep Power: 7
Quote:
 Originally Posted by santiagomarquezd Rupert, the integration is part of the method and is implied using FOAM. Adding S to the equation starts a chain of events that finally integrate the source over each cell. The other option is to use the fvm::Sp(). Regards.
Santiago,
do i have to use some integration over the cell volume inside an equation for the additional source term S or is it done automatically so that i have to add only the term with " + S" or do i need something else??

rupert

 June 25, 2013, 12:16 #9 Senior Member   Anne Gerdes Join Date: Aug 2010 Location: Hamburg Posts: 152 Rep Power: 7 Good evening, I have the same question. I have added an explicit source term rhs in the momentum equation HTML Code: ```tmp UEqn ( fvm::div(phi, U) + turbulence->divDevReff(U) +rhs )``` Is this source term automatically multiplied by the control volumes = integrated? In my case I would like to add a face-based source term which includes the face magnitudes. Therefore I suppose that I need to divide my source term by the control volume, as I do not want it to be multiplied as the multiplication with the face magnitude symbols an integration over the face already. Can someone please verify that the source term is automatically integrated if I insert it in the UEqn like stated above? I am looking forward to your answers. Kind Regards Anne

 June 25, 2013, 18:51 #10 Senior Member   Fumiya Nozaki Join Date: Jun 2010 Location: Yokohama, Japan Posts: 170 Rep Power: 7 Hi, You can use the cell center value not the cell integrated value when you specify the explicit source term in the UEqn. Hope that helps, Fumiya

 June 26, 2013, 02:56 #11 Senior Member   Anne Gerdes Join Date: Aug 2010 Location: Hamburg Posts: 152 Rep Power: 7 Dear Fumiya, thank you very much for your answer. How can I switch between cell-centered and cell-integrated value? Thank you, Anne Lincke

 June 27, 2013, 14:06 #12 Senior Member   Anne Gerdes Join Date: Aug 2010 Location: Hamburg Posts: 152 Rep Power: 7 Dear foamers, I have written a face-based source which I would like to include in the UEqn. I assume that this term will automatically multiplied with the cell-volume as it is explicit? As the term corresponds to the integration over the faces it is already scaled with the face-magnitude and does not need to be scaled by the cell volume any more. Therefore I divided the term by the cell volume, but the code does not converge In the following a sketch of the code. HTML Code: ```for( label faceI=0; faceI < mesh.nInternalFaces(); faceI++) { label P = owner[faceI]; label N = neighbour[faceI]; rhs[P] = rhs[P] + mesh.Sf()[faceI]*Uf[faceI]*1/mesh.V()[P]; }``` Can I somehow avoid the automatic scalation with the cell center volume inside the UEqn? Thank you very much for an answer. Anne

June 28, 2013, 08:40
#13
Member

Eysteinn Helgason
Join Date: Sep 2009
Location: Gothenburg, Sweden
Posts: 52
Rep Power: 7
Quote:
 Originally Posted by Anne Lincke Dear foamers, I have written a face-based source which I would like to include in the UEqn. I assume that this term will automatically multiplied with the cell-volume as it is explicit? As the term corresponds to the integration over the faces it is already scaled with the face-magnitude and does not need to be scaled by the cell volume any more. Therefore I divided the term by the cell volume, but the code does not converge In the following a sketch of the code. Code: ```for( label faceI=0; faceI < mesh.nInternalFaces(); faceI++) { label P = owner[faceI]; label N = neighbour[faceI]; rhs[P] = rhs[P] + mesh.Sf()[faceI]*Uf[faceI]*1/mesh.V()[P]; }``` Can I somehow avoid the automatic scalation with the cell center volume inside the UEqn? Thank you very much for an answer. Anne
Hi Anne,

Yes it is automatically multiplied with the cell volume.

I think you might be looking for the reconstruct operator to get the value in
the cell center:
Code:
```surfaceScalarField phi
= fvc::interpolate(U) & mesh.Sf();

volVectorField UfromPhi("UfromPhi",fvc::reconstruct(phi) );```
/Eysteinn

 July 1, 2013, 10:40 #14 Senior Member   Anne Gerdes Join Date: Aug 2010 Location: Hamburg Posts: 152 Rep Power: 7 Thank you, I think I found another reason for the non-convergence of my code. Nevertheless this implementation helped me a lot to understand how OpenFOAM treats the source terms. Kind Regards Anne

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post matthias OpenFOAM Running, Solving & CFD 1 April 26, 2010 05:46 sankarv OpenFOAM 0 April 4, 2010 18:06 luca_g OpenFOAM Running, Solving & CFD 3 September 21, 2009 02:30 youngan CFX 0 July 1, 2003 23:32 J. Ehrhard Main CFD Forum 1 October 8, 1998 19:47

All times are GMT -4. The time now is 17:28.