[hjasak]

Instructions:

- report on your system:

uname -a

echo $SHELL

- report on your environment variables:

env | grep WM_

env | grep FOAM_


- follow OpenFOAM-1.4.1-dev/buildInstructions.txt stage 1 to 4 and report success or failure after each step

To answer one of your questions:

I had a huge number of errors during compilation of "SSI modules" within the lam directories. Is there an explanation why lam doesn't work on 32bit linux (Ubuntu7.10)? And why do the Makefiles try to compile both lam-7.1.2 and lam 7.14?

lam is a self-contained library not developed by or for OpenFOAM developers. It builds using configure; make; make install tricks and it never gave me any trouble. It definitely works on 32-bit linux. Look for the first error message and post it here.

Please keep me informed, I want this one sorted out and don't mind investing my time into it.

Hrv

[bernd]

>lam is a self-contained library not developed by or for OpenFOAM developers.

Thank you for this information. If lam is the unmodified sources of the lam project, I'd suggest not to include it in the OpenFOAM sources. Same for zlib, mico, and openmpi, maybe? My impression is that these require more than half of the compilation time, and they usually are available as precompiled packages. What is the motivation to duplicate these packages in OpenFOAM?

Here comes the information, which you asked. The output from step 1-4 follows when I replace the broken harddisc next week so that I have space for the build process again.

$ uname -a
Linux linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

$ echo $SHELL
/bin/bash

$ env | grep WM_
WM_LINK_LANGUAGE=c++
WM_ARCH=linux
WM_JAVAC_OPTION=Opt
WM_PROJECT_VERSION=1.4.1-dev
WM_COMPILER_LIB_ARCH=
WM_PROJECT_INST_DIR=/home/bernd/OpenFOAM
WM_PROJECT_DIR=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev
WM_COMPILER_ARCH=
WM_NCOMPPROCS=1
WM_DECOMP_LIBS=-lfaceDecompFiniteElement -lfaceDecompositionMotionSolver
WM_PROJECT=OpenFOAM
WM_COMPILER=Gcc
WM_MPLIB=OPENMPI
WM_PROJECT0=OpenFOAM
WM_COMPILER_DIR=/home/bernd/OpenFOAM/linux/gcc-4.2.1
WM_DECOMP_INC=-DFACE_DECOMP
WM_COMPILE_OPTION=Opt
WM_DIR=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/wmake
WM_PROJECT_USER_DIR=/home/bernd/OpenFOAM/bernd-1.4.1-dev
WM_OPTIONS=linuxGccDPOpt
WM_PROJECT_LANGUAGE=c++
WM_PRECISION_OPTION=DP

$ env | grep FOAM_
FOAM_SOLVERS=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/applications/solvers
FOAM_APPBIN=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/applications/linuxGccDPOpt
FOAM_TUTORIALS=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/tutorials
FOAM_JOB_DIR=/home/bernd/OpenFOAM/jobControl
FOAM_LIB=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/lib
FOAM_MPI_LIBBIN=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/lib/linuxGccDPOpt/openmp i-1.2.3
FOAM_APP=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/applications
FOAM_SRC=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/src
FOAM_SIGFPE=
FOAM_UTILITIES=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/applications/utilities
FOAM_USER_LIBBIN=/home/bernd/OpenFOAM/bernd-1.4.1-dev/lib/linuxGccDPOpt
FOAM_LIBBIN=/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/lib/linuxGccDPOpt
FOAM_DOT_DIR=.OpenFOAM-1.4.1-dev
FOAM_RUN=/home/bernd/OpenFOAM/bernd-1.4.1-dev/run
FOAM_USER_APPBIN=/home/bernd/OpenFOAM/bernd-1.4.1-dev/applications/linuxGccDPOpt

[young]

Hello ,a nice day or maybe good evening for you;(you know ,we are in different time zones)

I am trying get OF-1.4.1-dev onto my computer whose OS is redhat4-EL and is 64-bits and has 4 processers;
I download the sources from http://powerlab.fsb.hr/ped/kturbo/OpenFOAM/release/ ;
I want to know whether there is necessary to do gdb like gcc?
are dx and cmake and gcc fit for 64-bits computer?

oceans of thanks!

Young

[alberto]

@ Bernd: Having those packages included means reducing the number of troubles you have when you compile and to provide a self contained package.

If you remove them and rely on the version provided with your distribution you increase the risk of problems and version conflicts (where are these libraries on a specific distribution? are they installed? is the version compatible?). I think their removal would make things more complex and not easier for final users.

Moreover their presence is necessary to developers to create binaries.

Regards,
Alberto

[hjasak]

Hello Bernd,

A few more words. I have done this compilation so often over the last 15 years that I can now compile OpenFOAM on a toaster if need be. We have had a little discussion here and the conclusion is that we cannot let new people fail in trying to install OpenFOAM: that would be bad for the future. So, you are in safe hands: between you and me, we can definitely get this sorted out.

Regarding the configure/make/make install build, there is a little problem that I keep forgetting about. Basically, OpenFOAM is set up as a development environment, where a user needs not only run the executables (like in a dumb CFD code), but also write his/her own, compile top-level code and libraries etc. You will appreciate that the latter requires lots of search paths, environment variables etc.

In fact, I see no difference between "core" OpenFOAM installation and user-written add-ons, which brings back the issue of "how to build it".

In any case, I hope this gives you a bit of a background picture. Please let me know when you get the hard disk and we'll enjoy the ride.

Best,

Hrv

[young]

Hello Pro. Hrv

I get some problem with lam-7.1.4 and Pstream 's make.
for Pstream :
./Allwmake
+ wmake libso dummy
`/home/ylc/OpenFOAM/OpenFOAM-1.4.1-dev/lib/linux64GccDPOpt/dummy/libPstream.so' is up to date.
+ '[' LAM = LAM -o LAM = OPENMPI -o LAM = MPI -o LAM = MPICH -o LAM = MPICH-GM -o LAM = MPIGAMMA ']'
+ export WM_OPTIONS=linux64GccDPOptLAM
+ WM_OPTIONS=linux64GccDPOptLAM
+ wmake libso mpi
/usr/bin/ld: /usr/lib/../lib64/libmpi.a(abort.o): relocation R_X86_64_32 against `lam_mpi_comm_world' can not be used when making a shared object; recompile with -fPIC
/usr/lib/../lib64/libmpi.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [/home/ylc/OpenFOAM/OpenFOAM-1.4.1-dev/lib/linux64GccDPOpt/lam-7.1.4/libPstream. so] Error 1

for lam-7.1.4 ,there is also a bad value about /usr/lib/../lib64/libmpi.a.
But in /usr/lib64, there does exist an archive libmpi.a.

When I Allmake the applications ,there are too many errors about ~Pstream something~

What should I do next ?

Thank you

Young

[kati]

> Posted by Jaswinder Pal Singh on Monday, April 28, 2008 - 04:44 pm:
>
>
> OpenFOAM documentation is possible but its absence should not be
> blamed upon them. I was myself so frustrated in the begining that I
> called up the people at ICON UK Ltd and thought of buying the support.
> Why ICON because my numerous emails to the openfoam went unanswered.
> After all it does not costs a fortune. If I am not wrong the price is
> 6000 Euros for 50 hours spread over 1 year. What deterred me is the
> terms and conditions as it had to be a one time payment. I was
> mentally prepared to go for it if the money could be spread over
> monthly installments.
>
Hi Jaswinder,

As people may have realised I work for Icon. I'm sorry to hear that you were not happy with the Icon offer, and I forwarded your feedback to our sales staff. They replied that we are developing a new payment method, which would make possible to purchase support in say 10 hour packages. Very small payments are not feasible due to administration and start-up costs.

Icon is also offering an Introductory User Training on OpenFOAM (which includes printed lecture material and tutorials for each trainee, i.e. a kind of documentation) and we will be offering an Introductory Programming training in a few months, which will also include printed lecture material and tutorials. We've had both commercial and academic trainees on the Introductory user training.

Regards,
Kati

[alberto]

Kati, feel free to drop an email (address in my profile) when the introductory programming course is ready.

I think it's going to attract a nice number of people :-)

Thanks in advance,
Alberto

[bernd]

>- follow OpenFOAM-1.4.1-dev/buildInstructions.txt stage 1 to 4 and report success or failure after each step

ok, here we go...

>1) Download files
>Get all files from the sources directory on the >web site and put them into the linuxSrc directory

I downloaded the svn trunk successfully

>2) Unpack OpenFOAM and set up the dot-files
>cd ~/OpenFOAM
>tar xzf linuxSrc/OpenFOAM-1.4.1-dev_22_11_05.tgz
>cp -r OpenFOAM-1.4.1-dev/.OpenFOAM-1.4.1-dev ~

I have no such OpenFOAM-1.4.1-dev_22_11_05.tgz. This instruction doesn't make sense in the svn download. But I have ~/OpenFOAM/OpenFOAM-1.4.1-dev containing the correct directory structure and files from the svn trunk. Therefore: Success

>3) Build utilities
skipped to save time until I sorted out the errors. I assume the errors listed below don't depend on this different setup. Let me know if I'm wrong.

Instead I downloaded gcc-4.2.1.linux.tgz, j2sdk1.4.2_05.linux.tgz and paraview-2.4.4.linux.tgz and extracted these successfully into ~/OpenFOAM/linux

>4) build OpenFOAM
>foam
>(this should take you to the >~/OpenFOAM/OpenFOAM-1.4.1-dev directory)
>./Allwmake

I ran ./Allwmake &>make0.log and interrupted this build, when enough error messages accumulated to begin with. Here is the complete (up to interruption) log: make0.log.gz

Below are error messages extracted from make0.log. The problems seem to be missing tm.h, libgm and libvapi. What do I need to install to have these available?

bernd@linux:~/OpenFOAM/OpenFOAM-1.4.1-dev$ grep -n -E '(failed)|(error)' make0.log
226:checking System V Release 4 fd passing example... failed
426:configure: error: Cannot continue
428:configure: /bin/bash './configure' *failed* for share/ssi/boot/bproc
879:configure: error: *** Cannot find working tm.h.
881:configure: /bin/bash './configure' *failed* for share/ssi/boot/tm
926:configure: error: Cannot continue
928:configure: /bin/bash './configure' *failed* for share/ssi/coll/impi
1367:configure: error: cannot continue
1369:configure: /bin/bash './configure' *failed* for share/ssi/crlam/blcr
1568:configure: error: cannot continue
1570:configure: /bin/bash './configure' *failed* for share/ssi/crmpi/blcr
1916:configure: error: *** Cannot find working libgm.
1918:configure: /bin/bash './configure' *failed* for share/ssi/rpi/gm
1985:configure: error: *** Cannot find working libvapi.
1987:configure: /bin/bash './configure' *failed* for share/ssi/rpi/ib
2715:checking for dlerror... yes
2721:checking for error_t... yes
[... some more messages, no errors, only filenames containing 'error'...]

Once you help me to sort this out, I'll start a new compilation, which probably will include zlib related errors and (dependent) libtrisurface compilation failure.

Best,
Bernd

[philippose]

Hello Bernd,

Couple of observations.....

1. Did you "source" the .bashrc file from your home directory after modifying it to include the parts from OpenFOAM?

2. In the bleeding edge OpenFOAM-1.4.1-dev version, the default compiler used is gcc-4.2.2, so, if you try to use gcc-4.2.1 directly without making the required changes to the OpenFOAM source, OpenFOAM will automatically fallback to your default system compiler.

This can be checked if you open a new console, and type in "gcc --version".... and see if the active compiler is the one you expect it to be.

On the other hand, looking at the environment variables you posted earlier, it looks like the version of OpenFOAM-1.4.1-dev you are trying to compile is still using GCC-4.2.1, so this should be ok

3. Suggestion: Delete the complete LAM-7.1.4 directory from the OpenFOAM sources, and put in a fresh copy of LAM-7.1.4 downloaded from the "thirdparty" directory of the OpenFOAM SVN repository.

Hope this helps!

Philippose

[olesen]

Hi Bernd,

I've been lurking on this thread for a bit and really can't figure out what you are trying to do. Are you trying to get LAM working or do you just want to get OpenFOAM working?

I ask since the posted make log is entirely LAM related. Do you really need parallelization at all, and LAM/MPI specifically? I've always tried to avoid LAM whenever possible whether it be OpenFOAM or other calculation software.

For starters, why not switch to *NO* parallel library, which corresponds to the OpenFOAM 'dummy' Pstream? Going back afterwards and recompiling for other (non-dummy) parallel libraries is relatively trivial - only the libPstream is directly affected and everything else will already have been built.

Presumably using this approach you can get OpenFOAM running sooner. NOTE: even if you have the Paraview/VTK sources installed, it could be that you run into problems compiling this application.

BTW: I've recompiled OpenFOAM from source a few times (various SuSE versions) and I can confirm that most of my compile issues arise from the 3rd party stuff (eg, CORBA, VTK, ...) rather than OpenFOAM itself.

When compiling OpenFOAM itself, the flex warnings are unavoidable.

IMO the single best contribution to improving the OpenFOAM install would be to jettison FoamX and patchTool in favour of a Qt-based solution. I assume that once you get OpenFOAM up and running, it wouldn't take much for a computer science guy like you (or your fellow computer science colleagues) to whip together replacements for these two programs. This would indeed be a useful contribution!

/mark

[bernd]

>1. Did you "source" the .bashrc file from your home directory after modifying it to include the parts from OpenFOAM?

yes. And changed the gcc-4.2.2 setting to gcc-4.2.1 therein.

>2. In the bleeding edge OpenFOAM-1.4.1-dev version, the default compiler used is gcc-4.2.2, so, if you try to use gcc-4.2.1 directly without making the required changes to the OpenFOAM source, OpenFOAM will automatically fallback to your default system compiler.

>This can be checked if you open a new console, and type in "gcc --version".... and see if the active compiler is the one you expect it to be.

>On the other hand, looking at the environment variables you posted earlier, it looks like the version of OpenFOAM-1.4.1-dev you are trying to compile is still using GCC-4.2.1, so this should be ok

Exactly. Here is part of the foamInstallationTest output:

Software Version Location
-------------------------------------------------------------------------------
gcc 4.2.1 /home/bernd/OpenFOAM/linux/gcc-4.2.1/bin/gcc
java 1.6.0 /usr/lib/jvm/java-6-sun/bin/java

But please concentrate on the actual compiler errors unless they are likely to be caused by an incompatible gcc version.

>3. Suggestion: Delete the complete LAM-7.1.4 directory from the OpenFOAM sources, and put in a fresh copy of LAM-7.1.4 downloaded from the "thirdparty" directory of the OpenFOAM SVN repository.

What the hell is meant by "the OpenFOAM sources"? Where do I find them if not at http://openfoam-extend.svn.sourceforge.net?
The buildinstructions.txt also starts with
"Get all files from the sources directory on the web site and put them into the linuxSrc directory". Which website??? If I downloaded this buildinstructions.txt from http://openfoam-extend.svn.sourceforge.net where there is no directory named 'sources', I assume that the downloaded trunk directory contains 'the sources'. But it doesn't contain the .tgz file you're supposed to find there.

Is it a strict secret, or would anybody mind telling me what 'the sources directory on the web site' is and update this information in the buildinstructions.txt?

And why would I need to replace lam-7.1.4 with the thirdparty source given that Hrv said above that lam-7.1.4 has been added unmodified?

----------------------------------------------

>I've been lurking on this thread for a bit and really can't figure out what you are trying to do. Are you trying to get LAM working or do you just want to get OpenFOAM working?

1) Above all I want to understand the OpenFOAM build process. So that I am able to solve compilation problems myself in future updates.
2) I want to point out problems in the build instructions, so that these can be improved to help other newbies.
3) Yes, I want to have a functioning OpenFOAM installation without workarounds. And I'll need a parallel installation in the near future.

>I ask since the posted make log is entirely LAM related.

Yes. Because Hrv asked for the first error messages to appear. Here they are.

As Philipose pointed out above, changing to openmpi instead of lam in the bashrc avoids these errors, which I can confirm.
Then openmpi should be enabled by default and lam should be labeled 'for expert use only' or the problems with lam should be solved, for which I want to provide input with my error reports.

>Do you really need parallelization at all, and LAM/MPI specifically? I've always tried to avoid LAM whenever possible whether it be OpenFOAM or other calculation software.

For what reason?

Thanks for the replies.
And again, please don't tell me what I can replace in the standard OpenFOAM installation in order to work around the problems, but help to sort out the problems. I have given very concrete error messages that should be sufficient to suggest fixes.

Bernd

[olesen]

Dear Bernd,

If I take time to write and potentially help, I do not wish to be exposed to belligerence.

[philippose]

Hello Bernd,

Could you tell me exactly which "version" of OpenFOAM-1.4.1-dev you are using / downloaded?

I was looking up in the OpenFOAM SVN Repository, and I found the following "versions":

1. /tags/core/OpenFOAM-1.4.1_dev_07_09_04
2. /tags/core/OpenFOAM-1.4.1_dev_07_11_14
3. /trunk/Core/OpenFOAM-1.4.1-dev

That way it would be easier to follow up on the issues you have been facing

Philippose

[bernd]

>Could you tell me exactly which "version" of OpenFOAM-1.4.1-dev you are using / downloaded?

>3. /trunk/Core/OpenFOAM-1.4.1-dev

It is this one. This is what I meant when talking about the 'trunk from svn'. Checked out on April 30.

Bernd

[philippose]

Hi again,

Ok... I am currently downloading the /trunk/Core/OpenFOAM-1.4.1-dev version of OpenFOAM, starting completely afresh.

Shall try to compile it overnight with LAM-7.1.4, and see how things work out.

I will be using:

1. System: A Fedora 8 system on which OpenFOAM has been compiled multiple times (with OpenMPI instead of LAM though) (unfortunately I am on holiday, and have only my Laptop with me).

2. Compiler: GCC-4.1.2

3. Java: IcedTea-1.7.0 (comes by default with Fedora 8, and works without a hitch though it throws up a million warnings)

4. Postprocessing: ParaView 3.3.0 (precompiled) - I will not make any changes to the make scripts in OpenFOAM,which implies, that a lot of errors will be thrown out when the libraries associated with paraFoam are tried to be built.

5. Parallel processing: LAM-7.1.4

6. Corba: MICO-2.3.12

7. Compression: zlib-1.2.3

Everything else would be as is. After downloading from SVN, if any of the last three packages are missing, I will download them from the "thirdparty" section of the SVN repository, though I think externals are automatically accounted for.

Have a nice day!

Philippose

[bernd]

>Ok... I am currently downloading the /trunk/Core/OpenFOAM-1.4.1-dev version of OpenFOAM, starting completely afresh.

>Shall try to compile it overnight with LAM-7.1.4, and see how things work out.

Thank you! By the way, the LAM error messages were logged during the first 15-30 minutes (of a total 6h for the complete build). So you don't need to compile for the whole night to compare the errors messages.

Besides, all I need is a suggestion where I get appropriate tm.h, libgm and libvapi which were logged as "Cannot find working tm.h,...".

Actually the same errors have been reported in this post which hasn't been answered since:
http://www.cfd-online.com/OpenFOAM_D...tml?1177666907

[mbeaudoin]

Hello Bernd,

Here it goes:

> Besides, all I need is a suggestion where I get appropriate tm.h, libgm and libvapi which were logged as "Cannot find working tm.h,...".

LAM is a sophisticated implementation of MPI. It support a lots of modules, some of them specific to some harware interconnect, etc.

The "error" messages you are seeing basically comes from the LAM configure script that tries to interrogate your system in order to select which runtime modules it can compile, and which it cannot, based on the presence or absence of some libraries or include files on your development system.

The fact that you have those error messages does not mean that the whole LAM package cannot compile, it just means that your system does not have the basic infrastructure to compile some specific modules.

For instance:

- libgm: This is for runnning LAM over a Myrinet interconnect. Do you have Myrinet on your machine? If so, the LAM configure scripts cannot find it. If not, no big deal, LAM will just not compile the module for Myrinet.

- libvapi : This is for running LAM over a Infiniband interconnect. Do you have Infiniband on your machine?

You see the pattern?

Just take a look at the numerous modules that LAM tried to configure; for all the modules that fails, you get a message similar to this:

"configure: --- SSI module boot:bproc compile: no"

For all the modules that LAM properly configured, you will get a message similar to this instead:

"configure: +++ SSI module boot:globus compile: yes"

You will also observe that further down your long log file, the properly configured modules do indeed get compiled. Those that failed the configuration did not.

If I were you, I would be much more concerned by the following errors messsages:


/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/src/lam-7.1.4/share/ssi/boot/globus/conf ig/missing: line 52: aclocal-1.9: command not found

WARNING: `aclocal-1.9' is missing on your system. You should only need it if
you modified `acinclude.m4' or `configure.ac'. You might want
to install the `Automake' and `Perl' packages. Grab them from
any GNU archive site.

/home/bernd/OpenFOAM/OpenFOAM-1.4.1-dev/src/lam-7.1.4/share/ssi/boot/globus/conf ig/missing: line 52: automake-1.9: command not found

WARNING: `automake-1.9' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.


You are either missing a very important development package called automake, or your actual version is too old.

From your log file, that would be the first problem I would try to solve.

Maybe you have some other problems on your development machine, but let's first try to correct this one, and see how far you can go.

Martin

[bernd]

Martin,
thank you so much for your excellent explanations! This is the kind of help I was hoping for.

Tomorrow I'll try to find the success messages of the lam modules in the logfile, so that I am sure I understand what you mean.

Then I'll continue the compilation until the next severe (or what I think is severe) error message and report again.

As for the automake warnings I was mistaken first. I thought I had a _newer_ version than required and therefore ignored the warnings, but actually automake is really not installed.

Best,
Bernd

[olesen]

I thought that others might find it useful to see that build errors per se are not always entirely avoidable. OpenMPI-1.2.6 fails to build on my version of SuSE 10.3 with these errors.

../../libtool: line 459: CDPATH: command not found
../../libtool: line 1262: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.1a, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.1a
libtool: and run autoconf again