CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM (
-   -   The OpenFOAM extensions project (

mbeaudoin September 10, 2007 10:42

We would like to draw your att
We would like to draw your attention toward an ongoing community effort called "OpenFOAM extensions" hosted on SourceForge ( ).

The goal of this project is to open the OpenFOAM CFD toolbox to community contributed extensions in the spirit of the Open Source development model.

This project is a Subversion site for developers and researchers for easily sharing code and collaborating on new ideas with OpenFOAM.

Highlighted objectives include:
  • A source code OpenFOAM repository, up-to-date with validated bug fixes to the current release
  • Application and library contributions from Open Source developers
  • Porting fixes and extensions for OpenFOAM on Windows and, coming soon, for OpenFOAM on Mac OS X
This project also conveniently offers the fully exploded, up-to-date and patched-up version of OpenCFD's OpenFOAM releases, starting with release 1.4.

Please note that the "OpenFOAM extensions" project is not a replacement for the OpenCFD release of OpenFOAM.

As of now, the "OpenFOAM extensions" project is offering the following playgrounds under the Subversion main /trunk directory:
  • Core : A complete development version (maintained by Hrvoje Jasak) with extensions to the current OpenFOAM release. This version is called OpenFOAM-dev.
  • Forge : A sorted collection of utilities, solvers, libraries and similar tools. These utilities have been peer reviewed and in general should be in a stable state and compatible with the current version of OpenFOAM
  • Breeder: Similar to the Forge, but without the peer review and probably unstable. Stable utilities from this branch may by moved to the Forge branch, subject to peer review of the source code and functionality.
Please refer to the following documents for more information: As for any community driven Open Source project, contributions from all OpenFOAM developers and researchers are most welcomed.


Martin Beaudoin
Bernhard Gschaider
Håkan Nilsson

hartinger September 10, 2007 11:55

interesting, very interesting,
interesting, very interesting,

hopefully you guys get it off the ground

good luck

gschaider September 10, 2007 12:17

Hi Marcus! That depends on
Hi Marcus!

That depends on you (amongst others)


msrinath80 September 10, 2007 14:22

Hi all, After discussions w
Hi all,

After discussions with my supervisor, I have decided to start my PhD coding work by modifying interFoam to:

a) Properly resolve the moving contact line problem (when you have a two fluid interface meeting a solid boundary) either through a slip B/C or something equivalent.

b) Create a solid domain (with no degrees of freedom restricted) so that I can account for rigid body dynamics coupled with fluid flow. The objective is to study the attraction/repulsion of solid particles floating at a two-fluid interface. I can either move the mesh for this case OR use a fictitious-domain like algorithm on a fixed eulerian mesh.

If everything goes according to plan, I should have a working prototype within the year

hani September 10, 2007 15:11

Hi Srinath, I hope that you
Hi Srinath,

I hope that you will consider Openfoam-extend as your Subversion repository.

Openfoam-extend makes it possible for other developers to contribute to your project, and you will contribute to the OpenFOAM community.

Good luck!


msrinath80 September 10, 2007 15:15

Sure. First I need to learn to
Sure. First I need to learn to use Subversion. Any pointers?

hani September 10, 2007 15:26

Just take your time and read t
Just take your time and read the information on the links in this thread. You can find all you need there, and it will help you organize your project nicely. We have actually made an effort to help you get started.

If you find something that is not clear or does not make sense, please tell us and we will try to improve the guidelines.


msrinath80 September 10, 2007 15:35

Apologies. I should have gone
Apologies. I should have gone through the links before posting. I'll post a message if I face problems. Thanks for your help!

fra76 September 13, 2007 08:14

Hi all! I'm convinced that su
Hi all!
I'm convinced that subversion is the better tool for this kind of projects, but the proxy I'm behind doesn't agree with me...
Is there any chance to put a tar of, let's say, /trunk/Core/OpenFOAM-1.4.1-dev in the Donwload section?
Maybe it won't be the most updated and stable development release, but it can be useful.

gschaider September 13, 2007 08:29

Hi Francesco! @the proxy pr
Hi Francesco!

@the proxy problem: Subversion uses HTTP (or in the case of sourceforge HTTPS) as its network-protocol. So in theory any proxy that alows you to browse the net should allow access to the repository. Wht kind of problem are you experiencing.

Making downloads available only does make sense for snapshots (in other words: sub-directories of the /tags-part, but never for the /trunk). Making tarball from this is a possibility. We'll discuss it.


fra76 September 13, 2007 09:04

Hi Bernhard! I've try to co
Hi Bernhard!

I've try to configure .subversion/server file, but without any success. I'll contact my IT department...

However, making a tar of a snapshot is a good idea, in my opinion.


mbeaudoin September 13, 2007 09:06

Hello Francesco, Could you
Hello Francesco,

Could you be a little bit more specific about your proxy and your svn client?

The Subversion repository is accessible though the http and https protocols, so if you can browse secured or regular http web sites using https or http, your proxy should not be a problem.

Take a look at this entry in the Subversion FAQ, it might help:

Maybe your svn client is not configured for https?

Here is a couple of tests for you; what is the result of the following svn commands:

svn list http://openfoam-extend.svn.sourcefor...penfoam-extend
svn list https://openfoam-extend.svn.sourcefo...penfoam-extend

You should get this list of directories:


hoogland September 26, 2007 19:35

I have been keeping an svn rep
I have been keeping an svn repo for large parts of OF for a while now, but have two problems and I'm interested in thoughts/suggestions:

* For source code: compiling/recompiling within the OF tree can change its structure slightly (i.e. creates new dirs such as "linux64DPOpt/" to hold compiled code). This requires inconvenient/inefficient fiddling to update the repository. If you have a big recompile, its a nightmare. I'm probably an intermediate svn user, not an expert, so there may be better workarounds.
* For cases: solution dumps (e.g. say, time directories) are placed inside the case directory, with the source files. Solution dumps can require large amounts of disk space and since a lot of the data produced is often not used later (e.g. you can sometimes generate gigs before you get to the "juicy stuff"), keeping it within the repository goes in the category "bad idea".

What you want to do is keep all your (small) source code and case files in the repo, but keep (most of) the solution data and compiled code outside it.

As an example, I did this for the case dirs successfully with Fluent, but of course could not with the source code. I'd have a case dir:


I'd have a run script that would make a commit, figure out the next rev number Rev, create an svn copy of the Case/ dir in the branch dir with a rev stamp


then cd to this Case-Rev/, make any mods to the run files, and run the job from this branch. It would also make a copy of Case-Rev (svn export) outside the repo, in say


and send solution dumps there. In this way, runs are more easily/quickly identified by svn rev numbers which makes looking back through the log more effective, and the source and data are separated. If you lose the external data, you have a precise snapshot of the source scripts needed in repo/branch/ (I had a little restart script too).

With OF you'd probably modify foamJob to do this, but ideally in addition each solver would give you the option of where to send solution dumps. After all, you already tell them both the root dir and case dir, we're just talking an extra (maybe optional) dir argument.

The OF source code is more difficult. I can think of a few different ways but they are all mostly messy, especially since you would have to regularly update the entire tree with OpenCFD releases, and they don't use a CVS.

In my experience using a CVS like subversion is a _very good_ idea for CFD cases yet alone basic code, but I'm looking for constructive ideas on how to manage these problems with OF in retrospective way.


mbeaudoin September 27, 2007 00:48

Hello Jason, For a starter,
Hello Jason,

For a starter, are you familiar with the Subversion ignore patterns, both global and per-directory lists?

If not, check out the section "Ignoring Unversioned Items" from the on-line book "Version Control with Subversion" re

Using the right ignore patterns, you could make sure to only keep the right information in your svn repo, even though your working copy (source code or cases) directories are a mix of source files and object files or time directories.


hoogland September 27, 2007 00:57

Martin, Nice, I thought the

Nice, I thought there might be something like that I hadn't heard about. Will check it out.

Whats your procedure for updating a new OpenCFD release into your svn repo?


gschaider September 27, 2007 04:49

Hi Jason! @Updating a relea
Hi Jason!

@Updating a release into SVN: It used to be a nightmare, but now I have a script for that. The scripts are found in the /admin/scripts section of the Repository. There is a README-File there and I'll quote from that:

The way I do it now is the following (I'll give as an example 1.4.1 and 1.4.2):

1. "svn cp OpenFOAM-1.4.1 OpenFOAM-1.4.2" to create the new directory (in the repository)
2. Go into OpenFOAM-1.4.2 and run there. This removes everything but the directories and the SVN-information
3. Untar the tar into that directory (use --strip-components)
3a. Remove the "external dependencies" (MPI, mico etc) from the src-directory. They will be dealed with later
4. Run the script there. This basically goes through the directories and schedules any new files for addition. Files that are missing for removal and removes empty directories (I used to do this by hand, it was a pain in the ....)
5. Do the "Mother of all commits" (like Sadam H. would have said). It takes quite some time
6. Add new stuff to the /thirdparty-branch and modify the svn:externals accordingly

Hope that helps. The scripts are not exercises in elegance, but they do their job.


hoogland October 9, 2007 09:33

Thanks Bernhard. A general
Thanks Bernhard.

A general update, documented on the wiki.

I found it takes a little bit getting to grips with svn's implementation of ignore patterns at first, but its not that hard to set up. I've set up my svn (working copy) source tree(s) as simultaneous build tree(s). Also have cases in a separate repo, works well.

No more lost/separated source/data, easy diff/revert between past changes, simple/easy documentation of changes. Can propogate changes and recompile across n machines basically in the time (approx) it takes to do one. To say nothing of the collaborative benefits. Perfect!

Thanks for the tip!


All times are GMT -4. The time now is 07:27.