View Issue Details

IDProjectCategoryView StatusLast Update
0002387OpenFOAMBugpublic2016-12-14 16:25
Reporterdkokron Assigned Tohenry  
Status resolvedResolutionfixed 
PlatformGNU/Linux 4.8.12-200.fc24.x86_64OSFedoraOS Version24
Summary0002387: Build : 4.x-3d754f4a122d giving erroneous force coefficients
DescriptionThe force coefficients produced by 4.x-3d754f4a122d are zero for incompressible/simpleFoam/motorBike and tiny for compressible/sonicFoam/ras/nacaAirfoil

# Force coefficients
# liftDir : (0.000000e+00 0.000000e+00 1.000000e+00)
# dragDir : (1.000000e+00 0.000000e+00 0.000000e+00)
# pitchAxis : (0.000000e+00 1.000000e+00 0.000000e+00)
# magUInf : 2.000000e+01
# lRef : 1.420000e+00
# Aref : 7.500000e-01
# CofR : (7.200000e-01 0.000000e+00 0.000000e+00)
# Time Cm Cd Cl Cl(f) Cl(r)
1 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
2 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00

# Force coefficients
# liftDir : (-2.397330e-01 9.708390e-01 0.000000e+00)
# dragDir : (9.708390e-01 2.397330e-01 0.000000e+00)
# pitchAxis : (0.000000e+00 0.000000e+00 1.000000e+00)
# magUInf : 6.180220e+02
# lRef : 1.000000e+00
# Aref : 1.000000e+00
# CofR : (0.000000e+00 0.000000e+00 0.000000e+00)
# Time Cm Cd Cl Cl(f) Cl(r)
4e-08 1.646333e-301 1.332445e-301 2.609097e-301 2.950882e-301 -3.417852e-302
8e-08 2.941511e-301 2.299226e-301 4.730491e-301 5.306757e-301 -5.762652e-302

Steps To ReproduceBuild 4.x with either Intel-2017.1.132 or gcc-6.2.1 and run the unmodified tutorials mentions above.
TagsNo tags attached.



2016-12-13 00:58

updater   ~0007463

Preliminary diagnosis:

I tested in Ubuntu 16.06 with the system's GCC 5.4.0, using a 32-bit label build, and I was able to reproduce the error with "incompressible/simpleFoam/motorBike"... but the reproduction only occurred because I had an older build that was using code from commit 769940a and a possibly an even older a modified copy of the tutorial case from 4.x.

After I did the following to get and build commit 3d754f4:

  git pull
  ./Allwmake -update -j > log.make 2>&1

I then ran the tutorial case "incompressible/simpleFoam/motorBike" and the file was "postProcessing/forceCoeffs1/0/forceCoeffs.dat" was OK once again and identical to OpenFOAM 4.1.

On the other hand, the tutorial case "compressible/sonicFoam/ras/nacaAirfoil" still has the same reported problem, namely "postProcessing/forces/0/forceCoeffs.dat" has all values on the level of 1e-301.

 * Same happens with OpenFOAM 4.1 (Deb package) and OpenFOAM 4.0 (built from source), on the same system.
 * It does not happen with OpenFOAM 3.0.x.

A quick side-by-side diff with comparison with Meld for the 'forces' function objects and I didn't spot any changes that would _pop-out to me_ as the source of the problem.


2016-12-13 01:01

updater   ~0007464

PS: Got the same exact values on "compressible/sonicFoam/ras/nacaAirfoil" as reported, so it shouldn't be something due to uninitialized memory space.


2016-12-14 07:21

reporter   ~0007470

The tutorial nacaAirfoil is missing rho rhoInf; entry from the forceCoeffs and hence it will use the default VGREAT for rhoRef.


2016-12-14 07:31

reporter   ~0007471

The behaviour has changed after this commit


2016-12-14 08:20

reporter   ~0007472

Hmm, there might be a problem with compressible solvers when using forceCoeffs. In order to work, forceCoeffs needs to have rho rhoInf; entry, because otherwise rhoRef won't be set. However, for compressible solver it would be better not to have rho rhoInf; as it can mess up force calculation. However, there are several guards in forces.c, such as checking p.dimensions and what kind of thermo is in use, so it might work correctly nevertheless;


2016-12-14 08:55

reporter   ~0007473

It would probably be better, if forceCoeffs would always read rhoInf entry regardless of the rho setting. That would allow to have correct rho for forces.C (ie. not rhoInf in compressible) and still have valid rhoRef value in forceCoeffs.


2016-12-14 09:31

manager   ~0007474

I agree that 'rhoInf' should always be present and read for 'forceCoeffs' but it is not needed for 'forces' in compressible simulations so it might cause confusion if it is a required entry. I will consider the interaction between 'forceCoeffs' and 'forces' to resolve this.


2016-12-14 10:47

manager   ~0007475

I have implemented a correction to the handling of 'rhoRef' in 'forceCoeffs':
OpenFOAM-dev: commit f14e69bdc51458bff74589ab742e1714940fd355
OpenFOAM-4.x: commit fb57ecbfdf0db3ff4362eed7365724f3bb72247c

and running tests. Let me know if there are any problems.


2016-12-14 10:58

reporter   ~0007476

Just to note, in etc/caseDicts/postProcessing/forces/, both the forcesCompressible.cfg and forceCoeffsCompressible.cfg include forces.cfg, which sets rho rhoInf;

I don't know if these are used in any tutorials, but they could be modified now that rho rhoInf; is not needed.


2016-12-14 14:44

manager   ~0007477

Corrected the function template files:

OpenFOAM-dev: commit c3ca6de336dcb0dfb7cd69775b2fc025e5c7e1d9
OpenFOAM-4.x: commit 930eb454e4ac8bae110676a52874eeb22d5fe096


2016-12-14 15:00

reporter   ~0007478

I think the templates are now reasonable, but I noticed that rhoInf 1; (or rhoInf 1.225;) is missing from forceCoeffsIncompressible. I think it should be there similarily as it is in forceCoeffsCompressible.


2016-12-14 15:18

manager   ~0007479

In principle 'rhoInf' is not needed by 'forceCoeffs' for incompressible flow because the pressure is already normalized. However in the current structure requires 'rhoInf' is used by 'forces' and the divided out by 'forceCoeffs', I am investigating if this can easily be avoided.


2016-12-14 15:32

manager   ~0007480

Given that 'forceCoeffs' is derived from 'forces' and the raw force data is available from the access functions to the base-class it is probably more consistent if 'rhoInf' is specified in the same manner in 'forceCoeffs' as it is for 'forces' so we will add the 'rhoInf' entry in forceCoeffsIncompressible.cfg.


2016-12-14 16:11

reporter   ~0007481

Ok, I think everything is now ok from my part.

Issue History

Date Modified Username Field Change
2016-12-12 14:58 dkokron New Issue
2016-12-13 00:58 wyldckat Note Added: 0007463
2016-12-13 01:01 wyldckat Note Added: 0007464
2016-12-14 07:21 tniemi Note Added: 0007470
2016-12-14 07:31 tniemi Note Added: 0007471
2016-12-14 08:20 tniemi Note Added: 0007472
2016-12-14 08:55 tniemi Note Added: 0007473
2016-12-14 09:31 henry Note Added: 0007474
2016-12-14 10:47 henry Note Added: 0007475
2016-12-14 10:58 tniemi Note Added: 0007476
2016-12-14 14:44 chris Note Added: 0007477
2016-12-14 15:00 tniemi Note Added: 0007478
2016-12-14 15:18 henry Note Added: 0007479
2016-12-14 15:32 henry Note Added: 0007480
2016-12-14 16:11 tniemi Note Added: 0007481
2016-12-14 16:25 henry Assigned To => henry
2016-12-14 16:25 henry Status new => resolved
2016-12-14 16:25 henry Resolution open => fixed
2016-12-14 16:25 henry Fixed in Version => 4.x