There is a number of open source codes that are freely available for the CFD practitioners and other scientists too.

The common thread between all these programmes is that they have been developed on the Linux operating system.

The question that jumps before my eyes is this:-

is the linux O/S a unique O/S (in the sense that Windows is only Windows or Unix is only Unix) or it is just that the Linux banner is very wide and open.

Take any project on the sourceforge net and try to download it, no matter what your chosen programme is, you will find One and only one msi (micro soft installer) file besides a good number of files for the Linux installers.

To explain what I want to say by this public post, Let us take one concrete example, the visualization programme Visit, developed by a research laboratory (google for the details) and is freely available for download, you log on the web site,then the download page, and voila There is a number of binary precompiled files for different arch/Linux systems (ask your self again if there is only one Linux operating system) then you have the very intelligent build_visit script. Since none of the precompiled binaries were suitable for my openSUSE intel arch, I downloaded that intelligent script, and in about 85 minutes I had visit 1.10 running on my computer.

Is the reason of me calling this script "Intelligent solution" clear to you, the reader, now.

Take the other codes mentioned in the head line, they are freely available for download, BUT, you need a number of freely avaiable external libraries with a specific version number, newer versions of these libraries are not guaranteed to produce a running code.

My simple question is this: Why the developers of these codes can not develop a similar build script, in the worst case, they can copy the build_visit script and modify it to suit their particular libraries needs.

Of course I am angry, you spend time chasing these dependencies and end up with a number of error messages just because one library or more is/are newer than the ones used by the developers. You, the reader of this post, can make the change, just express your opinion, few lines on this public forum will be heard by those developers. Happy Computing to all

So far, the solution to such noise, that I have followed was the use of the caelinux distro

There are multiple reasons for not bundling all libraries. It takes disk space and this may be significant when you have many independent versions of the same libraries. It takes extra memory. The memory required by shared libraries needs only be used once if all programs on a system link against the same version.

The really big one is diamond dependencies. Suppose I develop a code which links against libraries A and B, both of which depend on C. If A and B bundle their dependencies, then there will be two versions of C around (Ca,Cb) but my program can only use one of those. This means that either A or B will be using symbols from the wrong version (a version different from what it was compiled against), hence will likely be broken (seg fault). Note that most scientific packages are really libraries, at least in that the most powerful way to use them is to link them into your own program.

If A and B did not bundle C, I would install one version and built both A and B against the common C. This is a problem when A or B have very specific version requirements, but most open source projects keep fairly current. VisIt currently needs an older Qt, but the next release will be current. Most dependencies can be obtained and updated through your distro package manager. It is usually easy to make a new package if one does not already exist. I recommend doing this for any project that you are not tracking the development (cvs/svn/hg/git) version of. Windows is worse in this regard since it is standard to bundle all dependencies and you don't have a nice package manager to resolve dependencies and maintain a current common version.

Also note that Linux is a kernel which runs on many architectures, not an operating system. Windows is much more homogeneous so there are fewer cases to consider. For instance, there are two x86_32 Linux binaries (one for the old 2.4 kernel and one for the 2.6 kernel) compared to one for Windows (just XP, no Vista). There are no Windows binaries for x86_64, Itanium, or Altix.

This is a very interesting topic indeed.

I'll speak as one of the Code_Saturne's developers, but I'll try to remain as general as possible (feel free to correct me if I'm wrong somewhere).

Installing a software (from the CFD world or not) on a Linux distribution is usually a simple task if this software has no dependency, especially if it is based on a build system like autotools, cmake, or scons and provided that the developers have well tested their build system (it is not always easy... see further).

Now, say you have one or more dependencies. I see four solutions: - make a binary package that contains everything that is needed (see for example the ParaView binaries) - make a minimal binary package which tries to use the distribution packages of each dependency - package the software for a given distro - write an installer (like for Visit) - let the user install the system

The first solution would seem to be the simplest one. But UNIX world is not perfect... and every single distribution have different packages versions or packages layout. Let's take a first example: the HDF5 library. More and more mesh data file seem to rely on this library (for parallel I/O and so on...); CGNS in its third version can depend on HDF5 in its 1.8 version whereas MED (French: Model for Exchange Data) depends on HDF5 in its 1.6 version, and both version are incompatible (except with some trick as usual...). Is it the developer task to chose which data model the user need ? IMO, no. So you have to let the user decide which means the installation has to be done by the user himself. And I do not even speak about the wide range of MPI distribution for parallelism...

Another explanation why the first solution is not the easiest one is the answer to the question: what are my dependencies ? I'll take a Fortran code (though you might replace Fortran by C++ I think) as a simple example. When you compile your code with a Fortran compiler, you'll need the Fortran runtime libraries (e.g. libgfortran for the gfortran compiler) but this very library is not necessarily available on the user system... So you end up with providing the Fortran libraries in your binary! This is endless...

Coming back to the HDF5 example, if you try to create binary packages that suppose the user have it installed his system (every Linux distro has one available), you cannot ensure that it will work flawlessly on every system: firstly because the version is generally not the same, secondly because even two identical version of the same library are not always installed with the same layout (compare a RedHat and a Debian system).

Now, the installer option. That would be the perfect option if all the dependencies build systems worked flawlessly and the developers had enough time to maintain the install script. Just as an example, the CGNS build system is not as portable as one would expect (if you find out how to compile it on a BlueGene system, please tell me!). So, the question is: is it the developers task to patch all the dependencies build systems (when needed) ? IMO, no again. I understand it is frustrating for the user because one has to dig into all the dependencies, which can be quite tedious.

This lets us with two options: create a binary package for the main distros or let the user do the job. The open-source community can help with the first option, whereas the code support can try to guide the user during the installation.

To conclude I would say that Linux distros are too different (and users wishes as well!) to have the developers deal with all the configurations by themselves.

Sorry this long post... I hope it will have interested someone ;-)

David

ps: As far as Code_Saturne is concerned, we chose to follow several different paths: an installer is provided on the website download page, a package is available for FreeBSD systems (and hopefully soon for other distributions as well), and perhaps we'll create a binary package someday... (nothing sure for that)

Jed and David

I have been blessed reading these two enlightening posts. But you spoke out from a developer point of view, that is ok, but if you were on the same side as mine, you would agree with my original post.

Both have emphasized the importance of linking the correct version of the dependencies, and this is exactly what motivated me to post in the first place. Now let me detail a bit what the build_visit script does:

1- The script downloads the correct versions of the dependencies as needed by the programme.

2- Builds the application on your machine (no matter what distro you have).

3- Once the application is ready, you have the option of building a binary package for your machine/distro. Thus you can delete whatever has been downloaded before and save that hard disk space.

In the end, I, as a user, have the application running on my machine and you as a developer of a open source code has achieved one of your main goals and that is the code is running properly on your audience's machines. Let us not forget that the objective of the open source community are far more than writing a code.

I am glad that both of you are developers of such nice and useful codes, and hope and pray that you continue this way, all I am asking for is that a build_visit look alike is considered by the time of the next release.

Wish you success

Ahmed,

I was interested to read your post as I've spent many hours over the past week installing OpenFOAM. I have used Fluent since the mid-80s, starting with using v3 on a VAX station under VMS. Our company has licensed Fluent for many years, progressing through v4 and v6 and now v12.

It works fine, but as we work more with the user defined functions, parallel processing, and post processing, the worse the support becomes. It doesn't help that their support seems to be completely outsourced. And, for the computers we bought last month, we still had to spec. them with XP as Vista wasn't appealing.

We looked at Star-CD awhile ago, have considered Phoenics, have played with KIVA, and long ago used an in-house code (16,000 cells on a Pentium 3).

I had read a lot of good things about OpenFOAM and was optimistic about trying it. (I had also read about some of the issues). So the first thing was to choose a version of Linux - I went with openSUSE 11 - than you have to choose the graphical interface, and then the confusion (on my part) has just begun.

A few hours after downloading openSUSE and OpenFOAM, I was able to limp through the first tutorial. No graphics yet as I couldn't get Paraview to work, or more specifically couldn't get Qt to install. Being kind of niave about Linux, I have been surprised to muddle through the different package installers, GNOME vs. KDE, bash and other shells, not to mention Ubanantu, Red Hat, Fedora, and whatever else.

One of my issues with Fluent has been the dependence on third-party software - mpich2 for parallel processing, updated C++ compilers for user defined functions, opengl for graphics support, Hummingbird for Xwindowing, and the licensing manager just to have the privilege of getting in. (That, and the fact that I could buy a new Mercedes every year if I saved the licensing fee). My very limited experience with OpenFOAM is that these issues will be much worse.

Reading the OpenFOAM (and other Linux) forums it is obvious that there are a lot of people like me that are frustrated with the install of opensource software. It would seem that the only option to avoid this would be to spend a lot of time to learn Linux. Sure, you can get help as you encounter each problem, but then will be sure to run into another roadblock around the next turn. At this point, I'm not sure that it is worth investing that time for the benefits I might get from any opensource CFD code, but will keep working at it.

I guess it is true what they say, "There is no free lunch".

http://www.caelinux.com/

Well additional packages and installation procedures are really frustrating. And for a guy who is a dumb as me, i find myself often wasting lots of time installing and with no fruitful output.

This was the reason, when I thought of putting iNavier online, I make sure that it could be compiled easily and avoid external packages. (In other words all the c++ files you need are there in that folder).

Unfortunately, I have lots of work, and after office hours it is difficult for me to spend time debugging and verifying the source code. (my wife started complaining that i spend all evening working on something that gives no returns). So iNavier could not augment into something serious.

But as a hobby, and on side work for my pleasure, i am working on improved version of that code (have added lots of interesting things we might need but current solvers do not provide). So if i put new solver (iNavier will die out) it will again be complete in itself that it will have all the c++ files in one folder and user could compile it easyly.

I wish if this were true for other codes, I could use them. OpenFOAM is such example, I have ubuntu linux but i could never make it work. (For me its easy to write my own code and do things i want rather than trying to make OF work. Its beyond my tiny brain).

OpenFoam, I gave up installing openFOAM on my openSUSE 11. I tried a complete recompilation from the source code, the Allmake script (Supplied with the openFOAM code) gave me two pages of error message in spite of the fact that the openFOAM check installation script (also supplied with the code) gave me the "continue OpenFOAM installation" message. I also tried to install from the precompiled files and I faced a Berlin wall in the middle of the process. When you try to install the version of Qt recommended by OpenFOAM developers, the openSUSE system will issue a warning to you, if you continue you will face a tremendous change in the system behaviour (Read the explanations given by Jed and David above). I did not pay attention to that warning and finally I have to do a complete reinstallation of OpenSUSE 11. May be you can install it as local file to the OpenFOAM directory, but I have no idea how to do that, consult an expert on the subject. wish you good luck

Well, first of all the OpenFOAM message board would be the place to go. Having said that, you can easily install the OpenFOAM binaries and run it from the command line. The tricky bit could be paraFoam, but you don't actually need it -- just use the foamToVtk tool and use a precompiled ParaView from Kitware.

If you want to compile it yourself I would recommend to install additional versions of certain software, such as Qt for example, in a different directory (e.g. /opt/QtForOpenFOAM). In your .bashrc or .cshrc or whatever shell you are using you set the required environment variables to the alternative versions. Never mess with what SUSE does in /usr, /lib, /usr/lib and so on -- well that would be my recommendation...

Dolfyn, see www.dolfyn.net/dolfyn/voorbeelden_en.html (also included in caelinux), is developed under Linux because all the tools are there, the user environment is familiar (unix-like) etc. With other words pure personal preferences for the look and feel of the userinterface/desktop. That's one thing.

Writing a code for a certain platform, or platform independent, is another issue. As this was envisaged from the beginning some important assumptions/decisions/wishes were made: a) use of Fortran95 (and stick to the standard, thus no autotools are needed -it used to be a nice concept a long time ago-) b) be able to compile it in one shot (no real necessity for 'make', or any kind of 'make') c) do not use includes, weird file names (ever haunted an include on your system? ever worked with several unices and open source? tried to compile a 'big' library or (cfd)code on anything else as the system it was written on?) or platform/compiler specific 'solutions'.

dolfyn has been reported to have been parallelised (with OpenMPI, Hypre) on an IBM supercomputer system ('Hochleistungsrechner'), runs on Debian, BSD and Windows systems (see for example, sorry in Dutch, http://www.dolfyn.net/dolfyn/installatie.html#vistabin). As long as a Fortran95 compiler is available, free or otherwise, dolfyn will run (and even non-specialists can compile the code).

The situation gets more tricky if certain libraries are an essential part of the compilation process (like graphics/OpenGL, Hypre, MPI, file interfaces). Thus the default version should be released without them (if at all possible, otherwise try to minimise it to a absolute bare minimum).

My 2 cents. Have fun! Henk