CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   InterDyMfoam gives strange gamme if cell volume changes due to mesh motion (http://www.cfd-online.com/Forums/openfoam-solving/58021-interdymfoam-gives-strange-gamme-if-cell-volume-changes-due-mesh-motion.html)

daniels January 29, 2009 05:32

Hi, I am using interDyMfoam
 
Hi,

I am using interDyMfoam in combination with mesh motion. It gives strange gamma values if cell volume changes due to mesh motion.

Find attached a free surface test case (derived from icoDyMFoam's the movingCone) an an animation showing the results.

The lower plots in the animation shows the MULES result: gamma is exceeding one, if the cell volume is decreasing due to mesh deformation; gamma is nonphysically reduced if cell volume is increasing.

I used solidBody motionMesh (constant cell volume) without this problems.

I tracked the error down to MULES. Find attached a simplified interDyMFoam, which uses (instead of MULES) a simple scalar transport equation for gamma (in gammEqn2.H). The result is plotted in the bottom plot of the attached animation.

MULES interface compression feature is highly desirable, thus I would like to use MULES in combination with moving mesh.

So, anybody any hint?

Thanks
Daniel




daniels January 29, 2009 05:37

Hi, and here the attachment
 
Hi,

and here the attachments

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif movingGridFSproblem.tgz
http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif movingGridFSproblem.avi

hsieh January 29, 2009 16:16

Hi, Daniel, I downloaded yo
 
Hi, Daniel,

I downloaded your solver and case, but, it requires MULES2.H (which you developed?). can you email me the code or post it here so that I can do some testing? thanks

Pei
peiying2003@yahoo.com

hsieh January 29, 2009 16:19

Hi, Daniel, I downloaded yo
 
Hi, Daniel,

I downloaded your solver and case, but, it requires MULES2.H (which you developed?). can you email me the code or post it here so that I can do some testing? thanks

Pei
peiying2003@yahoo.com

daniels January 30, 2009 05:30

Hi Pei, sorry for the incon
 
Hi Pei,

sorry for the inconvenience. MULES2 was an unsuccessful attempt to solve the problem myself. Here is a version without MULES2

Daniel

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif movingGridFSproblemV2.tgz

daniels January 30, 2009 16:36

Hi, maybe I got a clue. I g
 
Hi,

maybe I got a clue. I guess the trouble is in the volume change term in MUSESTemplates.C line 111. If nGammaSubCycles is larger than 0, it is evaluated multiple times (once in each subcycle) and adds to much gamma. Setting nGammaSubCycles to 0 cures the problem.

Daniel

daniels January 30, 2009 17:48

Hi again, I have a solution
 
Hi again,

I have a solution, but one needs nGammaSubCycles within MULES.

In src/finiteVolume/fvMatrices/solvers/MULES/MULESTemplates.C:

111c111
< mesh.V0()*rho.oldTime()*psi0/(deltaT*mesh.V())
---
> pow((mesh.V0()/mesh.V()),(1./nGammaSubCycles)) *rho.oldTime()*psi0/deltaT

This works fine with nGammaSubCycles >0. What is the most elegant way to get nGammaSubCycles in MULES? Look it up from the dict or add to the MULES2::explicitSolve parameterlist?

Daniel

lukasfischer March 23, 2009 12:47

is there already a solution to this problem? how is it possible to get the nGammaSubCycles into MULES?

lukasfischer April 7, 2009 09:31

1 Attachment(s)
We (me and Mr. Scholochow) modified the MULES solver to include the nGammaSubCycles. It is passed as an argument to MULES::explicitSolve().
Code:

MULES::explicitSolve(gamma, phi, phiGamma, 1, 0,nGammaSubCycles);
nGammaSubCycles is defaulted to 1 to preserve the old interface.

To use the modified version extract the files to .../src/finiteVolume/fvMatrices/solvers/MULES/ and recompile the libfiniteVolume.so (wmake libso in .../src/finiteVolume/).

Solvers using MULES have to pass nGammaSubCycles. Change calls to MULES::explicitSolve in the gammaEqn.H in the solver as mentioned above.

regards
[update: corrected the code so the interface is really preserved]


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