[philippose]

Good day to everyone!

After a short break, I am back :-)! Break from posting on this thread i.e. :-)! The holiday break is just coming up (yippee :-)!)

For those who have moved on to OpenFOAM 1.4, here is the latest version of turbForceFoam.

turbForceFoam.tgz

This version of the solver has the following changes / upgrades:

1. Works in the stock version of OpenFOAM 1.4

2. Saves the following data at each write operation:
a. Absolute time at which calculation was carried out last
b. Acceleration
c. Velocity
d. Position
e. Pressure force
f. Wall Shear force

I have run a simple test-case which came up with very satisfactory results, though, I havent tried the wall shear force part of the code (A simple action of replacing the "no" with a "yes" in the dictionary... havent got around to doing it yet!).

The sample case itself is 1.9 MB, due to the fact that I use a mesh generated using Netgen. If anyone wants to take it for a spin, let me know and I can send it via E-mail.

The only problem I have, is that when I use an adaptive time step for the fluid solver (turbFoam based), with a limit on the maximum Courant number being 0.5, the time step goes down to around 2.8e-07, and the simulation takes ages to complete (though each iteration itself it quite fast).

Is there any way of getting larger deltaT without affecting the simulation results too much?

Have a nice day!

Philippose

[msrinath80]

Hi Philippose,

Can you send me a recent test case plus the latest version of your solver. My email address is msrinath80@yahoo.com.

Thanks very much for your help.

[philippose]

Hi Srinath....

Just sent you a mail with the solvers + example case :-)!

Now... its sleepy time for me....! Man... almost time to wake up again :-O!!

Enjoy!

Philippose

[msrinath80]

Hi Phillippose,

Firstly nice job on the solver. Very impressive indeed. I do have a few comments/questions though.

1. Your default setup causes the solution to blow up (Floating point exception) toward the end. I reduced the maximum Co and it still blows up at Time = 0.00240107 (with or without viscous forces turned on). Since transientSimple does not have a Co limit, I will assume that the problem lies elsewhere (as Hrv mentioned a while ago the dispersion error can foul up the solution).

2. The way I see it now, you are constraining the motion in the Y direction which is why you don't solve for any angular momentum balances. So far so good.

3. The valve in the test case ascends and then descends quite nicely. However I saw no evidence of mesh getting skewed as the valve moved down etc. Have you done away with all those problems?

4. How exactly did you create the mesh? If for instance I wanted to have a sphere inside a rectangular box, would I mesh the sphere as a wall as usual and then the cellmotion solver would identify the patch marked sphere wall and move the points on the sphere surface accordingly?

Thanks for your time and help

[philippose]

Hi Srinath,

A Good day to you :-)!

Thanks for the feedback :-)! Nice to see that something worked! However before going into all the details of your post yet....

You mentioned that the simulation blew up after 2.4 ms of simulation time. Did you use turbForceFoam or simpleForceFoam? .... Reason for my question... the night I sent you the code, I had run the simulation up to around 15 ms, and noticed that the valve was just beginning to settle, which was why I had mentioned that it should settle in around 20 ms odd.... so.. the simulation got well past the level to which you were able to get to.

Hmmm... Maybe I should check out that case I sent you again to see if I changed anything before sending it to you :-)! I have this vague memory of having changed a time step for the force solver :-)! Need to check up!

Are you using the stock OpenFOAM 1.4.1?

Shall get back to you on this sometime soon!

Have a nice day!

Philippose

[philippose]

Hello again :-)!

I just ran the simulation again, and I think I know what may have gotten you worried.... at around 0.0024... , you see some iterations where Epsilon is continuously bounded.

Well... this is really not a problem... this is in the initial phase of the simulation.... but if you let it go on, it settles down without any hassles.

I am attaching the log file of the simulation I ran today, which goes up to around 0.013... seconds. I ran out of disk space soon after :-)! So had to stop.... but things are looking ok so far.

As for the other questions.... right now I am literally breaking my head over the ParaView 3 plugin for OpenFOAM... shall get back to you over the weekend (if not earlier :-)!)

Enjoy!

Philippose

log_excerpt.zip

[msrinath80]

Thanks Philippose. I will wait for your responses. I would like to try out some test cases myself.

[jason]

Hi Philippose,

Very interested in your solver and tried to test it out but I got an error as follows:

>turbForceFoam . forceBalanceTest

...
...
...

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: laplaceTetDecomposition


--> FOAM FATAL ERROR : solver table is empty

From function motionSolver::New(const polyMesh& mesh)
in file motionSolver/motionSolver.C at line 94.

FOAM exiting

I get 3 warnings when I compile your code

OpenFOAM/OpenFOAM-1.4.1/src/finiteVolume/lnInclude/readPISOControls.H: In function 'int main(int, char**)':
OpenFOAM/OpenFOAM-1.4.1/src/finiteVolume/lnInclude/readPISOControls.H:3: warning: unused variable 'nCorr'
OpenFOAM/OpenFOAM-1.4.1/src/finiteVolume/lnInclude/readTimeControls.H:40: warning: unused variable 'maxCo'

I used your latest files from the 27th April above.

Any chance you know whats wrong?

Regards

Jason

[philippose]

Hello Jason,

A Good evening to you!

Great to hear that you are interested in the solver :-)!

However, before you do anything further, I would strongly suggest that you use the latest version of the solver. The version from 27th April is quite old :-)!

Anyway... as for the error you are getting.... in the official version of OpenFOAM-1.4.1, the tetrahedral decomposition mesh motion solvers are not available. Only Finite Volume mesh motion solvers have been included with this version of OpenFOAM.

I modified the solver to use the finite Volume solvers instead, which would be one very good reason for you to switch to the latest version :-)!

The warnings that you get when compiling the source code are perfectly fine. They are harmless, and can be safely ignored.

I forked the solver into two paths... one which uses the PISO algorithm (modified version of icoFoam), and another one which uses the SIMPLE algorithm (modified version of transientSimpleFoam). I personally find the SIMPLE algorithm to be "less harder" on the system, so I almost exclusively use that... but you can choose based on your application and experience.

Here are the latest versions of both the streams:

simpleForceFoam.tar.gz

turbForceFoam.tar.gz

By the way... you need to change your selection of motion solver in the "dynamicMeshDict" to one of the finite volume ones.... and.... the location of the dictionary for the force solver has changed... it now looks for a file called "forceFoamDict" in the "constant" folder of your case.

Here is a sample of the "forceFoamDict", and the "dynamicMeshDict" :

forceFoamDict

dynamicMeshDict

If you have problems, or more importantly... improvements and bugfixes.... I would be really grateful to hear from you :-)!

Have a nice weekend!

Philippose

[jason]

Hi Philippose,

Many thanks for the files. I have to go away on business till late next week so I will try it out when I return. Looking forward to it!

Regards

Jason

[jason]

Hi Philippose,

Finally got around to playing with your code. Would you have an up to date test case that I can study?

I had one called forceBalanceTest but I'm not sure if that came from here or not and I cannot find it again.

Kind Regards

Jason

[cwang5]

Hi, I am wondering if this code works with OF-1.5? or is there an equivalent type of solver available in OF-1.5? Thanks

John

[louisgag]

Hello

There is the turbDyMFoam in OF 1.5 but I think you would have to implement fluid-structure interaction yourself (unless it has already been done on the development version).

I am also looking for such a solver in 1.5 and will keep you updated.

have a good day,

-Louis

[pablodecastillo]

So correctPhi is necessary or not??, i thought that in mesh motion with makeabsolute-makerelative, the flux was corrected.

Pablo