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 (http://sourceforge.net/projects/openfoam-extend/ ).

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:

• Project Web Site : http://openfoam-extend.wiki.sourceforge.net/
• Subversion archive: http://sourceforge.net/svn/?group_id=194890
• Subversion archive guidelines : http://openfoam-extend.wiki.sourcefo...ion_Guidelines

As for any community driven Open Source project, contributions from all OpenFOAM developers and researchers are most welcomed.

Enjoy!

Martin Beaudoin
Bernhard Gschaider
Håkan Nilsson

interesting, very interesting,
 

interesting, very interesting,

hopefully you guys get it off the ground

good luck
markus

Hi Marcus! That depends on
 

Hi Marcus!

That depends on you (amongst others)

Bernhard

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

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!

Håkan.

Sure. First I need to learn to
 

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

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.

Håkan.

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!

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.
Francesco

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.

Bernhard

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.

Francesco

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:

http://subversion.tigris.org/faq.html#proxy

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:
admin/
branches/
tags/
testing/
thirdparty/
trunk/

Martin

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:

repo/trunk/pathToCase/Case

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

repo/branch/Case-Rev

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

$HOME/data/fluent/Case-Rev

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.

hoogs

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" http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.props.special.igno 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.

Martin

Martin, Nice, I thought the
 

Martin,

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?

hoogs

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 clearOutRelease.sh 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 addAndRemoveFromRelease.py 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.

Bernhard

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!

hoogs