[vkrastev]

Hi all, I really don't know what the hell is going on with the installation of OpenFOAM on my new Ubuntu 10.10 64 bit based machine, so any help would be really appreciated...A brief summary of the story so far:

- I usually work on a Fedora based server and on my old notebook (Ubuntu 8.10). I've installed successfully on both of them OpenFOAM-1.6 (64 bit version on the server and 32 bit version on the notebook). After the installation I've also compiled my own modifications and add-ons to the source code and they work perfectly.

- Now I've changed my notebook and decided to install Ubuntu 10.10 64 bit and OpenFOAM 1.7.1 on it. Well, I've downloaded the source pack from the official OpenCFD site an built all (OpenFOAM and paraview) following the instructions: no errors, no strange messages, everything seemed ok, and in fact the tutorials worked perfectly.

- After that, I've implemented the same additional source code as before (basically a new turbulence model and a new wall function) and compiled it: after fixing some errors (probably due to slight differences between the 1.6 and 1.7.1 versions), the compiling procedure of the incompressible/RAS turbulence models source folder (./Allwmake) was succesfull, but the tutorials now have some strange issues with the wall functions (also with those I didn't touch at all) and during the first iteration a segmentation fault error causes the exit from the run.

- Well, maybe the problem was somewhere in the passage from 1.6 to 1.7.1, so ok, let's install the 1.6 64 bit version on the new machine! Again, downloading of the source pack and compiling, all seems good, the tutorials work. After that, compiling of the add-ons (this time with no errors at all) and....surprise! The same segmentation fault message! This is the error report form the airfoil2D tutorial (SpalartAllmaras model with nutSpalartAllmarasWallFunction at the wall, but the same is with other RAS models and wall functions):

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model SpalartAllmaras
SpalartAllmarasCoeffs
{
sigmaNut 0.66666;
kappa 0.41;
Cb1 0.1355;
Cb2 0.622;
Cw2 0.3;
Cw3 2;
Cv1 7.1;
Cv2 5;
}


Starting time loop

Time = 1

smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.00397212, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 0.00380162, No Iterations 2
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0818354, No Iterations 9
time step continuity errors : sum local = 0.000200831, global = 1.65043e-17, cumulative = 1.65043e-17
smoothSolver: Solving for nuTilda, Initial residual = 1, Final residual = 0.0191146, No Iterations 2
#0 Foam::error:rintStack(Foam::Ostream&) in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::incompressible::RASModels::nutSpalartAllmara sWallFunctionFvPatchScalarField::calcUTau(Foam::Fi eld<double> const&) const in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#4 Foam::incompressible::RASModels::nutSpalartAllmara sWallFunctionFvPatchScalarField::calcNut() const in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#5 Foam::incompressible::RASModels::nutWallFunctionFv PatchScalarField::updateCoeffs() in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6 Foam::fvPatchField<double>::evaluate(Foam::Pstream ::commsTypes) in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/simpleFoam"
#7 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/simpleFoam"
#8 Foam::incompressible::RASModels::SpalartAllmaras:: correct() in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#9
in "/home/vesselin/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/simpleFoam"
#10 __libc_start_main in "/lib/libc.so.6"
#11
at /usr/src/packages/BUILD/glibc-2.9/csu/../sysdeps/x86_64/elf/start.S:116
Segmentation fault

Please, HELP!

V.

ps - I have gcc 4.4.5 on my system, don't know if it makes some difference...

[vkrastev]

Well, I have rebuilt once again the 1.7.1 source packages, but this time changing the optimization level of the compiler from -O3 to -O1 (simply by editing the c++Opt and c++Prof files in the /wmake/rules/linux64Gcc/ folder). After that I have compiled also my own source code and now all seems to work perfectly...Does it mean that the 4.4.5 release of gcc has some optimization-level issues? I've read here http://www.cfd-online.com/Forums/ope...gcc-4-5-x.html that in the recent past there were some troubles between gcc 4.5.x and OpenFOAM 1.7.0/1.7.1: could I have found some analogous problem with gcc 4.4.5 and OF 1.7.1 compiled on 64 bit machines? Or maybe the problem is somewhere else (processor architecture, or the specific combination of Ubuntu 10.10 and gcc 4.4.5)? I think these issues are quite interesting to start a debate, so any contribution would be really appreciated

Thank you in advance

V.

[l_r_mcglashan]

What happens if you compile OpenFOAM with -O3 and your own code with -O1 or -O2? Have a look at the difference between the options here: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

[vkrastev]

Originally Posted by l_r_mcglashan

What happens if you compile OpenFOAM with -O3 and your own code with -O1 or -O2? Have a look at the difference between the options here: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

If I build the whole code with -O3 and rebuild only the /incompressible/RAS folder with -O1 the result is the same as building all with -O3 (have in mind that my pieces of code are simply adapted version of pre-existing source files, so with the same type of basic structure and dependency lists), i. e. the same segmentation fault error appears. Actually I've made no extensive tests (e. g. switching from -O1 to -O2 or from -O2 to -O3 and deactivating the single additional flags) on what exactly should be the optimization flag (or flags) which causes such an error. In an older post I found that for gcc 4.5.0 there was a problem connected with the -fstrict-aliasing flag, and the problem disappeard when -fno-strict-aliasing was added along with -O3. However in my case this seems not sufficient (I've tried the compilation of the whole code with -O3 -fno-strict-aliasing and the same for the additional sources, but again the segmentation fault error appears). At the moment I'm quite busy with other issues, but I hope I could make some additional tests as soon as possible. Thanks for your reply (and for the useful link)

V.

[wyldckat]

Greetings to both!

Vesselin, I've reported/accompanied the last two transitions in OpenFOAM 1.6.x to use gcc 4.4.x, as well as OpenFOAM 1.7.x to use gcc 4.5.x, as you have seen and can see here:

• http://www.cfd-online.com/Forums/ope...tml#post270684
• http://www.cfd-online.com/Forums/ope...oam-1-6-a.html

So, to the best of my knowledge, let me try to address one issue at a time:

1. The original OpenFOAM 1.6 should not even build with gcc 4.4.5. You will need the fixes made by Mattijs in 1.6.x around November 17, 2009, in case you don't want to step up directly from 1.6 to 1.6.x.
2. The changes you've added are they made directly to the core code of OpenFOAM or are they independent of the original code? Because if you added code directly to the original, then you'll need to analyse very closely the fixes made by Mattijs.
3. On your changes, have you run this command:

   wclean all

   This will clean up all of the objects used in the previous builds. Otherwise, you risk having old objects built with gcc 4.3.3 to contaminate the new builds with gcc 4.4.5! This has been know to complicate things.
4. If you use different gcc versions to build OpenFOAM, you might end up with slightly different results in your cases. If you intend to reproduce the same results, using the same compiler version you used in your previous machine would be advisable!
5. Although this is a long shot, have you tested the memory of your machine? It's unlikely, but my experiences in the last 12 months lead me to be more suspicious of machines with less than 12 months.

Either way, my biggest suspicion is that you didn't run "wclean all" on your code and that those libraries "contaminated the area". I suggest that:

• If the changes are independent of the original code, then you should build one library at a time to try and isolate the issue.
• If the changes are made directly to the original code, then the changes should be made gradually and not all at once.

Finally, when there are too many changes made to the code, it's better to play safe and run:

wclean all
wmake all

on the folder where you made the changes! This way you force a clean build.

Best regards,
Bruno

[vkrastev]

Originally Posted by wyldckat

Greetings to both!

Vesselin, I've reported/accompanied the last two transitions in OpenFOAM 1.6.x to use gcc 4.4.x, as well as OpenFOAM 1.7.x to use gcc 4.5.x, as you have seen and can see here:

• http://www.cfd-online.com/Forums/ope...tml#post270684
• http://www.cfd-online.com/Forums/ope...oam-1-6-a.html

So, to the best of my knowledge, let me try to address one issue at a time:

1. The original OpenFOAM 1.6 should not even build with gcc 4.4.5. You will need the fixes made by Mattijs in 1.6.x around November 17, 2009, in case you don't want to step up directly from 1.6 to 1.6.x.
2. The changes you've added are they made directly to the core code of OpenFOAM or are they independent of the original code? Because if you added code directly to the original, then you'll need to analyse very closely the fixes made by Mattijs.
3. On your changes, have you run this command:

   wclean all

   This will clean up all of the objects used in the previous builds. Otherwise, you risk having old objects built with gcc 4.3.3 to contaminate the new builds with gcc 4.4.5! This has been know to complicate things.
4. If you use different gcc versions to build OpenFOAM, you might end up with slightly different results in your cases. If you intend to reproduce the same results, using the same compiler version you used in your previous machine would be advisable!
5. Although this is a long shot, have you tested the memory of your machine? It's unlikely, but my experiences in the last 12 months lead me to be more suspicious of machines with less than 12 months.

Either way, my biggest suspicion is that you didn't run "wclean all" on your code and that those libraries "contaminated the area". I suggest that:

• If the changes are independent of the original code, then you should build one library at a time to try and isolate the issue.
• If the changes are made directly to the original code, then the changes should be made gradually and not all at once.

Finally, when there are too many changes made to the code, it's better to play safe and run:

wclean all
wmake all

on the folder where you made the changes! This way you force a clean build.

Best regards,
Bruno

Hi Bruno, and many thanks for your detailed answer! Rereading your observations and suggestions, I think that:

1) When I built OF-1.6 after OF-1.7.1 this should have been done with gcc 4.3.3 instead of 4.4.5, as the 4.3.3 version is automatically provided with the 1.6 release and set as default once the environmental variables are pointed to the OF-1.6/etc/bashrc file. Thus, probably between the two consequent compilation there was this kind of "contamination" you are talking about (and this could be an explanation of the identical segmentation fault error displayed for both the OF versions).

2) The first time I compiled OF-1.7.1, the contamination could not have been possible...In addition, I'm sure I have done it all with gcc 4.4.5, and before building my modifications (which are not brand new libraries, but new source and header files based on the same dependency lists of the original ones) I've also cleaned the dependencies concerning the folder of interest (turbulence models/incompressible/RAS/). However, as the cleaning was done only with wclean (and not wclean all), could this have been (in your opinion) a source of troubles? In any case, I'll try to make some additional tests following your advices as soon as possible...

Thanks once again

V.

[wyldckat]

Hi Vesselin,

Originally Posted by vkrastev

However, as the cleaning was done only with wclean (and not wclean all), could this have been (in your opinion) a source of troubles?

From my experience (and I could be wrong on some details), when we only run "wmake" on a library folder, it tries to build an executable, instead of a library; to build a library, we have to be explicit with "wmake libso", although I believe that "wmake all" will tell "wmake" to figure out what should be done, namely if to build an executable or a library.
So, since "wclean" is almost the opposite of "wmake", it should have similar functionality, namely the clean up process will depend on whether it's an executable or a library.

To make matters even more confusing, "wmake all" will call the local script "Allwmake" when it exists, since somethings are to be executed in different orders than usual. As for "wclean", it will call "Allclean". But usually only "Allwmake" exists in folders, while "Allclean" only exists sometimes.

As for contamination, there are at least two possibilities:

• It usually occurs at an object level, namely ".C" files that have already been compiled with one compiler, thus creating the respective ".o" files, will then be used by another compiler. This sometimes works well, but when differences are too big between compilers, it won't work.
• Another possibility that sometimes occurs, which usually happens when updating the git version of OpenFOAM, is that the building process doesn't detect new files that are needed for rebuilding the libraries and applications.

Best regards,
Bruno

[vkrastev]

Hi Bruno, I've just finishing rebuilding the code (1.7.1 release) and my modifications with the -O3 optimization level and now (finally) all works properly without strange error messages! I think that the issue was in the cleaning up of the dependency lists, because this time I've completed the cleaning/rebuilding procedure by using the combination wclean all/Allwmake. Thanks a lot for your comments and suggestions!

V.

[wyldckat]

Hi Vesselin,

I'm glad I was able to help and even happier that the issue you were having wasn't something related to a damaged CPU or RAM!

Best regards,
Bruno

[adhiraj]

Hi all,
I seem to have a similar problem, and it seems that the problem the OP had is related-- segfaulting in OpenFOAM. I can confirm this kind of behavior on both 64 bit and 32 bit Ubuntu 10.10. And if that is any help. the debug version runs perfectly fine.

[wyldckat]

Greetings Adhiraj,

Originally Posted by adhiraj

Hi all,
I seem to have a similar problem, and it seems that the problem the OP had is related-- segfaulting in OpenFOAM. I can confirm this kind of behavior on both 64 bit and 32 bit Ubuntu 10.10. And if that is any help. the debug version runs perfectly fine.

Soooo... have you followed the instructions on this thread to solve the problem?

Best regards,
Bruno

[adhiraj]

Hi all,
sorry for the late reply; I've been simply swamped. I ran the wcleanall and recompiled everything, that seemed to help.

[wyldckat]

Hi Adhiraj,

OK, I'm glad it worked out well. I was worried that the instructions weren't clear enough, since I have a tendency to write too much

Best regards,
Bruno