[lr103476]

Hi everybody,

As I showed on the workshop 2 weeks ago, the 'new' finite volume mesh motion solver is a lot faster than the other decomposition motion solvers. (At least, for my cases). Unfortunately, I also showed that the solution obtained around a plunging cylinder is different when comparing 1.3 (development release) and 1.4 (official release with added patch).

In order to isolate this problem, I performed a comparison of the transient drag coefficient for static cylinders (both steady Re=40 and unsteady Re=150). For this I used the same discretisations, boundary conditions and iterative solver settings for both solvers, 1.3 and 1.4,

To conclude, the solutions (steady and unsteady) for the static cylinder case is precisely the same using both solvers 1.3 and 1.4. Unfortunately, when the mesh moves in the plunging cylinder case, the unsteady solution is really different, which could be the result of different mesh motion solvers. Or the mesh motion flux is treated somewhat different. But of course, that should not cause such a difference in solution.



More detailed info on my webpage:
http://www.aero.lr.tudelft.nl/~frank...mparison13vs14

This really need to be sorted out, since a lot of people are using the mesh motion solvers, and know I don't know which one to use.

Best regards,
Frank

[alberto]

Any comparison with other codes/results? What version gives the most reasonable solution?

Regards,
A.

[lr103476]

I can't use this moving mesh in Fluent (the only other code that we have). Right now, I try to do a comparison with literature (drag coefficients) on larger domains and denser meshes. We'll see what comes out.

Has anyone more ideas about (simple) testcases (comparisons with literature.....) using moving meshes?

Regards, Frank

[hugo_pedro]

Hi all,
I can help to sort out this issue.
I am able to solve this case using the commercial code comsol, I already did some successful attempts, however before I post the results here I would like to make sure my setup is equivalent to Frank's setup. Therefore I would like to ask Frank for more details, namely:
the cylinder motion equation;
the placement of the outer boundaries;
the boundary equations used.
At last I would like to know if the drag coefficient shown here is the force projected in the X direction or the force in the resultant velocity direction.

Regards,
Hugo

[lr103476]

Dear Hugo,

That would be nice, but how do you know that your comsol solution is correct? The problem is that when I compare the mean drag coefficient, obtained using both OF-1.3 and OF-1.4, with literature I could be satisfied, but in my view their should be zero difference between OF-1.3 and OF-1.4.

Besides, there is no literature of detailed forces of plunging cylinder flow. For very few plunging frequencies / amplitudes you'll find average drag and wake frequency. In my view, the force amplitudes need to be solved accurately as well, but I can't find proper references.

Concerning this validation of 'complex' cases, I'd like to create some benchmark cases using Fluent of plunging cylinder / sphere flow such that I can validate OpenFOAM with that. In such a way I can compare all parameters I like :-)

I've already shown that OpenFOAM appears to have less numerical diffusion compared to Fluent, which has resulted in a lower drag amplitude for Fluent. I have no reason to believe that ComSol solves this drag amplitude as accurate as OpenFoam. Summarizing, validation for these unsteady moving cylinder stuff is very very difficult, at least if you're as fussy as I am.

Please, if you're still interested drop me a mail.

Regards, Frank

[alberto]

Hi Frank,
sorry for the obvious question, but were the two OF solutions obtained using exactly the same solver settings (linear solvers, tolerances, ...)?

With kind regards,
Alberto

[lr103476]

yes. The new OF-1.4 also works with the 'old' OF-1.3 definition of solver settings. The only thing that is different is the way the mesh moves. OF-1.3 uses the tetDecomposition stuff, whereas OF-1.4 uses the new finite volume bases mesh motion.

Regards, Frank

[rolando]

Did you look at the time scheme?
If you use the backward scheme, do you use the version of backwardDdtScheme<type>::meshPhi() you posted in the forum once?
Henry posted corrected versions of the backward and the CrankNicholson scheme in the bug section.
(Whereas the uncorrected version seems to be the one of version OF-1.3)

Rolando

[lr103476]

yes, I use the last versions of those time schemes. I did simulations with Euler implicit, Backward and Crank Nicholson (CN=1.0), all with similar differences between OF-1.3 and OF-1.4.

Frank

[rolando]

Hm, it seems that at least the Euler scheme didn´t change from 1-3 to 1-4. So it doesn´t look like a time scheme problem.
I once had the problem, that a calculation of a mesh moving case which produced smooth results in 1-3 "diverged" in 1-4.
Using an other preconditioner cured the problem. (As I thought the divergence was result of some inattention of me, I didn´t look at the problem any longer and unfortunately I can´t reproduce it now.)
Did anyone have a look at the linear solvers?
Was there some change in the implementation of the preconditioners?

Rolando

[msrinath80]

I don't know if this is related. But I've noticed something a little strange when I use the new preconditioned CG solvers for solving pressure in icoFoam. While the default preconditioned ICCG gives a final residual for pressure equal to a large number like 31 for an initial residual of 1 (i.e. at the start of the simulation), the GAMG solver seems to do a better job at bringing the final residual to the order of 1e-7. Preconditioned ICCG in OF 1.4 seems to max out at 1001 iterations for quite some time. GAMG with GaussSiedel smoother on the other hand seems to help the pressure to converge as expected. It should be noted that the case in question is a 3D vortex-shedding simulation which ran nicely with OF 1.3 (both ICCG and AMG).

[msrinath80]

Hello Frank, I wonder if you had any success on this issue. Have you been able to figure out why there are differences between OF 1.3 and 1.4 solvers?

[lr103476]

Hi Srinath,

Up to know, I am not able to explain the difference between OF-1.3 and OF-1.4 for moving wall cases. But, after some more tests, I found the following:

1) Using moving cylinder cases, there is a difference between OF-1.3 and OF-1.4. This difference becomes larger and larger when the plunging amplitude increases.

2) Using static cylinder cases, there is zero difference between OF-1.3 and OF-1.4.

3) I used vortex decay / convection for further testing. OF-1.3 and OF-1.4 give the same solution (according to total energy and vorticity contours). This is the case for static and moving meshes (I just moved the internal mesh points).

==> The mesh motion is not the problem, but it seems that the treatment of the moving wall (mesh) is somewhat different in OF-1.3 and OF-1.4 causing different solutions for moving body cases. I am using exactly the same mesh motion for both codes, so the problem could be differences in discretization on moving meshes.

Since this is a very important problem (all engine and turbo people are using moving meshes and moving walls too), it would be nice if someone could do a similar comparison of a moving body using OF-1.3 and OF-1.4 like I did.

Regards, Frank

[msrinath80]

Thanks for the update Frank. One other thing. In one of the other posts in the forum, you mentioned that interFoam has moving mesh capability. Would you happen to have a sample case that shows how this can be used?

Thanks for your help!

[lr103476]

As I already mentioned, the moving mesh stuff is only present in interFoam 1.3.

Here is a nice testcase of a plunging cylinder submerged in water.



Regards, Frank

[lr103476]

www.aero.lr.tudelft.nl/~frank/files/cylinderInFluid.tgz