[philippose]

Hello again,

Hey... that was a great catch Martin :-)! Nice nice... :-)!

Soo... as I had mentioned last evening, I put my laptop through the exercises overnight, and here are the results:

1. Based on Martin's explanation, I too looked deeper into the LAM related errors my system put out, and here is a small extract of what I found:

418:configure: error: Cannot continue
858:configure: error: *** Cannot find working tm.h.
904:configure: error: Cannot continue
1332:configure: error: cannot continue
1528:configure: error: cannot continue
1867:configure: error: *** Cannot find working libgm.
1935:configure: error: *** Cannot find working libvapi.

That looks exactly like what you were experiencing... So, I went further, and made a list of all the LAM Modules scheduled to be compiled, and those skipped... here they are:

configure: +++ SSI module boot:globus compile: yes
configure: +++ SSI module boot:globus mode: static
configure: +++ SSI module boot:rsh compile: yes
configure: +++ SSI module boot:rsh mode: static
configure: +++ SSI module boot:slurm compile: yes
configure: +++ SSI module boot:slurm mode: static
configure: +++ SSI module coll:lam_basic compile: yes
configure: +++ SSI module coll:lam_basic mode: static
configure: +++ SSI module coll:shmem compile: yes
configure: +++ SSI module coll:shmem mode: static
configure: +++ SSI module coll:smp compile: yes
configure: +++ SSI module coll:smp mode: static
configure: +++ SSI module crlam:self compile: yes
configure: +++ SSI module crlam:self mode: static
configure: +++ SSI module crmpi:self compile: yes
configure: +++ SSI module crmpi:self mode: static
configure: +++ SSI module rpi:crtcp compile: yes
configure: +++ SSI module rpi:crtcp mode: static
configure: +++ SSI module rpi:lamd compile: yes
configure: +++ SSI module rpi:lamd mode: static
configure: +++ SSI module rpi:sysv compile: yes
configure: +++ SSI module rpi:sysv mode: static
configure: +++ SSI module rpi:tcp compile: yes
configure: +++ SSI module rpi:tcp mode: static
configure: +++ SSI module rpi:usysv compile: yes
configure: +++ SSI module rpi:usysv mode: static

configure: --- SSI module boot:bproc compile: no
configure: --- SSI module boot:tm compile: no
configure: --- SSI module coll:impi compile: no
configure: --- SSI module crlam:blcr compile: no
configure: --- SSI module crmpi:blcr compile: no
configure: --- SSI module rpi:gm compile: no
configure: --- SSI module rpi:ib compile: no

I looked into your log, and the list of "to-be-compiled" and "skipped" modules are exactly the same as the ones I got.

Other than those initial errors, I got no more LAM related errors, and the most important thing is, to ensure that you have a folder call "lam-7.1.4" in your OpenFOAM-1.4.1-dev\lib\linuxGccDPOpt" folder, with the file "libPstream.so". If this exists, I would be inclined to say, that the compile of LAM (as far as OpenFOAM is concerned) was successful.

2. As I had mentioned before, I had to copy the "Make" folder from zlib-1.2.1 to zlib-1.2.3, though, I think the better way might be to run the configure script present in the zlib-1.2.3 folder before doing a make.

3. As usual, I had to do two passes in order for everything to compile without any problems.

The reasons for the need for two passes were multiple, some of which I can't explain as to why...

a. mico-cpp, which is generated during the compile process of mico-2.3.12, is not detected at a later stage in the compile when it is required, and that throws up 2 errors during the FoamXServer compile:

make[3]: Entering directory `/home/philippose/OpenFOAM/OpenFOAM-1.4.1-dev/applications/utilities/mesh/manipulation/patchTool/Idl'
/home/philippose/OpenFOAM/OpenFOAM-1.4.1-dev/src/mico-2.3.12/platforms/linuxGcc41DPOpt/bin/idl --poa --c++-suffix=C --hh-suffix=H --any --typecode PatchTool.idl
sh: mico-cpp: command not found
error: cannot execute mico-cpp
make[3]: *** [../C++/FoamXServer/PatchTool.H] Error 1
make[3]: Target `all' not remade because of errors.

sh: mico-cpp: command not found
error: cannot execute mico-cpp
make[2]: *** [../C++/FoamXServer/FoamX.H] Error 1
make[2]: Target `all' not remade because of errors.
make[2]: Leaving directory `/home/philippose/OpenFOAM/OpenFOAM-1.4.1-dev/applications/utilities/preProcessing/FoamX/Idl'

The solution to this is, to close the console, and open a new one before the second compile pass.

b. During compile of the foamToVTK applications, the include file: interpolatePointToCell.H was not found in the first pass.


The rest of the errors I got were related to dxFoam, the OpenDX reader for foam, and vtkFoam, and PVFoamReader, the ParaView 2.x.x reader for OpenFOAM, both of which I do not use.

So, to make it clear, the only OpenFOAM related issue, is the compile of foamToVTK... all the other errors are related to third-party software which OpenFOAM uses.


For the sake of completion, here are the log files for the two compile passes:

make_pass1_errorlist.log.tgz

make_pass2_errorlist.log.tgz

And as an end-note.... here is the foamInstallationTest after the second pass:

foamInstallationTest.log

So basically, the compile was successful, and the resulting installation is functional (including FoamX actually :-)!)


Now comes the question.... how detailed should a "guide" for compiling OpenFOAM be, when the possibilities for errors are very user and system dependent?? Or..does it make sense at all??

Such as the missing automake in your case, which would be expected to be present in any Linux system used for software development / compiling....

And the various system related issues with the third-party software, such as LAM? In case you had Infiniband configured on your system, you would have seen fewer errors for example.

So... it would be great if you held your cool a little longer next time, before lashing out at everyone else unnecessarily.

Hope this solves your issues...

Philippose

[lakeat]

Dear all,

Peace to you all.

To Bernd,
I am sure you are not just want to learn installation!
Just be patient, there's a longgggg way to go if you want to enter CFD world.
Installation is much much easier than the problems you will surely meet in the future.

Not to say OpenFOAM, if you are using Commercial CFD software, do you think it will be an easy task?
Yes, commercial software is easier to install, but that don't mean they are easy to use! Solid backgrounds in both fluid mechanics and numerical analysis are absolutely necessary in using CFD. Just as what Ferziger said in his masterpiece,

-It is our belief that, to work in CFD, one needs a solid background in both
-fluid mechanics and numerical analysis; significant errors have been made by
-people lacking knowledge in one or the other.

Again I think you are not just want to learn installation from what you mentioned about parallel. So, just be patient. You will do well.

To Alberto Passalacqua and to Jaswinder Pal Singh

>OpenFOAM appears attractive due to the simple syntax of the transport equations and the possibility to use unstructured grids, but it immediately becomes impractical when a new user tries to implement new boundary conditions, new models and so on.
>very attractive at the startup phase but becomes a nightmare when you really want to do something productive.
>The developers should understand that their code is being used mostly by Master's and Phd students. No student can afford that kind of support. Also no masters student is going to need that level of support. The developers know that more the number of successful Master's and Phd works bigger is the user base. But how can the financial aspect be brought into picture because there is no free lunch.

I fully agree with what Jaswinder said, for I myself am a PhD Student in wind engineering, and I found the learning curve is very very steep!
My experiences are: (Note that I was completely newbie one year ago to linux)
1. Certain knowledge about *nix is indispensable.
2. Certain knowledge about shell scrpting.
3. Deep knowledge about C++, esp. STL, for OpenFOAM is a library in essence.

And I believe many Foamers are using parallel computing, and for me hard time arises when:
4. I have to face a different arch (eg. sgi-IRIX) and very little support can I get.
5. (Linux platform is easy to use indeed), but parallel and other thirdparty implements are harder to make them work.

More thoughts to newbies if they try to use it according to each of their area,
6. If parallel function would not be used at all, just delete openmpi, lam, mpich, etc. directories in ./src and switch thw MPI_LIB to empty.
7. In ./src/Allwmake, comment out the unused libso, for me libs like thermo* compressible*, and delete them in ./src.
8. Turn off the unused turbulenceModes or LESmodles or schemes(in ./src/finiteVolume/Make/files)

This will shorten the OpenFOAM, and make it a little faster to compile.


Best Regards,
& Special thanks to folks like Henry, Hrv...
Have a nice day.

Daniel

[bernd]

Hello,
thanks to your help I have a working development installation now, and can start with productive simulations.

I agree that I have done some stupid mistakes, but I absolutely disagree with those answers implying that every newbie can easily succeed with the installation simply because OpenFOAM has been built so frequently by a few users. This discussion has shown that there are a few problems, which I couldn't have solved in twice the amount of time if not some of you experienced guys had helped.
Will someone extract the information from this thread and update the repository with updated instructions and scripts? If not, where do I have to send suggestions for a patch?

>So, to make it clear, the only OpenFOAM related issue, is the compile of foamToVTK... all the other errors are related to third-party software which OpenFOAM uses.

Correct. When saying that I had problems installing OpenFOAM, I meant the whole thing as it is bundled in openfoam-extend, and as it is compiled with the default scripts. Besides, a single true OpenFOAM compilation error which has been reported more than half a year ago should be reason enough to at least try a fix.

I find the integration of the thirdparty software into the OpenFOAM download very confusing, because I had the impression that these packages had been modified for use with OpenFOAM, and therefore I didn't try to repair their compilation independently from the rest. My mistake. But still
I prefer the standard (not OpenFOAM) approach, that the build script should check whether the required software (lam or openmpi, zlib, ...) is installed in the correct version and otherwise tell the user what is missing. This saves lots of downloads and compilation time and questions from stupid newbies who think the thirdparty software installation problems are related to OpenFOAM.

>Now comes the question.... how detailed should a "guide" for compiling OpenFOAM be, when the possibilities for errors are very user and system dependent?? Or..does it make sense at all??

Don't you agree that things like the missing Make directory in zlib-1.2.3 should be corrected or at least mentioned in a guide? And the valuable remark, that the Allwmake script has to be run twice? If your opinion is that this should be hidden from new OpenFOAM users, we are talking at cross-purposes.

Again, sorry to those who felt insulted about the very explicit expression of my annoyance with the build process. Nevertheless, seeing how many halfhearted help requests remain unanswered in this forum, I can't say that I regret my style too much. I hope that some more people will take requests more serious and quickly point to the wiki if sufficient or improve the wiki when necessary, so that the OpenFOAM user base experiences the well deserved growth.

Bernd

[mbeaudoin]

Hello,

Just a few comments:

About the openfoam-extend repository and Subversion repositories in general:

If you take a look at this document: http://openfoam-extend.wiki.sourcefo...ion_Guidelines, in the section "Use Cases", you will find the following advices:

* "User likes to live dangerously and wants the bleeding edge of OpenFOAM-dev"
<blockquote>o Check out /trunk/OpenFOAM-dev and compile it. Update it every time you feel lucky. But be aware that this is by definition not a stable version.

* "User wants a stable version of OpenFOAM-dev"

o Check out the most recent tag found in /tags/OpenFOAM-dev. Once a new stable version gets released, one can switch to it with "svn switch".

And from my experience, this is usually true for a lot of very active OpenSource projects with a Subversion archive, not just for OpenFOAM-dev; the latest, meanest version might take you on a wild ride, experienced user or not.

However, please note that the developpers that contribute to "trunk" branch of the openfoam-extend svn repository are very professionnal, and very competent. This bleeding edge release usually compiles flawlessly right out of the box.

But simple errors also happen, like the missing Make directory for zlib. This zlib package has been updated to a newer version a few weeks ago, and I guess it needs to be revisited in order to add this missing directory. This will be fixed. But again, this section of the SVN is for the bleeding edge release, and these kind of problems are bound to happen once in a while, like it or not.

Also, personnally, when I first start playing with a new package available from a Subversion archive, I always start downloading a stable tagged version first, never the latest bleeding edge version. But this is me.

For instance, the very stable tagged release OpenFOAM-1.4.1_dev_07_11_14 would have given you a bit less trouble to compile. And it would have been a very good starting point for you to discover OpenFOAM, to make sure your workstation is configured correctly for compiling and running OF, and to eventually move on to the latest version, if needed.

How can a newcomer know about this? Well, a question on the Forum would probably have done the trick. Reading the General Guideline documentation on the openfoam-extend SVN web site is also very useful.
</blockquote>
About the list of dependency packages needed to compile OpenFoam:

This is a very common problem for many users that first start developing on a Linux machine, and I think this was your main problem; development packages are often missing from default Linux installation.

It would be a good idea to try to keep a list of the required dev packages needed to compile OF on different platforms. I guess we could try to put something on the Wiki to address this very common problem.

Enjoy the ride!

Martin

[bernd]

>Also, personnally, when I first start playing with a new package available from a Subversion archive, I always start downloading a stable tagged version first, never the latest bleeding edge version. But this is me.

Don't you think that is what I did?
I did start with the latest "stable" version in the tags directory. I didn't count (what I thought were) the errors, but I had the impression it was even more than my later attempts with the "bleeding edge".

And if you start asking for help on other projects you are always pushed to use the latest development version, because this is where errors are still being corrected.

If I'm very bored during the next weeks I could start another build of OpenFOAM-1.4.1_dev_xx_xx_xx and compare the output with my recent successful build. But considering the vanishing interest to change something I doubt that I'll be bored enough.

I'll probably stop commenting in this thread now and instead try to answer questions similar to mine.

Bernd

[eugene]

I hope you realize OpenFOAM-1.4.1_dev is a community/collaborative extension of the what is released by OpenCFD. It is not a development version for the OpenCFD release - i.e. the additional components present in OpenFOAM-1.4.1_dev will most likely not be supported by the stock 1.5 OpenCFD release.

I mention this because recompiling the extend release is only really necessary if it contains major components you specifically need that are not present in the core. If you need isolated bits it is straightforward to add them to you installation individually.

On the other hand, if you plan to contribute to the extension, you will of course download the lot.

[hjasak]

Quite the contrary - in fact, OpenFOAM-dev SVN is the only community-supported open-source location where people can contribute code, improvements, bug fixes and similar to OpenFOAM. It also hosts various application-oriented user-group areas.

In the SVN you can download and update the current version of OpenFOAM, with or without enhancements but with all known bug fixes (again, supported by the community), algorithmic improvements etc. as well as substantial contributions across many areas. The list of contributors (warning - advertising own stuff) can be seen from the SVN log.

True, to date there are no contributions from Henry in the SVN, but this is his choice. OpenFOAM-dev has successfully gone through versions 1.3, 1.4 and 1.4.1 without any trouble, so I do not see any issues with future enhancements either.

The alternative to freely available bug fixes is to pay for software support and get the same thing for 6000 Euros per year.

My first priority here is to keep OpenFOAM open, especially in terms of community-based development and enhancements through hundreds of projects using it so far.

Hrv

[lr103476]

But still, since Henry doesn't contribute to the OpenFOAM-dev SVN, we cannot really be sure that ALL bug-fixes and improvements from BOTH OpenFOAM-dev and OpenCFD-1.5 will be synchronized. Or maybe, Henry keeps a good eye on the OpenFOAM-dev and throws all the bug fixes in OF-1.5.

Since there have been some time scheme / moving mesh related bug fixes, I need to run my test cases whenever I switch to a newer OpenFOAM version (dev or not). This is far from ideal, but it is as it is, CFD is a continuing process of code use and code development.

Regards, Frank

[hjasak]

Sure Frank,

Like in the past, I will go through all the changes and merge them in. Don't worry about this: it was my responsibility at Imperial and during all the time at Naabla Ltd (found a forbidden word on this forum!). It usually takes me a few days, but based on past experience more care is needed. You may recall all the cyclics problems with 1.4.1 release...

Hrv

[alberto]

I'm trying to compile the development version myself (always used the official one). However I'm having various problems.

First of all, is it really necessary to recompile all the compiler/debugger and friends? Or is it possible to use the same provided with the official OpenCFD version?

Second, are there updated instructions? The buildinstructions.txt file looks outdated (it refers to files that are not there, for example).

Thanks in advance.

With kind regards,
Alberto

[alberto]

Some more information about the compilation problems I mentioned above:

- The system is OpenSUSE 11.0, on which I had no problem to install and use the OpenCFD version of OpenFOAM.

- The buildinstruction.txt file says:

"2) Download files

Get all files form the sources directory on the web site and put them into the linuxSrc directory"

Which site does it refer to? OpenFOAM extend is based on a SVN repository.

- The same instruction file suggests to recompile a lot of utilities (gcc, gdb, cmake, dx, paraview). Some of them are required in outdated versions. Are these sources collected in a repository somewhere?

- Considering that I don't need paraview support, but I'm mainly interested in the LDU solvers, I tried to compile only the core libraries. However I failed many times due to huge number of errors I obtained.

The first problem appears with zlib, which doesn't compile and complains about a missing -lOpenFOAM

The following problem is MPI. Not needing it for now, is there a way to disable its inclusion?

Thanks in advance,
Alberto

[jaswi]

Hi Alberto

Wish you a nice sunny Sunday :-).

I have been using the development/SVN version for long on OpenSUSE 10.3 box, and this is how I compile it (it has worked until now :-) ) :

- Download or svn checkout the dev version
- take gcc and java from the official Openfoam.org and untar it to linux64.
- you don'need all the stuff listed in that list if you are not a purist. preinstalled gdb works as fine as the one you will install.
- paraview , OpenDx and cmake are also not required if you are not using them


Before i start compiling I have the following folder structure:
OpenFOAM
->OpenFOAM-1.4.1-dev
->linux64
-->-->gcc-4.2.1
-->-->java

Next I edit the .OpenFOAM-1.4.1-dev/bashrc for
--> set the compilation options : opt / debug
--> export WM_64=on
--> comment out the sourcing of script files for 3rd-party post processing utilities

and

OpenFOAM-1.4.1-dev/.bashrc for
--> version number of gcc compiler as for both SVN/dev vseriosn it is set to 4.2.2; change it to 4.2.1
--> make sure that java path is set correctly; there are two options given , pick the 1st one pointing to your linux64 folder.

once all set, source the bashrc and check with foamInstallationTest. Should be all OK

Now to identify which part of installation is problematic I never compile it as one big chunk. I suggest the following.
-> first compile only the /src
-> then compile the /applications/solvers
-> then compile each of the folders in the /utilities

Such an approach is interactive but always takes less time in comparison to looking for the source of errors. To compile in this way you will just need to
-->first edit the /src/Allwmake and comment out the compilation of applications in the first run.
--> once the /src is compiled , re run the ./Allwmake and it will show that the there id nothing tobe done and all you core libraries are up to date.
--> the cd to applications and edit the /applications/Allwmake and comment out the compilation of /utilities. Running this Allwmake will compile your solvers. Just re run to make sure that ir spits out no errors

--> Now compile the /applications/utilities folder. for this you will have to issue
wmake all <foldername> fir each folder in the /utilities .
--> special caution is required when you are compiling the /postProcessing as it has the graphics folder which is the source cause of most of the erros and is not required in your case. Removing iit is not recommended , just skip its compilation.

--> /postProcessing also has /dataConversion folder which has all the format convertors. All compile well except the foamToVTK as it requires the lnInclude folder from the /postProcessing/graphics/PVfoamreader/vtkFOAM/ and it is missing. just cd to /postProcessing/graphics/PVfoamreader/vtkFOAM/and create the lnInclude folder and in there create the soft links to all the .C and .H files in the vtkFOAM folder.

Let me know if you face some problem and post the error here. The whole process will not take more than two hours. It just gives you more control over the whole compilation preocess and you know what is causing the error.

Best Regards
Jaswi

[hjasak]

You can compile the code with ANY compiler of your choice - simply set up your environment appropriately. Furthermore, zlib is a public library, it is written in C and if you have compilation problems with this, you must have some serious issues with your computer installation. WHY does it fail - what is the message? Do you have the compiler installed? Do you have all system headers you need?

Hrv

[alberto]

Dear Jaswinder and Hrvoje,

I'm following right now the instructions suggested by Jaswinder. I successfully compiled the src subdir. Thanks a lot for the very detailed procedure Jaswinder!

The main difference in the procedure I used is that I didn't install java provided by OpenCFD because I have the same version available on my system, so I just pointed to /etc/alternatives/java_sdk_1.5.0

About the error messages I obtained regarding zlib, it happened at the linking stage due to an inconsistency in enviroment variable (of course, yes I had the compiler and headers!).

The compilation of applications gives some problem with some solver (I don't need them, just reporting fyi):

- /home/alberto/OpenFOAM/OpenFOAM-1.4.1-dev/lib/linux64GccDPOpt/libcombustionTherm ophysicalModels.so: undefined reference to `yyFlexLexer::yywrap()'
collect2: ld returned 1 exit status
make[2]: *** [/home/alberto/OpenFOAM/OpenFOAM-1.4.1-dev/applications/bin/linux64GccDPOpt/reac tingFoam] Error 1
make[1]: *** [reactingFoam] Error 2

- Same problem for XiFoam, engineFoam, dieselFoam, dieselEngineFoam, Xoodles

Thanks for the help.
Alberto

[ngj]

Hi Jaswi and others

First of all, thanks to you Jaswi for the extremely detailed how-to-compile. It work exactly as you said, and no problems at all occureed.

Secondly I would inquire, if any of you know of the existence of a WIKI which tells the same as Jaswi' elaborate explanation. I've tried to look, couldn't find anything and considers doing a page. Though it would just clutter the wiki if it already exists. If I don't hear anything, I'll just assume that it doesn't exist.

Have a wonderfull weekend,

Niels

[alberto]

Hi Niels,

there's no such a page on the wiki. I planned to do the same you suggested, but still have not found the time :-(

P.S. Didn't you meet problems with the libcombustionThermophysicalModels.so library?

Regards,
Alberto

[mbeaudoin]

> there's no such a page on the wiki. I planned to do the same you suggested, but still have not found the time :-(

Well, this page is available since June 2006...

http://openfoamwiki.net/index.php/Ho...mpile_OpenFOAM

Martin

[alberto]

Yes, I'm sorry. In the hurry of the answer I forgot that page. However I think it contains too many information and steps, making it complete but not necessary for most of the users.

In particular, it's not necessary to build gcc, libutils, cmake, ...

A shorter guide would be useful for users who don't want to start from the foundations of their systems, and the one you linked might be the second choice in specific cases, where the "short version" fails.

Regards,
Alberto

[mbeaudoin]

Hi,

Yes it's true, this document is complex, but it is also a reflection of the numerous little "gotchas" you will find after trying to compile OpenFOAM over a lot of different Linux "flavors", not just for one Linux distro in particular.

> In particular, it's not necessary to build gcc, libutils, cmake, ...

I would say "it's not ALWAYS necessary to build gcc, libutils, cmake, ..."

For instance, installing libutils was necessary to overcome a dependency over a little file called demangle.h that is installed by default with SuSE, but not always installed by other Linux distros.

cmake: some older version of cmake simply cannot compile some newer versions of paraview correctly, and some newer versions of cmake might not either compile some slightly older version of paraview. So, depending on how recent your Linux version is, your RPM installed version of cmake might work for compiling the paraview version required for OpenFOAM, it migh not work either.

So keep in mind that as OpenFOAM is evolving while still keeping some dependencies on external packages, the Linux distros currently available are also evolving quite rapidely.

So a recipe that works well for SuSE might not work so well for Centos.

But also, a recipe for compiling OpenFOAM for Ubuntu version ABC might not work for Ubuntu version XYZ because, for example, some packages like cmake were upgraded in order to be compatible with a more recent version of paraview. But these newer versions of paraview/cmake might not necessarily be compatible for the current version of OpenFOAM.

So I totally agree that a shorter compilation recipe would be much easier to swallow, but I would recommend that you also take the time to label those shorter recipes as "known to work for this and this version of Unix/Linux".

The fact that people are willing to take the time to document and share their experience for compiling OpenFOAM is great and should be encourage. There is a lot of room on the Wiki for all those nice and extremely useful contributions.

But keep in mind also that not all versions of Linux are created equal.

My little 2cents.

Martin

[alberto]

I can't agree more with what you wrote Martin, and surely I didn't want to discourage who writes very detailed documentation. I'm the one always saying that we need more documentation after all :-)

I created an initial page here:

http://openfoamwiki.net/index.php/Ho...M_the_easy_way

and I linked both the guides (full and this one) on the main HowTo page, so that they can be easily found.

Regards,
Alberto