Dear FOAMers! I am despairing
 

Dear FOAMers!
I am despairing of the installation of the OpenFOAM development version (http://openfoam-extend.wiki.sourceforge.net/), and from what I read in this board, I'm not the only one.

When I check out the svn version (svn co https://openfoam-extend.svn.sourceforge.net/svnroot/openfoam-extend/tags/Core/Op enFOAM-1.4.1_dev_07_11_14/), first of all several directory names don't fit the buildinstructions.txt.

After correcting these directory names as I think is best, and sourcing the bashrc to setup the environment, compilation is possible and runs for a few hours, but none of the icoFoam and other solvers are generated.

In the logfiles I find several linker errors like "-lsampling not found". These are libraries of OpenFOAM-1.4.1, so I wonder if OpenFOAM-1.4.1_dev has to be built on top of OpenFOAM-1.4.1 and not standalone?

Finally compilation of mico, paraFoam and FoamX produce a whole bunch of error messages. Do I have to disable their compilation (how?) if I downloaded the binaries of gcc, paraview and j2sdk from http://www.opencfd.co.uk/openfoam/linux.html#linux?

Is it so hard to update the build instructions every few years? Most of my fellow students have given up using openfoam, because they received no help in this board. Now they use FreeFEM++ and have other problems, because it is less powerful.

Can one of the experienced openfoam users please spend an afternoon to build the development version from the openfoam-extend site in a clean environment (no preinstalled openfoam, parafoam, mico,...) following the included buildinstructions.txt? And then please correct what appears to be nonsense, and explain which of the ~5000 error messages can be ignored.

I'd really appreciate this.

Bernd

Hello Bernd, You seem to be
 

Hello Bernd,

You seem to be massively frustrated with the build process, for which I apologies. The build instructions have been updated a few weeks ago and only last week I have done the installation of OpenFOAM-1.4.1-dev from scratch on a brand new machine accoring to the instructions with precisely zero errors.

My guess is that the reason for your frustration are missing packages on your system, for things like flex++ - discussed in detail in this forum. Here I cannot help you - look at the actual error, tell me what it is, and I will help you. Unfortunately, it is unreasonable to document all packages you need to install before you start compiling OpenFOAM for all machines and all users.

OpenFOAM-1.4.1-dev is a complete and self-contained version and you do not need to unpack or build it on top of anything else. I would be grateful if you could please concentrate on the problem, go through it step by step and tell me what your FIRST error message is. Once we sort this out, you can contribute to the open source effort by documenting things that I failed to explain in buildInstructions.txt. Deal?

I am sorry to hear people are giving up on OpenFOAM because they cannot build it - you cannot expect 800 thousand lines of free code and free support as well.

How about it?

Hrv

P.S. I do get annoyed with comments like "please correct what appears to be nonsense" and for this reason I intend to demonstrate how you were supposed to spot and resolve each of your errors in turn.

P.S. I do not like anonymous p
 

P.S. I do not like anonymous posters - who are you?

Hrv

Dear Hrvoje, I can understand
 

Dear Hrvoje,
I can understand that you are upset with my tone and apologize that I overreacted in a moment of repeated frustration. I'll happily add installation instructions to the wiki that can help users like me, if somebody explains to me how to compile the dev version with zero errors.

>The build instructions have been updated a few weeks ago and only last week I have done the
>installation of OpenFOAM-1.4.1-dev from scratch on a brand new machine accoring to the
>instructions with precisely zero errors.

The instructions in the very file that I mentioned above contain the same inconsistencies since several months, and also the buildinstructions.txt in the svn trunk have not improved. Please tell me where to find the new instructions.

>My guess is that the reason for your frustration are missing packages on your system, for things
>like flex++ - discussed in detail in this forum.

This may be, but flex++ and bison are installed.

>Here I cannot help you - look at the actual error, tell me what it is, and I will help you.
>Unfortunately, it is unreasonable to document all packages you need to install before you start
>compiling OpenFOAM for all machines and all users.

As soon as I know what I am supposed to do for compilation, I'll list the beginning of the error messages.

>I am sorry to hear people are giving up on OpenFOAM because they cannot build it - you
>cannot expect 800 thousand lines of free code and
free support as well.

Sure. But most other successful GPL projects have several authors who try to make the documentation useful to new users. This is necessary to attract a larger community in the first place to make the whole project expand faster. Openfoam may be different, because it targets not a huge user group.

Concerning my anonymity: In my opinion the name is sufficient to map discussion entries to my person. On top of that I only want to mention that I am a student of computer science who got interested in CFD some months ago and was very satisfied with Openfoam until he wanted to use the extended version.

Bernd

>I am sorry to hear people are
 

>I am sorry to hear people are giving up on OpenFOAM >because they cannot build it - you cannot expect >800 thousand lines of free code and free support as >well.

I disagree. An open code without documentation is a closed code for most of the people.

A user can decide to adopt OpenFOAM for various reasons, but the main two I think are due to its openness (control of the code) and to the independence it should offer.

I don't include cost reduction, even though it's a factor, because I know various groups that tried to switch to OF and gave up because they didn't see the advantage when they made the comparison with commercial tools. To make it short, summing the time required to learn OpenFOAM to the cost of the almost always necessary support seemed to them less convenient than simply buying a well documented commercial package.

At the moment OpenFOAM is formally open, meaning that the code is accessible. But this is true for simple tasks, for which a solver already exists. For the rest it's exactly as a closed code, because having the source and the doxygen documentation is simply not enough for most of us, me included. 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.
This misses the point of gaining independence in the use of the code.

With this I'm not saying that the documentation of the code should be free, or that it should be absolutely complete. But something has to be done in that direction, and it can't be only community based. The community is small, or at least it's small the cooperative community (I don't know the number of OpenFOAM users, but the contributions to the wiki are of just a few, for example!), and also for long time users a lot of aspects of the code are still unknown. Plus, useless to hide it, many just take and don't give back.

Most of the successful open source project have a company behind and a strong active community which work together for the success of the software. I think it's possible to do something like this also with OpenFOAM, but it requires to cooperation of both parts, and, at the beginning, a sort of "investment in the transmission of knowledge", which can't really be done only with a discussion board.

To start the process, I perfectly understand that some money is necessary, and I think there are various possible way to support the developers to write more documentation, especially oriented to the development of new solvers and additional features, if they're willing to.

Just some ideas:

- A fund raising in the community.

- Open donations (This possibility was available, then removed. Probably it wasn't that successful, but it was the beginning of the open life of OF).

- A small amount of money added to the price of paid support.

- Limit the development for a release cycle and work on documentation.

Just what I think,
A.

Hi Alberto First, I appreci
 

Hi Alberto

First, I appreciate your constructive appraoch. You have always come up with good and practical appraoches. I hope that some of the listed ideas find their home so that more and more people get interested.

OpenFOAM is without any doubt a wonderful oppurtunity for the CFD community. It is, as you have already said, very attractive at the startup phase but becomes a nightmare when you really want to do something productive.

There is no doubt that documentation is the most crucial part but at the same time the most frequently asked question is why there is none at first place. Well asking that question is very easy but anybody who has undertaken the task of documenting a moderate sized code knows how much time and resources it takes to accomplish such a task.

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.

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.

Here I strongly support the ideas proposed by Alberto. Create a common fund raising or common support account where one could get support proportional to their contribution. That will not deter a small user who in the absence of support just gives up. Also lets make a fundraising appeal to the forum particularly for the documentation and see how serious people are about it.

There are some points I would like to bring into notice. First, the forum is full of basic questions which are being asked repeatedly and there are so many questions which are unanswered. The search spits out so many responses but only 10-20% of these are useful or have any useful information. If we could somehow come up with a solution to make it leaner. Secondly, a valid email address should be made compulsory at the registration.

Hope we will be able to solve these issues with the spirit of Open Source.

With Best Regards
Jaswinder

Hi Jaswinder, first of all,
 

Hi Jaswinder,

first of all, thanks for your support.

I would like to clarify that I don't really mean to discharge the responsibility of the missing documentation only on developers. I really think it's a shared responsibility. But I also hardly see how users can document something without clearly knowing it themselves.

If I support the idea of "community sponsored" projects, if they're of common interest, I disagree with the "proportionality" criterion. I really think that if the community decides to sponsor a project, the results of that project should be then open to everyone. This is the spirit of a community that works. I don't think a form of community paid support where anyone can ask what he like would work. In my opinion the first step in that direction is to support a sort of "OpenFOAM programming for dummies", to significantly lower the slope of the learning curve.

About the discussion board cleaning, we have a nice and well maintained (thanks to Bernhard) wiki which is always in need of love. So, transferring there the knowledge spread in the discussions would be a starting point.

Regards,
A.

Hi, I would like to add my th
 

Hi,
I would like to add my thoughts to the current discussion. As new OpenFOAM user I found the learning curve quite steep even though I have extended experience as software developer and did my master's thesis on a CFD code. According to me the main problem is exactly the lack of documentation. I understand that one cannot expect to have all the questions answered on the forum however there should be a way to provide a better start to new users. I believe that all the energies wasted in frustrating attempts could be better employed in adding test cases and tutorials to the wiki. I plan to give some contribution to the wiki myself once I get to a decent point as a OpenFOAM user and I think a lot of people like me will be more able to contribute to the project when given the opportunity to do so.

Best regards
Luca

I am also frustrated with the
 

I am also frustrated with the installation process, especially with the three approaches:
- Official documentation
- Guide on the wiki page
- Hrvoje's guide
(I do not mean to criticize, as they are all product of individuals that tried to help out).

I am now at my third attempt. The forum and some individuals have been helpful so far, but I'm still not there yet :-)

I would be very willing to contribute to the installation documentation. I think that newbies that benefit from other's advice do have a moral obligation to give back to the community. One way is to improve the documentation on the very topic that they received help on.

The Wiki page may be the place to start with that effort. I'll try to add to the FAQ - with questions at least :-)

Cheers,

Mirko

Hi, I'd like to add my own
 

Hi,
I'd like to add my own couple of thoughts to this thread. Mainly, that the open source "mentality" as I understand it is something like this: if the feature you want doesn't exist yet, do it yourself. In this case, that feature happens to be documentation and while it would be nice to already have the features done, this is just where OpenFOAM is right now.

I'd like to recommend the wiki become the repository for all these contributions because that's the quickest place everyone can get to. It also means that not everyone needs to actually *write* material to contribute to the project. People can help edit, test and organize other contributions to the documentation project.

As for getting the dev version compiled, when I was having loads of trouble with dependencies, etc, my usual method was to create a logfile ("./Allwmake > logfile") and then grep for errors (grep Error logfile > errorLog) and then step through one at a time. Usually, you can enter an error message into google and someone's answered the issue already somewhere on the internet. That takes a lot of work and is not "productive" time, but it will eventually get you compiled. I just barely know C++ and I was able to get everything running, so I know it's possible.

Good luck,
Mike J.

Hello, I've been following
 

Hello,

I've been following OpenFOAM since the beginning of its open life, and I'm a bit skeptical about the "do it yourself" approach applied to documentation.

My main objection is that I don't think a community user can learn OF in a reasonable time for its purposes and then document what he learnt.

I really think a stricter cooperation between developers and community, with maybe a more open development approach, is necessary. The community alone, exactly as the developers alone can't do it. Of course this puts the problem of funding, but as I said, there are various ways to at least try to solve it.

Regards,
A.

Hello, And ofcourse, as alw
 

Hello,

And ofcourse, as always... a very Good Evening too :-)!

Since this whole discussion started up because of compilation issues with the OpenFOAM-1.4.1-dev SVN Version, I thought I would just let it be known, that I (rather.. my very tired laptop).. just completed a successful compilation of OpenFOAM-1.4.1-dev downloaded from SVN last evening.

The only issues I had were:

1. There was no Make folder in the "zlib-1.2.3" folder, which was quickly solved by copying the Make folder from the "zlib-1.2.1" folder.

2. I had to change some of the entries in .bashrc, and .OpenFOAM-1.4.1-dev\bashrc to use openmpi-1.2.6

3. I had to rerun the compilation a second time (which has always been the case for me so far... and the second time goes through... as expected, much faster), I think because of foamFlex++, or maybe it was something to do with the ordering of the library dependencies

4. I had to change the java home path to reflect the java I use on my system (again... as always)

In addition, I do not use the paraview libraries which come with OpenFOAM because I use ParaView 3.3.0, with the native reader.

I do not use dxFoam... because I don't use DX

foamInstallationTest gave me a clean sheet, and currently I am running some test cases.... so far everything looking normal, and as expected.

And as a side note... I use GCC 4.1.2 rather than GCC 4.2.0... so I always need to do the relevant changes for that.

Have a nice day!

Philippose

>1. There was no Make folder i
 

>1. There was no Make folder in the "zlib-1.2.3" folder, which was quickly solved by copying the Make folder from the "zlib-1.2.1" folder.

I'll try this next time. Instead I installed the zlib-dev package on my system. Which is preferable?

>2. I had to change some of the entries in .bashrc, and .OpenFOAM-1.4.1-dev\bashrc to use openmpi-1.2.6

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?

>3. I had to rerun the compilation a second time (which has always been the case for me so far... and the second time goes through... as expected, much faster),

Thanks, this was the most useful remark ever! Now I have at least a few of the openfoam applications built successfully.

>I think because of foamFlex++, or maybe it was something to do with the ordering of the library dependencies

What is the relation to foamFlex++? Ad why should the problem be solved during the second build?

>4. I had to change the java home path to reflect the java I use on my system (again... as always)

Java is still one of the problematic things. Do I definitely need java 1.4.2 or java 1.5? I have java 6, which is recognized in /usr, but I haven't been able to get FoamX working.

Hello, You should be ok wit
 

Hello,

You should be ok with Hrv's latest building instructions.

You can also find on the Wiki a guide I have written on how to compile OpenFOAM from scratch.

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

I have compiled OpenFOAM on many Linux platforms over the years, so this guide is basically my own compilation recipe.

Other people have contributed to the document as well, so I guess this guide is still pretty much up-to-date.

Has Hrv pointed out, the most usual compilation problems comes from missing packages from your base Linux installation.

Regards,

Martin

My advice is to install openSU
 

My advice is to install openSUSE and try again the compilation procedure -- I think openSUSE is the distribution that OpenFOAM developers work with.

In the past I had some problems with Ubuntu and Debian, there were some incompatibilities with OpenFOAM that I wasnt able to overcome.

Regards,
Jose Santos

>You should be ok with Hrv's l
 

>You should be ok with Hrv's latest building instructions.

No, I'm not. See Philippose Rajans post for details which don't work.

>You can also find on the Wiki a guide I have written on how to compile OpenFOAM from scratch.
>http://openfoamwiki.net/index.php/Ho...mpile_OpenFOAM

I have already started and will continue correcting that guide whereever other forum users pointed out solutions to the same problems which I have encountered.

>My advice is to install openSUSE and try again the compilation procedure -- I think openSUSE is the distribution that OpenFOAM developers work with.

If OpenFOAM compiles only on a single distribution, this is not much better than proprietary software which is only available for windows. Fortunately it is not that bad, because there seem to be some users who are successfully using OpenFOAM on all kinds of systems.

If however Albertos ideas about some funding came true, I'd advise something else: pay a working group to clean up the build process, so that
- building is possible in any directory without editing cshrc files in different locations. Autotools or CMake should be taken into consideration.
- building is tested on a few (to be defined) architectures and systems, not depending on the developers individual configurations
- required packages are identified and excluded from or offered independently from the OpenFOAM installation

Besides the documentation a "./configure; make; make install" installation workflow may make OpenFOAM usable.

Bernd

Bernd, With all due respect I
 

Bernd, With all due respect I think you are being a little unreasonable. Problems such as these are very commonplace especially when dealing with development codes. Why don't you simply post what errors you are facing during the compile so that they can be solved one at a time.

Folks like Henry and Hrv were busy, are busy and will be busy with work. Yet they take some time off every now and then and post responses to common problems. It is important to remember that they are the major devs working on improving numerical methods, adding new solvers, fixing bugs etc. We owe our gratitude to them for such wonderful work.

For the record, I have used Martin Beaudoin's excellent build instructions to compile stock OpenFOAM 1.4.1 on over 15 different GNU/Linux clusters (archs: i686, x86_64, PPC64) with no major problems whatsoever.

It would help if you could explain what problem you are working on so that more experienced folks may be able to tell you whether you really need the bleeding edge OpenFOAM code?

Let's all calm down - this is
 

Let's all calm down - this is in fact very positive. I do not know how to set up a confiure/make/make install system, but other people do. So, splitting the task into people who can help with build errors (me) and the ones who can automate the build is a good idea.

This is definitely the way to get contribution from a wider community, and making the compilation easier is definitely positive. I promise to do my bit.

Hrv

>Bernd, With all due respect I
 

>Bernd, With all due respect I think you are being a little unreasonable.

Why?

>Problems such as these are very commonplace especially when dealing with development codes.

In my opinion OpenFOAM is too valuable to remain in this status. A little effort put into setting up reasonable build tools will be returned thousandfold. If I get help soon to solve my early installation problems, I'll try to achieve this. But all those comments about who respects whom how much make me feel like I'm fed up again before I start.

>Why don't you simply post what errors you are facing during the compile so that they can be solved one at a time.

Because Phillipose has mentioned a few things that solved some of the problems, so that I don't consider it useful to post 5000 errors that won't appear in the next build log. Unfortunately each compilation runs for some 6 hours, so that I can only start one each evening. Furthermore my harddrive died last night so that I first need a new one.

If you are up to answering questions, please start with those in my post from Tuesday, April 29, 2008 - 02:16 pm.

>It would help if you could explain what problem you are working on so that more experienced folks may be able to tell you whether you really need the bleeding edge OpenFOAM code?

Great suggestion. And if we find out that I really need the extended code, I'll have to simplify my problem so that I can use the 1.4.1 release instead. Everybody knows that software works best if only its developers use it.

Bernd

This wanted to be a _construct
 

This wanted to be a _constructive_ discussion, not a fight between who is happy of the status quo and who would like something more.

It's not really a question of respect for Henry, Hrv and the other developers. I don't think this is under discussion: they have huge merits, and it's under our eyes everyday we use OF.

The point is to find a way to improve the project at a community level.

About the compilation/packaging problems, a nice solution for the stable version (or a relatively stable snapshot of the development version) might be to offer pre-compiled packages for some of the most used distributions. I don't know much about the topic, but it might be interesting to consider the OpenSUSE build service. It's a service to generate packages (RPM's, .deb, ...) for various distributions (openSUSE, SLE, RH, Ubuntu, ...) and to provide them to the users. If it's interesting I can collect some more information through some friends I have in the openSUSE community.

Regards,
Alberto

Instructions: - report on y
 

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:

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

>lam is a self-contained libra
 

>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

Hello ,a nice day or maybe goo
 

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

@ Bernd: Having those packages
 

@ 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

Hello Bernd, A few more wor
 

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

Hello Pro. Hrv I get some p
 

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

> Posted by Jaswinder Pal Sing
 

> 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

Kati, feel free to drop an ema
 

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

>- follow OpenFOAM-1.4.1-dev/b
 

>- 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: http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif 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

Hello Bernd, Couple of obse
 

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

Hi Bernd, I've been lurking
 

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

>1. Did you "source" the .bash
 

>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

Dear Bernd, If I take time
 

Dear Bernd,

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

Hello Bernd, Could you tell
 

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

>Could you tell me exactly whi
 

>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

Hi again, Ok... I am curren
 

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

>Ok... I am currently download
 

>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

Hello Bernd, Here it goes:
 

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

Martin, thank you so much for
 

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

I thought that others might fi
 

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