[wyldckat]

Dear OpenFOAM developers,

After various trial-and-errors with various distros and gcc 4.5.x versions, I've come to the conclusion that OpenFOAM's 1.6.x, 1.7.0 and 1.7.x versions (at least until today's 12pm UTC) have serious problems with the gcc 4.5 series.

List of distros/builds tested (all double precision):

• OpenFOAM 1.7.0, gcc 4.5.1 (edit: 20100730 (prerelease))+mingw-w64 for cross-compiling to Windows (both 32 and 64bits, pre-built cross-compilers from mingw-w64 sf.net project page);
• OpenFOAM 1.7.0, custom build of gcc 4.5.0 in Ubuntu 9.10 x86_64;
• OpenFOAM 1.7.x, system gcc 4.5.0 in OpenSUSE 11.3 i586.

With all of these builds, the following tutorials were detected to have failed to work properly:

• basic/potentialFoam/cylinder
• compressible/rhoPorousMRFPimpleFoam/mixerVessel2D
• electromagnetics/electrostaticFoam/chargedWire
• incompressible/MRFSimpleFoam/mixerVessel2D
• incompressible/nonNewtonianIcoFoam/offsetCylinder
• incompressible/simpleFoam/pitzDailyExptInlet
• incompressible/simpleSRFFoam/mixer
• multiphase/MRFInterFoam/mixerVessel2D
• stressAnalysis/solidDisplacementFoam/plateHole

Except for the pitzDailyExptInlet case, these tutorials failed at the blockMesh stage (it finishes successfully with no indication of error), apparently because they have arc edges in blockMeshDict. The generated meshes have no arc edges in them and the damaged values can be either very small (<10e-200) or very large (>10e-200); checkMesh gives various indications of the meshes being flawed.
The pitzDailyExptInlet case failed when running simpleFoam, quitting with a "DTRIS2 - Fatal error!" message (and respective stack dump); checkMesh doesn't give any indications that the mesh is flawed.

Additionally, I've seen another bug report made a few days ago that points to another issue that I didn't detect (since the applications didn't crash with that tutorial case), but it should also be because of OpenSUSE's 11.3 gcc 4.5.0: porousSimpleFoam bug in 1.7.x


So, in the short run, I suggest that you add a note in the source/git pages warning about gcc 4.5!
Because I remember that when OpenFOAM 1.6 was released, it simply didn't build with gcc 4.4, so that refrained most users from aimlessly using it and simply switched to the custom gcc 4.3.3 build. But in this case, it's seriously worse: OpenFOAM 1.6.x-1.7.x do build with gcc 4.5 and have no explicit warning (that I've seen) indicating that OpenFOAM might not work properly!


Side note for OpenSUSE 11.3 users: you can install gcc 4.3.4 in YaST, thus avoiding the need to do a custom gcc build.

Best regards,
Bruno


EDIT: see post #10 for the fix for OpenFOAM 1.6.x and 1.7.0. OpenFOAM 1.7.x is now fixed.

[alberto]

I can confirm this problem. The meshes generated in the test cases you listed are not valid, and the solver fails before performing the first iteration. This happens on openSUSE 11.3 - gcc 4.5.0 20100604 [gcc-4_5-branch revision 160292] - 64 bit.

The problem with simpleFoam on pitzDailyExptInlet seems of different origin, and related to a segFault(int) in the timeVaryingMappedFixedValueFvPatchField boundary condition.

Thanks for reporting this, even if they're not good news, since I have to validate a code again, since I wrote and developed it only with gcc 4.5 on openSUSE 11.3. :-(

[chibsen]

I have tested that porousSimpleFoam gives correct result when compiling 1.7.x with gcc 4.3.4 in openSUSE 11.3

Thanks, Claus.

[heather]

Thanks for the report - we will look into it.

Andy

[alberto]

Results are fine also with gcc 4.5.x, so it seems a limited problem :-)

[wyldckat]

Originally Posted by alberto

Results are fine also with gcc 4.5.x, so it seems a limited problem :-)

Me and my big mouth... I should have stated gcc 4.5.0 and 4.5.1 pre-release, instead of simply 4.5.x
Alberto, could you please you specify if 4.5.x>=4.5.1 or 4.5.x>4.5.1?

Best regards,
Bruno

[alberto]

No, I cannot confirm 4.5.x, with x >= 1, since I use 4.5.0 (fcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux)) in openSUSE 11.3. What I meant is that in general, code works, and results are reliable, but I can reproduce the problems you reported. The problem seems limited to a few parts of the code however.

Best,

[mattijs]

I've done a bit of digging and see problems running valgrind on blockMesh for the potentialFoam/cylinder tutorial. It somewhere calls arcEdge:osition(..) and this seems to reference an uninitialised location in the coordinate system. I cannot see anything wrong in the code. If I compile all of the relevant code with -O0 or -O1 it runs through fine so my current guess is that there is an optimiser bug in 4.5.

This is gcc-4.5.0 release, 64bit on Ubuntu.

Can someone try using -O1? (change in $WM_DIR/rules/$WM_ARCH$WM_COMPILER/c++Opt)

[mattijs]

On my local blockMesh compilation I can trigger the uninitialised location problem by adding -fstrict-aliasing to -O1 compilation. So it works with plain -O1 but not anymore if I add the -fstrict-aliasing optimisation (this is one of the optimisations switched on by -O2).

[wyldckat]

Greetings to all!

Originally Posted by mattijs

On my local blockMesh compilation I can trigger the uninitialised location problem by adding -fstrict-aliasing to -O1 compilation. So it works with plain -O1 but not anymore if I add the -fstrict-aliasing optimisation (this is one of the optimisations switched on by -O2).

Mattijs, following your discovery, I've tested adding the option "-fno-strict-aliasing" along with "-O3" and it did the trick! All of the tutorials reported on the first post seem to be working fine once again with gcc 4.5.x.
I've only tested with 32 bit builds so far:

• OpenFOAM 1.7.0, gcc 4.5.2 (edit: 20100813 (prerelease))+mingw-w64 for cross-compiling to Windows
• OpenFOAM 1.7.x (pulled a couple of hours ago), system gcc 4.5.0 in OpenSUSE 11.3 i586.

I copied the wmake rules from the standard linuxGcc and linux64Gcc folders and added that option:

cd $WM_DIR/rules
cp -r linuxGcc linuxGcc45
cp -r linux64Gcc linux64Gcc45
for file in linux64Gcc45/c++Opt linux64Gcc45/cOpt linuxGcc45/c++Opt linuxGcc45/cOpt
do
sed -i -e 's=-O3=-O3 -fno-strict-aliasing=' $file
done

NOTE: I only did it for the "WM_OPTIONS=Opt", but I believe it should also be done for the Prof option.
NOTE2: I think I overdid it in adding it to cOpt too...

I also changed the WM_COMPILER option in "$WM_PROJECT_DIR/etc/bashrc" from Gcc to Gcc45, so these new rules could be used.


So, if more people can confirm this, then I can edit the title in the first post to add [SOLVED] to it


Side note: I've got the impression that the "-Wno-strict-aliasing" option in "c++WARN", which is in the local "c++" rule file, is what has been hiding this issue with gcc 4.5.x... but I haven't tested removing that option, because I've got a feeling that a lot of warnings are going to pop up during Allwmake...

Side note 2: Mattijs, you mentioned that something got broken in gcc 4.5.0... here is the release note associated to this flag:

Originally Posted by http://gcc.gnu.org/gcc-4.5/changes.html

The infrastructure for optimizing based on restrict qualified pointers has been rewritten and should result in code generation improvements. Optimizations based on restrict qualified pointers are now also available when using -fno-strict-aliasing.

Best regards,
Bruno

[alberto]

I can reproduce what observed by Bruno on my openSUSE 11.3.

Best,

[mattijs]

Thanks. It seems to be the aliasing in Tensor.H. I think I've got the fix. Will push once tested.

[mattijs]

I've pushed a fix into 1.7.x. It will force a full rebuild. The problem was that we were slicing a Tensor into three vectors and this works only under some circumstances.

Changes:
- Tensor::x(), y() etc. return a (const) vector, not a const reference. (the returned vector is const for now to catch illegal use)
- There are no more non-const x(), y(),z() functions to inplace modify vectors of the tensor. You'll have to create a new tensor and assign. There is a new construct-from-vectors constructor for tensors.
- Fed through these changes (return copy, not reference) into coordinateSystem,coordinateRotation
- removed the Wno-strict-aliasing warning suppression

Thanks all for reporting,

Mattijs

[Bufacchi]

guys,

I couldn't be more confused.

I'm using Suse 11.3 and tried to rollback to gcc 4.3.4 and recompile OF 1.7.x. It was a total disaster.

Are you going to deliver the OF 1.7.x code ready for gcc 4.5.0? If yes, do you have a delivery date?

Thanks,

Paulo

[alberto]

It has already been delivered, as per Mattijs post above you.

Simply run 'git pull' in your OpenFOAM/OpenFOAM-1.7.x and then rebuild it with ./Allwmake

Best,

[Aleksey_R]

Dear colleagues!

I have a problem with OF-1.6 installation on OpenSUSE-11.3. All third party software have installed ok, but OF itself - not. I've tried to change the wmake rules as you advise, but that didn't help.

Did anyone try to install OF-1.6 on Suse 11.3? Please, help!

Best regards, Aleksey.

[alberto]

I would suggest to use 1.7.1 or 1.7.x, since it works out of the box on openSUSE 11.3.

[wyldckat]

Greetings to all! Aleksey,

Originally Posted by Aleksey_R

I have a problem with OF-1.6 installation on OpenSUSE-11.3. All third party software have installed ok, but OF itself - not. I've tried to change the wmake rules as you advise, but that didn't help.

OpenFOAM 1.6 will only build with gcc 4.3.x; OpenFOAM 1.6.x can use both gcc 4.3.x and 4.4.x; OpenFOAM 1.7.1 and 1.7.x can use gcc 4.3.x, 4.4.x and 4.5.x.

So, if you really need OpenFOAM 1.6 working on your OpenSUSE 11.3, then follow these instructions for building gcc 4.3.3: "Installation" page on openfoamwiki.net - section "2.3.5.2 Building"
It also explains on how to use gcc 4.3.3 with OpenFOAM 1.6

Best regards,
Bruno

[Aleksey_R]

All my solvers have been successfully compiled in OF1.7.1. So, I don't need OF-1.6 any more :-)

Thanks for help, gentlemen!