View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002387 | OpenFOAM | Bug | public | 2016-12-12 14:58 | 2016-12-14 16:25 |
| Reporter | dkokron | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux 4.8.12-200.fc24.x86_64 | OS | Fedora | OS Version | 24 |
| Summary | 0002387: Build : 4.x-3d754f4a122d giving erroneous force coefficients | ||||
| Description | The 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 Reproduce | Build 4.x with either Intel-2017.1.132 or gcc-6.2.1 and run the unmodified tutorials mentions above. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
PS: Got the same exact values on "compressible/sonicFoam/ras/nacaAirfoil" as reported, so it shouldn't be something due to uninitialized memory space. |
|
|
The tutorial nacaAirfoil is missing rho rhoInf; entry from the forceCoeffs and hence it will use the default VGREAT for rhoRef. |
|
|
The behaviour has changed after this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/bd2fa2b800a195c9e5dcfa58b5052aafee510af6 |
|
|
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; |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Corrected the function template files: OpenFOAM-dev: commit c3ca6de336dcb0dfb7cd69775b2fc025e5c7e1d9 OpenFOAM-4.x: commit 930eb454e4ac8bae110676a52874eeb22d5fe096 |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Ok, I think everything is now ok from my part. |
| 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 |
