[antonio_ing]

I everybody.

Just a quick question: if I have a 2d geometry with a single cell with thickness 2.5mm in the Z direction and I run the forces utility, the torque will be the one generated by those 2.5 mm. So, if I want the torque generated for 1 meter depth, I have to multiply for 400. Is that correct?

[yuhai]

hei, Antonio,
My experiment with depth 0.1M leads to a 1/10 torque comparing with Fluent.
I think most times, it is right.

[leopaul]

hi,
I was following Srinath's procedure for compilation of liftdrag tool in of1.4.everything went ok till step 6 where after executing ./Allwmake i find that all other files except liftdrag.o are created and i get the following error message..its quite long! but since i've very little knowledge in o.f or ubuntu for that matter i decided to put the whole thing in..please help me out!!
P.S:the entire error message was too long ..i've taken bits from the start and the end..i hope this is a relevant post cause it deals with forces!ive searched the forum and no ones got this error

[leopaul]

hi,
this is the entire error message.
thanks.
leo

[ngj]

Hi Leo

You are missing your headers files. Install using:

sudo apt-get install build-essential

and you should be able to compile.

Best regards,

Niels

[msrinath80]

I think you have your answer now :-)

[leopaul]

hi,
Thanks a lot guys...will try that out..
Leo

[leopaul]

hi,
compiled succesfully..had to copy that foamutil file frm of1.2 as said in 1 of the posts after step7 tho..nw i've t fix the bug i guess and start off..thanks again guys..
Leo.

[marico]

Richard Samuel: Why is the the forceCoeff for an axisymmetric case calculated wrong? For example a infinite long circular cylinder in 2D as a half model?!
And how is your patch executed??

Thanks,
Marco

[tomislav_maric]

Hello everyone,

I'm trying to do a simulation of a ship on a free surface using interFoam and calculate the forces. I'm running 32bit Ubuntu 8.10 on Hp Compaq 6820s laptop with latest OpenFOAM-1.5-dev from the repo. This is what I've added to my controlDict:

functions
(
forces
{
type forces;
functionObjectLibs ("libforces.so");

patches (Hull_OBJECT);

rhoInf 1000;
CofR (0 0 0);
}
);

and this is the error I get:

(snipped the header)

Create time

Create mesh for time = 0


Reading environmentalProperties
Reading field pd

Reading field gamma

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Calculating field g.h

time step continuity errors : sum local = 3.71483e-07, global = 4.68522e-11, cumulative = 4.68522e-11
PCG: Solving for pcorr, Initial residual = 1, Final residual = 8.66164e-11, No Iterations 204
time step continuity errors : sum local = 3.21776e-17, global = 2.07916e-19, cumulative = 4.68522e-11
Courant Number mean: 0.0005283 max: 0.00883279 velocity magnitude: 7.49691

Starting time loop

Courant Number mean: 0.010566 max: 0.176656 velocity magnitude: 7.49691
deltaT = 0.02
Time = 0.02

MULES: Solving for gamma
Liquid phase volume fraction = 0.790868 Min(gamma) = -6.562e-19 Max(gamma) = 1
MULES: Solving for gamma
Liquid phase volume fraction = 0.790866 Min(gamma) = -1.18035e-18 Max(gamma) = 1
PCG: Solving for pd, Initial residual = 0.999223, Final residual = 0.023873, No Iterations 3
PCG: Solving for pd, Initial residual = 0.0133212, Final residual = 0.000661896, No Iterations 13
PCG: Solving for pd, Initial residual = 0.00127542, Final residual = 9.36798e-08, No Iterations 150
time step continuity errors : sum local = 1.18414e-07, global = 4.01111e-10, cumulative = 4.47963e-10
ExecutionTime = 40.54 s ClockTime = 46 s

Courant Number mean: 0.0118945 max: 0.811429 velocity magnitude: 57.9195
deltaT = 0.01


keyword nu is undefined in dictionary "/home/tomislav/OpenFOAM/tomislav-1.5-dev/run/semestralniProjekt/brod_interFoam/constant/transportProperties"

file: /home/tomislav/OpenFOAM/tomislav-1.5-dev/run/semestralniProjekt/brod_interFoam/constant/transportProperties from line 21 to line 32.

From function dictionary::lookupEntry(const word& keyword) const
in file db/dictionary/dictionary.C at line 213.

FOAM exiting


tomislav@icarus:brod_interFoam$ *** glibc detected *** /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linuxGccDPOpt/interFoam: double free or corruption (fasttop): 0x0adb26b0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb6be6454]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb6be84b6]
/home/tomislav/Software/gcc-4.3.3/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb6dd4271]
/home/tomislav/Software/gcc-4.3.3/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d )[0xb6db27cd]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libinterfaceProperties.so(_ZN4Foam4wordD1Ev+0x63)[0xb7ed26f3]
/lib/tls/i686/cmov/libc.so.6(exit+0x89)[0xb6ba5d89]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libOpenFOAM.so(_ZN4Foam7IOerror4exitEi+0x20a)[0xb6f437ba]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libOpenFOAM.so(_ZNK4Foam10dictionary11lookupEntryE RKNS_4wordEb+0xec)[0xb6f8df7c]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libOpenFOAM.so(_ZNK4Foam10dictionary6lookupERKNS_4 wordEb+0x2c)[0xb6f8dfbc]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libforces.so(_ZNK4Foam6forces10devRhoReffEv+0xee5)[0xb0bee085]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libforces.so(_ZNK4Foam6forces16calcForcesMomentEv+ 0xc8)[0xb0bee528]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libforces.so(_ZN4Foam6forces5writeEv+0x52)[0xb0bec112]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libforces.so(_ZN4Foam26OutputFilterFunctionObjectI NS_6forcesEE7executeEv+0x56)[0xb0c0e176]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libOpenFOAM.so(_ZN4Foam18functionObjectList7execut eEv+0x6b)[0xb6fb136b]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libOpenFOAM.so(_ZN4Foam4TimeppEv+0x48)[0xb6fb93d8]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libOpenFOAM.so(_ZN4Foam4TimeppEi+0x11)[0xb6fb9131]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linuxGccDPOpt/interFoam[0x80641bb]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb6b8d685]
/home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linuxGccDPOpt/interFoam[0x8061551]
======= Memory map: ========
08048000-080da000 r-xp 00000000 08:03 7358876 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linuxGccDPOpt/interFoam
080da000-080dc000 rw-p 00091000 08:03 7358876 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linuxGccDPOpt/interFoam
09c63000-0b537000 rw-p 09c63000 00:00 0 [heap]
aba96000-abec3000 rw-p aba96000 00:00 0
ac6f5000-acf27000 rw-p ac6f5000 00:00 0
ad352000-ad77f000 rw-p ad352000 00:00 0
adbac000-aedb5000 rw-p adbac000 00:00 0
af8e3000-afce8000 rw-p af8e3000 00:00 0
b0115000-b026c000 rw-p b0115000 00:00 0
b03c3000-b07f0000 rw-p b03c3000 00:00 0
b0b3a000-b0bd9000 r-xp 00000000 08:03 18745 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libLESfilters.so
b0bd9000-b0bdb000 rw-p 0009e000 08:03 18745 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libLESfilters.so
b0bdb000-b0c1b000 r-xp 00000000 08:03 18755 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libforces.so
b0c1b000-b0c1c000 rw-p 00040000 08:03 18755 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libforces.so
b0c1c000-b0c1d000 rw-p b0c1c000 00:00 0
b0ecb000-b144f000 rw-p b0ecb000 00:00 0
b18cc000-b19cd000 r-xp 00000000 08:03 18748 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libcompressibleLESModels.so
b19cd000-b19d1000 rw-p 00100000 08:03 18748 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libcompressibleLESModels.so
b19d1000-b1b4f000 r-xp 00000000 08:03 18744 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libcompressibleRASModels.so
b1b4f000-b1b52000 rw-p 0017e000 08:03 18744 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libcompressibleRASModels.so
b1b52000-b1ca9000 rw-p b1b52000 00:00 0
b1e30000-b1e56000 r-xp 00000000 08:03 18746 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libLESdeltas.so
b1e56000-b1e57000 rw-p 00026000 08:03 18746 /home/tomislav/OpenFOAM/OpenFOAM-1.5-dev/lib/linuxGccDPOpt/libLESdeltas.so
b1e57000-b1e97000 r-xp 00000000 08:03 18728 /home/tomislav

... and so on....

I've tried using forces in icoFoam as a test and everything worked ok, as with simpleFoam. I even have a Python script somewhere that extracts the data for nice plots of calculated magnitudes of both forces and moments. Email me and I'll send what I have.

The forces directory is written, but since the simulation stops before first timeStep it contains only the title comment of the forces and moments components.

From what little I understand C++ i think that the code is having trouble seeing through nested dict-s in transport properties. But if so, why doesn't it complain in the start at "reading transportProperties"? Should I tamper with the source code to adjust it for interFoam? Has anyone seen this before? What's with the glibc error? I've had the same error using other solvers, but they ended normaly, and the forces directory was written.

I've tried to build it using wmake, and it was up to date (as expected, since it works fine with other solvers). I've deleted the functions entry in controlDict and the simulation is running fine for a whole day.


Tomislav

[tomislav_maric]

to answer myself: forces lib has trouble finding the right nu in the transportProperties dict for interFoam cases.

in the

~/OpenFOAM/OpenFOAM-1.5-dev/src/postProcessing/forces/forces.C

go to line number 101 and look around

else if (obr_.foundObject<dictionary>("transportProperties "))
{
const dictionary& transportProperties =
obr_.lookupObject<dictionary>("transportProperties ");

// This is really stupid: it presumes that the water is the
// phase1 (just like damBreak tutorial), and takes it's
// viscosity for reference calculation.

dimensionedScalar nu(transportProperties.lookupEntry("phase1").dict( ).lookup("nu"));

// ORIGINAL line is this one below
//dimensionedScalar nu(transportProperties.lookup("nu"));

const volVectorField& U = obr_.lookupObject<volVectorField>(Uname_);

return -rhoRef_*nu*dev(twoSymm(fvc::grad(U)));
}



I've commented the original troublesome part:
//ORIGINAL line
//dimensionedScalar nu(transportProperties.lookup("nu"));

because it tries to search for "nu" in transportProperties, and "nu" is nested within "phase1" or "phase2" subdictionary, so I've added this:

dimensionedScalar nu(transportProperties.lookupEntry("phase1").dict( ).lookup("nu"));

and it works now (writes the forces in forces directory). The downside to this stupid solution is that you write forces for the phase1. In my case it's the forces imposed by the water, because these forces are kind of important for a ship (at least i think so ).

Does anyone have any suggestion or comment on this? I think this solves my problem for now, but I'm not even sure of that.

Awaiting for floating point exception error,

Tomislav

[lakeat]

oops, I'm late again to join the discussion.
libforces.so works fine for me, I think it's better than the old liftDrag utility, very flexible and dynamic!
Thanks to OF developers.

[blaise]

Dear Foamers,

I hope this thread is still alive. I am fairly new to OpenFOAM, but have some experience with CFX. I am using OpenFOAM1.5-dev on a selfmade exercising case, which is a wedge like case but with some cells in circumferential direction (common three dimensional case in turbo machinery, I think). So it is rotationally symmetric. In the center of the wedge there is a section of a small torpedo like body. The whole is somehow similar to a piece of cake with a small bite of it taken away from the tip. :-)

I am trying to calculate the steady drag force on this body section in water with a speed of about 6m/s (Re=10^7) using the simpleFoam solver, but compared to the CFX results, I get wrong results for x pressure force from OF, and I am lost now. Strange enough, all other components are fairly eqal to the CFX results. I used the same grid for the calculations.

The setup is as follows (I will give only the essentials):

INLET
{
type patch;
nFaces 459;
startFace 173842;
}
OUTLET
{
type patch;
nFaces 459;
startFace 174301;
}
AUSSEN // outer boundary of domain
{
type slip;
nFaces 1071;
startFace 174760;
}
SB1 // first patch of axial symmetric wedge
{
type cyclicGgi;
separationOffset (0 0 0);
rotationAxis (1 0 0);
rotationAngle 10;
shadowPatch SB2;
bridgeOverlap false;
nFaces 6761;
startFace 175831;
}
SB2 // second patch of axial symmetric wedge
{
type cyclicGgi;
separationOffset (0 0 0);
rotationAxis (1 0 0);
rotationAngle -10;
shadowPatch SB1;
bridgeOverlap false;
nFaces 6761;
startFace 182592;
}
GONDEL1 // surface patch of the body to retrieve forces of
{
type wall;
nFaces 990;
startFace 189353;
}

In the controlDict I use:
application simpleFoam

and forces by:
functions
(
forces
{
type forces;
functionObjectLibs ("libforces.so");
patches (GONDEL1);
rhoInf 1025.87;
CofR (0 0 0);
}
);

In RASProperties I set:
RASModel kOmegaSST;

In transportProperties:
transportModel Newtonian;
nu nu [0 2 -1 0 0 0 0] 1.1883e-06;
rho rho [1 -3 0 0 0 0 0] 1025.87;

Originally, the density is not set in this file (in the tutorials), but I found this in some posting, and tried it. Anyway, it does not seem to cause any change in the results.
So, in what cases is it useful to set it?

Values for boundary conditions are:
U:
dimensions [0 1 -1 0 0 0 0];
internalField uniform (6.0923 0 0);
boundaryField
{
INLET
{
type fixedValue;
value uniform (6.0923 0 0);
}
SB1
{
type cyclicGgi;
}
SB2
{
type cyclicGgi;
}
OUTLET
{
type zeroGradient;
}
AUSSEN
{
type zeroGradient;
}
GONDEL1
{
type fixedValue;
value uniform (0 0 0);
}
}

p:
dimensions [0 2 -2 0 0 0 0];
internalField uniform 0;
boundaryField
{
INLET
{
type zeroGradient;
}
SB1
{
type cyclicGgi;
}
SB2
{
type cyclicGgi;
}
OUTLET
{
type fixedValue;
value uniform 0;
}
AUSSEN
{
type zeroGradient;
}
GONDEL1
{
type zeroGradient;
}
}

omega (using epsilon and k, which I calculated in the same way as is done in the user guide):
dimensions [0 0 -1 0 0 0 0];
internalField uniform 0.015;
boundaryField
{
INLET
{
type turbulentMixingLengthFrequencyInlet;
mixingLength 4;
k k;
value 0.015;
}
...

k:
dimensions [0 2 -2 0 0 0 0];
internalField uniform 0.004865;
boundaryField
{
INLET
{
type fixedValue;
value 0.004865;
}
...


RESULTS:

The results from OF are (only forces):
2750 ((11.1798 152.876 13.3751) (4.76695 0.254509 0.0178232))

The results from CFX are (ordered in the same manner):
1924 ((0.77298 133.43 11.674) (3.6813 0.21366 0.018662))

The pressure distribution on the GONDEL1 patch looks very similar in CFX and OF, but the value ranges differ slightly (p, not p*):
CFX: -4284 to 18850
OF: -5223 to 24892

Due to our long term experience with CFX I can almost certain exclude the possibility of a mistake in the CFX setup. I suppose I missed something very basic in OF, but I cannot figure it out.

Any hint is warmly appreciated!

Thanks,

Pascal.

[-mAx-]

I have a question about the forces.c which generates the file forces.dat
if I plot the result vs Time in gnuplot, I am not able to see the first components of the vectors.
I think gnuplot ignore those values because of the "("
Is there a workaround in gnuplot, which skip all the "("?

[wolle1982]

use the forceCoeffs Tool. Set v=1, A=1,63 in controlDict so the tool calculates the CL values as if there were the L values.

[-mAx-]

Originally Posted by wolle1982

use the forceCoeffs Tool. Set v=1, A=1,63 in controlDict so the tool calculates the CL values as if there were the L values.

yes, I have already tested this trick , but I wanted to use the force, for plotting the convergence of the pressure inlet ( I was septic because of the non-wall type, but it's ok ).
So I get the pressure force at the inlet (this is the x-axis in my case ) and I divide it with the inlet-area
On the other hand, the viscous effects should be negligible, so I can work with the total force, eg: the coefficients

[-mAx-]

To filter the opening parenthesis in gnuplot
>plot "<sed 's/(/ /g' forces.dat" u 1:2 w l

[blaise]

Originally Posted by wolle1982

use the forceCoeffs Tool. Set v=1, A=1,63 in controlDict so the tool calculates the CL values as if there were the L values.

Hello wolle1982,

was this posting meant as a reply to my posting from May, 7th (don't understand the Linkback URL completely, but this is the only reference URL I can find for my posting: http://www.cfd-online.com/Forums/ope...rces-of15.html) about the wrong x forces in OF and the comparison to CFX?
If this is the case, I do not understand where the A=1.63 value comes from?
If this posting is a reply to mAx question about filtering of "(" in gnuplot, then I do not understand the correlation either.
Please shed a little light on this.

Thank you!

Cheers,
Pascal.

[wolle1982]

Hi blaise,

was a reply to mAx post.

if on a wing the lift is L = 0.5 * rho * u^2 * A * cL

and you take U as 1m/s and the area A=1.63 m², then you get the values of cL as if they were the lift L. because 1.63 is the reciprocal of 0.5*rho .......

i think the results of the drag are calculated too high in OF (or forces-tool). I also have problems calculating an airfoil. drag is too high about 15% compared to windtunnel measurements. but the fit the calculated values of FLOWer e.g.

[yuhai]

hi ,dear foamers,
I am not sure whether the default density of liquid for turbFoam is air ? 1.29 or 1.225?
if I want to specify it, I should introduce a item in turbulenceProperty "rho" following nu?

thanks!

Cheers