View Issue Details

IDProjectCategoryView StatusLast Update
0002387OpenFOAM[All Projects] Bugpublic2016-12-14 16:25
ReporterdkokronAssigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/Linux 4.8.12-200.fc24.x86_64OSFedoraOS Version24
Product Version 
Fixed in Version 
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

Motorbike
# 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

nacaAirfoil
# 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.

Activities

wyldckat

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.

wyldckat

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.

tniemi

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.

tniemi

2016-12-14 07:31

reporter   ~0007471

The behaviour has changed after this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/bd2fa2b800a195c9e5dcfa58b5052aafee510af6

tniemi

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;

tniemi

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.

henry

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.

henry

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.

tniemi

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.

chris

2016-12-14 14:44

manager   ~0007477

Corrected the function template files:

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

tniemi

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.

henry

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.

henry

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.

tniemi

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