[alexeym]

Move 0 folder to 0.org and retry with paraFoam. I really would like to know where is defaultFaces from the point of view of openfoam-extend-3.0.

Meanwhile I've generated mesh with OpenFOAM 2.2.2 and put case files with converted mesh to https://dl.dropboxusercontent.com/u/...ylinder.tar.gz (as it is too big for attachment).

[alexeym]

Originally Posted by Maimouna

It works perfect in OpenFOAM. I just go to p, U and changeDictionary files and commit
defaultFaces { type empty; }
and the visualization is shown in paraview. But I'm still being confused about lift and drag coefficients for Reynolds number 100? Any idea? What shall I change for Re = 100?

Did you forget to actually attach the visualization files?

[Maimouna]

Originally Posted by alexeym

Move 0 folder to 0.org and retry with paraFoam. I really would like to know where is defaultFaces from the point of view of openfoam-extend-3.0.

Meanwhile I've generated mesh with OpenFOAM 2.2.2 and put case files with converted mesh to https://dl.dropboxusercontent.com/u/...ylinder.tar.gz (as it is too big for attachment).

Alexey, what do you mean by move 0 folder to 0.org? There is no 0.org file.

What is the Reynolds number in your attached case?

[alexeym]

Originally Posted by Maimouna

Alexey, what do you mean by move 0 folder to 0.org? There is no 0.org file.

I meant rename 0 folder info 0.org, so paraFoam stop complaining about boundary conditions.

What is the Reynolds number in your attached case?

You have access to the case files. nu is 1.787e-3, inlet velocity is 0.1 m/s, D is 1 m. So it's around 56. If you'd like to use your original viscosity 1.787e-6, you need to reduce velocity, set U = 0.01 in BC files, reduce D, let's say D = 0.01787 (correct GEO file, regenerate mesh), and you'll have Re = 100. Also you'd need to modify forceCoeffs dictionary in controlDict to correspond to the new sizes.

[Maimouna]

Dear Alexey,

I attached paraview screen. Is that make sense?

You are using two walls on the top and bottom of the domain. Am I right?

[alexeym]

The screen shot shows internalMesh and all the patches, I'd like to see only defaultFaces patch, as with OF 2.2.2's gmshToFoam there is no such thing.

Also I've updated case files for the case with Re = 100 (https://dl.dropboxusercontent.com/u/...ylinder.tar.gz). You need around 9000 seconds for the flow to develop periodic vortex structure as inlet velocity is quite low. And my quickly made mesh is not so good in fact, you need to play with densities in different regions to make more or less uniform mesh, maybe create additional layer of cell between cylinder and the rest of the mesh.

[Maimouna]

Many thanks Alexey. I'm trying all posibilities now. I will let you know then what I would get. Moreover,

1. Did you try to plot velocity, drag and lift forces for that last case?

2. In the attached screenshot, you are using two walls on the top and bottom of the domain. You should use slip boundary conditions on these walls. You should only apply v = 0. The figure shows that you are applying both velocity components equal to zero on the top and bottom walls. Am I right?

[alexeym]

1. Well, I've plotted them, after 9000 s these plots have periodic structure. I did not check the values.

2. Patches top and bottom have empty type as we are running 2D simulation (assuming infinite height of the channel), so there is actually no BC there. I set non-slip BCs only on walls patch (usual BC for walls).

[Maimouna]

I got very high velocity that is imposible, isn't it? see the attached file please

[alexeym]

Where did you probe this velocity?

Also as I said the mesh is far from being even good. I've tried another more uniform mesh with grading towards the cylinder and the results are more beautiful. I'll post case files as soon as it will finish running.

[Maimouna]

I probe this velocity from the output file which gives forces. It gives time, cm, cd, cl, cl(f) and cl (r). I think cm represents velocity. Isn't it?

I don't know what are cl(f) and cl(r)?

I'm looking forward to get the new mesh. With lots of thanks.

[alexeym]

Meanwhile,

here's how Cm is calculated:

...
scalar pDyn = 0.5*rhoRef_*magUInf_*magUInf_;
...
Field<vector> totMoment(moment_[0] + moment_[1] + moment_[2]);
...
coeffs[2] = (totMoment & pitchAxis_)/(Aref_*lRef_*pDyn);
...
scalar Cm = sum(coeffs[2]);

So it depens on the values given in controlDict, if there's a mistake in the values, Cm can be also wrong.

[Maimouna]

Dear Alexey,

the last changes that I did for Reynolds number= 100, I fix U=1.0 , D = 1.0 and changed the value of nu = 0.001. But unfortunately, I didn't solve the convergence problem for lift and drag coefficients which gave very high value. Do you get the result for your case?

My last changes and the graph shown drag coefficient were attached.

If you have any idea let me know please. Many thanks in advanced.

[alexeym]

As I said, calculation of Cm, Cd, and Cl depends on the properties you've used in forces dictionary in controlDict. If you put there wrong values of CofR, lRef or Aref, you'll get very strange values in the forcesCoeffs.dat.

Here is the new mesh - https://dl.dropboxusercontent.com/u/...inder-n.tar.gz. I've reduced D, modified controlDict to correspond to the new mesh and velocities. At Re=100, I've got no vortexes (maybe did not wait enough), so I've increased inlet velocity ten times, now Re=1000.

You need to ignore initial values of force coefficients as the initial flow is not physical.

Check the parameters of the mesh, initial conditions, contents of forces dictionary before running the case. As I don't know what you are trying to do (except development of vortex street) they can be wrong.

Maybe also you'll need to reduce density of the mesh, now it's rather fine, so running time can be unacceptable. In the GEO file density of the mesh is controlled by RHO{1..6} variables.

[Maimouna]

Dear Alexey,

many thanks. I'll check everything, then I'm going to inform you about the final result.

[Maimouna]

Dear Alexey,

In force function in controlDict file, is the following meaning correct?

a.) magUInf is relative velocity.
b.) lRef is length of the domain (21 m in my case?)
c.) Aref is area of the domain (rectangular area + cylinder area in my case?)
d.) What does CofR mean?

I'm still trying to solve my problem regarding velocity, lift and drag coefficients. Any idea?

[alexeym]

If you take a look at $FOAM_SRC/postProcessing/functionObjects/forces/forceCoeffs/forceCoeffs.H, you will be able to find this comment:

    \heading Function object usage
    \table
        Property     | Description             | Required    | Default value
        ...
        patches      | patches included in the forces calculation | yes |
        liftDir      | lift direction          | yes         |
        dragDir      | drag direction          | yes         |
        pitchAxis    | picth axis              | yes         |
        magUInf      | free stream velocity magnitude | yes  |
        lRef         | reference length scale for moment calculations | yes |
        ARef         | reference area          | yes |
        ...
    \endtable

So magUInf is an inlet velocity. AFAIK lRef should be characteristic length of the cylinder (i.e. diameter), ARef is the cylinder frontal area (i.e. D*D, as a height of the mesh is D). For CofR you should look at $FOAM_SRC/postProcessing/functionObjects/forces/forces/forces.H:

    \heading Function object usage
    \table
        Property     | Description             | Required    | Default value
        ...
        CofR         | centre of rotation (see below) | no   |
        ...
    \endtable

so I guess in this case it should be a center of the cylinder.

[Maimouna]

Dear Alexey,

now I understand the meaning of each forces coefficients. After I did changes regarding my case ( I fixed D=1, U = 1 and nu = 0.001 to get Re = 100), but unfortunately it gives me the following error

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam222/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam222/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam222/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/openfoam222/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam222/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) in "/opt/openfoam222/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#7
in "/opt/openfoam222/platforms/linux64GccDPOpt/bin/pimpleFoam"
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9
in "/opt/openfoam222/platforms/linux64GccDPOpt/bin/pimpleFoam"
Floating point exception (core dumped)
maimouna@maimouna-desktop:~/OpenFOAM/maimouna-2.2.2/run/tutorials/incompressible/pimpleFoam/circularCylinderNew$

What does it mean?

Could you please go through the attached file?

[alexeym]

I don't know why you've decided to increase initial deltaT to 0.01.

This is the reason for the error. Set it to smaller value (1e-3 or 1e-4, as I my original case files).

[Maimouna]

Many thanks. It is running now. I will contact you when get the result.