Hi,
I am an enthusiastic GN
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 |
Hi,just some points from my vi
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. |
hi Gerber
I fully agree wit
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? |
Maxim,
If you have multiple
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 |
Hello,Maxim
Thanks for your r
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. |
Gavin,
what is the point t
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. |
linzhenhua,
please note, yo
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 |
Maxim,
Your original messag
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 |
I second Gavin in his opinion.
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. |
Maxim,
btw manual sourcing
Maxim,
Quote:
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 |
Thanks to all you all of for h
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. http://www.cfd-online.com/OpenFOAM_D...part/happy.gif Gerber |
But it gets stuck as a variabl
Quote:
See: primitives/Scalar/scalar/scalar.H Presumably your new build system did not request single precision (SP) or double precision (DP). |
No, it does not. This are thin
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.
|
Where is this (and other setti
Quote:
|
Gerber,
take a look at wmak
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. |
Mark,
~OpenFOAM/etc/{bashrc
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. |
Thanks for the info Maxim, but
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? |
Mark,
I do not think wmake
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? |
Hi Maxim,
Your point 1:
Co
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. |
Mark,
1. try to implement n
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. |
I am starting to get the pictu
I am starting to get the picture: many MACRO's or environmental settings found in etc/, like WM_PRECISION_OPTION, will have to be included in CmakeLists.txt as options and used when configuring and building. Others, like WM_PROJECT_* and WM_COMPILER_ARCH, are probably not necessary as cmake will figure it out by itself. Experience will learn.
Of course, I did not change the environmental settings as recomended in the README during my attempts to configure and build with cmake. Because these changes are necessary for wmake et al, but not for cmake. At least that is my goal. That's also why I get stuck. But I knew this in forward and has to be happen during the development of this building machine. I hope I will find the time to work it all out. When it is working up to an acceptable level I will be back at this forum and hope to issue the cmake configuration system somewhere (at freefoam of SF.net, for example). Of course, anybody can pick his taste, that's why it is OSS. But there is still a very long way to go. Back to work on developing now. In case of any technical questions I'll be back here as well, of course. Thanks to all of you for this discussion. Gerber |
People that want a stable operating system never put third party software in the system directories. The traditional place on linux is /usr/local for relatively small packages or /opt for larger packages where one is going to control the environment. Because openfoam has unusually strong dependencies on particular versions of compilers, qt, paraview, etc... then /opt is the most logical place for it as recommended by others earlier.
Openfoam is written by people that want to use wmake. It is perhaps not unreasonable to speculate that a degree of weirdness/awkwardness may be considered desirable by those that have written and are continuing to write the bulk of the software. Using a normal build system like cmake is an obvious thing to do, has been done before and was not picked up the openfoam developer/s. Starting out by pulling in a direction the project does not want to go may be unwise. Of course, this is not a problem if you are performing the conversion as a learning exercise for yourself but I would suggest having few expectations beyond this. And by the way, I would suggest that the quickest and most reliable way to generate the cmake files is by modifying the wmake scripts. |
Hi Andy,
I attended the OF Stammtisch in Stuttgart. Hrv gave a Presentation there. He said has the opportunity to go to seattle and Port OFoam on Windows with the Support of Micro$oft. He said when he has made the Port to M$, he would like the support of the Community (like the FreeFOAM guys) and give cmake a chance. greets elvis |
Perhaps I have misunderstood the point you were making but how would Hrv adopting cmake for his extension to openfoam change the current situation in a significant way? Surely what is important is what is used by the main release of openfoam?
(Are we replying to a current or an old thread? Gerber's post seems to be dated in 2008 even though he joined in 2009.) |
All times are GMT -4. The time now is 09:04. |