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

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

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

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

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

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

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

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

We (me and Mr. Scholochow) modified the MULES solver to include the nGammaSubCycles. It is passed as an argument to MULES::explicitSolve().
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]