[gerbervdgraaf]

Hi,

I am an enthusiastic GNU/Linux user and developer of some OSS software
using the GNU/Debian system. Recently I started to work with
OpenFoam.

As I experienced by myself and also by many postings I read on this
site, compiling the software is not straightforward. In addition, the
software also includes the building of third-party libraries and
programs that most of the time are already available on the majority
of GNU/Linux platforms. To my feeling, the building/configuration
scripts (Allwmake and companion) are a little aged, so to say, which
doesn't help much to maintain the OpenFoam software. Here are some
suggestions:

Stripping the software: removing all programs and libraries that do
not belong to the core of OpenFOAM. Many problems during the
building occur while compiling, for example, Paraview. This is not
necessary anymore on a GNU/Debian system as Paraview can simply be
installed by "apt-get install paraview". The same for many tastes of
MPI (LAM, MPICH, OpenMPI) and other libraries.

Adapting the environment such that OpenFoam libraries and programs
will be installed in the standard places, like /usr/lib and /usr/bin
with eventual configuration parameters in /etc/.

Replacing the building machine. I think Cmake is a good alternative
for complicated project like this. Actually, I already have started
with this. Just by studying the Allwmake scripts, I developed some
CmakeLists.txt to go down into src/ and build libPstream,
libOSspecific and libOpenFOAM. Until now the building process
arrives at a point it finds all header .H files below src/ that are
needed by these libraries. But it gets stuck as a variable 'scalar'
is not defined. Apparently, 'scalar' is defined in:
src/./OpenFOAM/primitives/vector/vector.H and in:
./finiteVolume/interpolation/surfaceInterpolation/limitedSchemes/LimitedScheme/N VDTVD.H
But these headers are not included into other .H or .C files of
these libraries. Does anybody have suggestions?

I am aware that implementing these changes is a very ambitious
project. Any help would be welcome.

Sincerely, Gerber

[lin]

Hi,just some points from my view point.

1.Compiling OF is quite straightforward if one follows the readme file,most problems I see during compiling is either because the user is new to linux,or not follow the readme file.

2.It's easy to install paraview from apt command,but in order to get best from it to use OF,one still need to compile it from scratch with the capability not in the official release.

3.I would more like OF in a separate directory,not in the standard system places,like /usr/bin, because it mess up the system.

[zeliboba]

hi Gerber

I fully agree with you, OF should have a better build system. I was thinking to do something similar, but unfortunately I have very little time for it. but I could try it on different linux installation to ensure portability.

OF has quite strange way of including headers, please see http://www.cfd-online.com/OpenFOAM_D...es/1/9205.html basically you can find proper include file in Make/option. I have limited experience to incorporate include path into source files (made an ugly script), if you are interested, please let me know.

you can also look at http://freefoam.wiki.sourceforge.net/ there is an attempt to build OF-1.4.1 with cmake (I did not test it unfortunately). If you can make something similar for OF-1.5 it would be perfect! I'd suggest to create a script for conversion wmake files to CmakeLists.txt instead of doing it by hands, so the next releases and other additions from openfoam-extend can be integrated easily.

good luck!

to linzhenhua:

1. OF compilation IS NOT straightforward, just look at the amount of message on the forum:

# Running / Solving / CFD [13792]
# Installation [3429]
# Meshing / Mesh conversion [2719]
# Post-processing [2092]
# Preprocessing / FoamX [1407]

installation topics take second place after CFD itself, it is more then pre- and post-processing altogether. is it ok from you point of view? installation should not be a pain even for not experienced user, most of well written software can be installed by something like "./configure && make && sudo make install". not experienced user wants to use software, not to struggle with its installation.

2. what capability do you exactly mean? OF reader? you can have it independently using patch, for example gentoo have it. btw paraview is not the only visualization software (and IMHO not the best one). you should have a possibility to switch it off especially when it causes problems, it is OPTIONAL feature.

3. how can /usr/lib/OpenFOAM directory "mess up" you system? an example, please.

I have plenty of them for the current installer: inconsistency in OF utility names mess it up (R is executable for R statistical language, not for Reynolds stresses). different compiler version used for OF mess it up (system gcc 3.4.6 compiler is not accessible after sourcing ~OpenFOAM/etc/bashrc and you cannot compile anything for the system). change of LD_LIBRARY_PATH (made by ~OpenFOAM/etc/bashrc) mess up the system. OF installation in every user directory on multiuser system (UNIX is multi-user, you know?) mess up the space. do you want more examples how OpenFOAM can mess up you system with its current installer?

[grtabor]

Maxim,

If you have multiple users using OF, you don't need to put the installation in each user directory. Create a separate "foam" account (I put it in /opt), install it there, then point everyone's .bashrc file at the configuration scripts in the central account.

I do agree that the installation can be complex. Another make system (eg cmake) would make it easier to compile the library. I will say though that wmake is much easier if you want to write your own codes within the OF framework.

Gavin

[lin]

Hello,Maxim
Thanks for your reply.Some of my opinion.
1.about the installation.I'm a new user,but the with one command I could compile openfoam,it's quite easy. Your statistics could not persuade me. We could not neglect the developer's effort during the development of OF.For old versions ,there may be some problems,which I am not sure.But for the OF 1.5 version I have tried,it's straightforward.At least for the 1.5 version installation problems I could remember in the email list,nearly all is either caused by the users not following the readme,or they do not have certain packages installed in the system.These kind of problems will also happen with the "configure" and "make" methods.So your statistics may be true for the whole OF versions,from the first to 1.5,but not for 1.5. Especially for OF1.5,except the two above aspect,how many posts left?

2.For paraview,I guess the patch with OF1.5 is up to date,though paraview itself could also manage OF format,also for Visit.

3.Base on the fact that generally no other software will use OF files,I would like to keep it as a separate directory,while not in the system directories.In my systems,all files in /usr/bin /usr/lib etc are managed by the package management system,such as rpm.

For the gcc problem.I do not add OF bashrc in my .bashrc file.I only source it manually in the shell I want to use only for OF.

For multiuser problem.In fact what I do ,is I do not install OF in the home directory,but in /opt ,and then link it to my home directory.

[zeliboba]

Gavin,

what is the point to put OF in /opt instead of /usr/lib and having separate account for OF?

I work quite a while with OF but still cannot understand advantage of wmake comparing to make. IMHO it only introduces additional level of complications and creates a source of various problems.

[zeliboba]

linzhenhua,

please note, you are talking about only your experience. you probably tried to install OF only on your desktop with recent linux distribution. I'm talking about about generally accepted practice for source packaging and portability. that is why I refer to statistics and to my experience of OF installtion on various UNIXes (linux is not the only, as you probably know) both on desktops and cluster. I'm talking about package management and creation OF package for different UNIXes. why to have all these complications (/opt directory, symlinks etc) instead of making normal package and use package manager for managing OF?

If it works for you it does not mean that installer works for everyone. If it works for you, just go ahead and use it, but do not try to convince others that installer is good enough. it is not good enough, believe me, there is a room for improvement.

btw manual sourcing of OF bashrc does not work on cluster, when you run jobs with MPI

[grtabor]

Maxim,

Your original message sounded like you were unaware of the suggested method of installing OF if several people were using it. I was merely trying to point out that there is a method of doing this. Granted, its unusual - as my local sysadmin keeps explaining to me! but it does work after a fashion. My choice of /opt rather than /usr/local or /usr/lib is just a personal preference.

wmake is good for compiling OF codes within the library, if everything is set up correctly - basically because everything is hidden; all you generally need to do is to edit the list of files and type wmake (or wclean if you want to be really certain). make/cmake scripts are generally much more complicated and would probably be difficult for a general user to work through for simple tasks. I am prepared to believe that there are better ways of generating and/or installing the base library however (.rpm packege for example?)

Gavin

[olesen]

I second Gavin in his opinion. Wmake is extremely good at hiding all the build details. For a new application or library, just create the "mkdir Make" and add two files.
Make/files just lists files to be compiled and the target (EXE= or LIB=).
Make/options contains the include paths (EXE_INC=) and the library link options (EXE_LIBS= or LIB_LIBS=).

Starting with OpenFOAM-1.5, almost all of the ThirdParty software has been stripped out of the main tree and placed in its own area. This certainly helps isolate which part of the build might cause problems (it is generally not the OpenFOAM source itself though).

I don't see much advantage of packaging OpenFOAM via rpm or whatever. If I make a change to the library, or just update from git for a bugfix, I really don't relish the idea of re-packaging OpenFOAM once again and then redistributing it across 30 machines. Sticking with an NFS-share is much more convenient - even if there is a potentially small performance hit at startup.

Packaging for a single machine, on the other hand, could be convenient for new users. It does, however, contain the danger of not being up-to-date with the latest bugfixes. Besides which, since OpenFOAM is "The Open Source CFD Toolbox", I would expect users should be building their own personal applications anyhow.

[olesen]

Maxim,

btw manual sourcing of OF bashrc does not work on cluster, when you run jobs with MPI

Interesting. I assume that you are using openmpi, but which shell and queuing system are you using? I've tried it with bash and at some point with ksh and had no problems. I am using GridEngine 6.1u3 and do *not* have OpenFOAM sourced from my ~/.profile, or ~/.bashrc - instead I source it in my job script itself. The openmpi starter for GridEngine invokes "qrsh -inherit", which correctly redistributes the environment during startup.

Here is small code snippet from my job script. The '%{...}' tag is dynamically replaced before the job script actually gets sent to the queuing system:

# ---------------------------------------------
# OpenFOAM (re)initialization
FOAM_INST_DIR=%{WM_PROJECT_INST_DIR}

sourceFoam=false # fallback command

for i in \
$HOME/.OpenFOAM/%{WM_PROJECT_VERSION} \
$HOME/.OpenFOAM \
%{WM_PROJECT_DIR}/etc \
;
do
echo "check $i/bashrc"
if [ -r "$i/bashrc" ]; then
sourceFoam="$i/bashrc"
. $sourceFoam
break
fi
done

if [ "$sourceFoam" = false ]
then
echo "(EE) cannot find appropriate OpenFOAM bashrc"
exit 1
fi

[gerbervdgraaf]

Thanks to all you all of for having this discussion.

To Maxim Loginov: thanks for the directions you gave as I was not
aware that cmake has been tried before.

Mark Olesen: I agree, sometimes it is a problem not having the newest
release or bugfixes when using a library or program from binary
repositories. In that case, on a Debian system for example, there is
the security patch system or you can rebuild the package by yourself
much more easely: You'd use the "apt-get build-dep source openfoam',
This will download OF source and all the library and headers which are
needed to build the OF binary. Then, you may eventually modify/update
the source and build the new package with "dpkg-buildpackage
-rfakeroot -us -uc openfoam". This is a very standardized method. Once
you know it for OF, you know it for all >20.000 packages of the Debian
system. I admit, I am a bit towards Debian, but the same would hold
for its derivatieves (Ubuntu) and probably similar technique for .rpm
based systems (Red Hat, Suse).

The CmakeLists.txt scripts may include other files, like those
containing the .H and .C to be used for building a library. As an
example: I slightly modified the src/OpenFOAM/Make/files, renamed them
to src/OpenFOAM/files.cmake and used them in
src/OpenFOAM/CMakeLists.txt. This was very easy to do.

I think it would be vey profitable if OF could be installed and used
following some standards, for example the Linux Standard Base
(LSB). System administrators would be delighted!

Some other idea I'd like to share:
I often have to look up which program has to be invoked to perform a
special task, as the naming of the programs often is not
straightforward and minor/capital letters do not help either (which is
not standard on a Unix platform, as well!). So also it might be a good
idea to change these program names. A common practise is to start all
programs with a specific prefix, for example of_. So blockMesh
might be changed to of_blockmesh etc. This helps as there are shell
environments (like bash) that display all programs starting with of_ when
invoking of_<tab>. This helps a newbie and someone who hasn't used OF
for a long time. Eventually, symbolic links may be created to the old
naming, so everybody will be happy. Just a suggestion.



Still my initial question, how to get the "scalar" variable properly
defined in the libraries has not been answered, yet. More questions to
come, probably.

Gerber

[olesen]

But it gets stuck as a variable 'scalar'
is not defined. Apparently, 'scalar' is defined in: src/OpenFOAM/primitives/vector/vector.H

In my copy, vector.H includes "scalar.H" which defines scalar as a typedef of floatScalar or doubleScalar (depending on the requested precision).

See: primitives/Scalar/scalar/scalar.H
Presumably your new build system did not request single precision (SP) or double precision (DP).

[gerbervdgraaf]

No, it does not. This are things I will have to learn, yet. Where is this (and other settings/macoros) defined when using wmake? Thanks a lot.

[olesen]

Where is this (and other settings/macoros) defined when using wmake?

It seems you are somehow missing the settings in etc/{bashrc,cshrc} - I'm not sure how any of your OpenFOAM system is working. Maybe you should re-install, something is horribly wrong with your setup.

[zeliboba]

Gerber,

take a look at wmake executable, it is simply bash script.

short summary: (almost) all includes in source code are written without path like "#include scalar.H", in order to find the path wmake first searches in ./lnInclude and then in -I directories in Make/options file. in discussed case it looks in src/OpenFOAM/lnInclude then in -I directories from src/OpenFOAM/Make/options.
I suggest you to change #includes, it will make you life much easier.

[zeliboba]

Mark,

~OpenFOAM/etc/{bashrc,cshrc} only sets up environment variables for wmake, even if you do not use wmake, you can compile and use OF without problems. wmake is simply wrapper to make and you can roll out Make/options, Make/files and OpenFOAM-1.5/wmake/Makefile to normal Makefiles in every directory and use make. no magic.

[olesen]

Thanks for the info Maxim, but it was (mostly) already clear to me how wmake works under the hood. And yes, I know that the precision specification can also be passed through to cmake with something like this:

ADD_DEFINITIONS(
-D$ENV{WM_PRECISION_OPTION}
)


What I admittedly don't understand is why an automated build requires replacing wmake at all. Some programs work with a combination of ./configure, make, make install whereas OpenFOAM uses the wmake, wclean and some Allwmake scripts and leaves the source where it is.
Would it not be simpler to adjust to packaging process to use the scripts provided by and maintained by OpenCFD? Or are the packaging systems in question so terribly inflexible?

[zeliboba]

Mark,

I do not think wmake should be removed at all just because of backward compatibility reason, it can probably coexist with alternative build system, but definitely some changes have to be made. I prefer to distinguish "build system" (make, wmake) and "configuration system" (cmake, autotools). there are several reasons, why not to use wmake wrapper:

1. it is not flexible. one cannot simply copy any directory from source to another location, change something in code and compile it. with recursive makefiles it is possible.

2. it is not reliable. wmake, wclean etc are separate scripts, when make change one of them, other scripts should be checked for compatibility also and tested. in fact there is a bug in one of the scripts in OF-1.5 release which makes it unusable. creation configuration tool around wmake increase the chain and thus make it less reliable.

3. it's convenience is doubtful. there is no single command to clean source tree like "make distclean" (or I miss something?). one have to learn how to use it, there several messages on the forum just because of this. the worst thing that wmake and Co. usage have nothing in common with other tools.

4. it makes code less readable and its analysis more difficult. "hiding details" also does not help to debug.

so why to have all this complexity? for me wmake is nothing more then reinvented wheel with no good features, but I do not intend to convince anyone to stop use it. as I said before: if you like it, just use it, why waste time in this thread?

[olesen]

Hi Maxim,

Your point 1:
Copying a directory somewhere else and changing things is no problem. I do this, for example, if I want to use one of the standard solvers but with a minor change. Here I would change the EXE= target though, since I want my version to land in my user area rather than affect the site installation or break things for another user.

Your point 2: which script is buggy and "unusable"? Have you reported the bug? Do you have a suggested fix?

Your point 3: don't any of "wclean all" or "wcleanAll" etc. work?

Yout point 4: my intend is not to waste bandwidth, but to maybe to clarify where misconceptions about wmake may exist. Your tone is unwarranted.

[zeliboba]

Mark,

1. try to implement new derived boundary condition or equation of state and you'll see the difference.

2. I do not remember. no. no. --- I do not interested in this tool.

3. just try them and you'll find out the answer.

4. hopefully you achieved your goal.

I really do not want to continue the discussion, there is no point. you are happy with wmake and OF packaging, I'm not. you do not want to change anything, I want.