[daniels]

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]

Hi,

and here the attachments

movingGridFSproblem.tgz
movingGridFSproblem.avi

[hsieh]

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]

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]

Hi Pei,

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

Daniel

movingGridFSproblemV2.tgz

[daniels]

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]

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]

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

[lukasfischer]

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

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]