0

For my master's thesis I am working with the open source CFD simulation tool OpenFOAM. For those unfamiliar with its structure:

You usually create a directory for each simulation case. This directory consists of a couple of sub directories, in which several ascii configuration files are stored. Those define the mesh, optiones for the solver, etc... depending on the complexity of your simulation, there can be quite a few settings in quite a few files.

Since it often needs some experimenting until you figured out a working setup, version controlling changes in these config files and being able to switch back to previous states would be very helpful. This basic functionality should be provided by every version control software.

I found this blog entry about using git to track changes to your OpenFOAM config files. After I set it up myself, I can confirm that git indeed works very well in this case.

However, the entry also talks about using branches for parameter variation withing a single case. Very often I need to create slightly modified copies of my cases, for example to examine the influence of different boundary conditions on my simulation.

Using different branches here is not enough, because I need to compare the results of the different modifications and each simulation therefore needs its own working directory!

My solution to this was to clone my original git-case repository for every modified case. But now it gets very cumbersome, as soon as I would like to make general changes to this "case family". Consider the following scenario:

  1. There is a "generic" case folder
  2. I create several clones of "generic", slightly modifying each case afterwards
  3. I realize that I messed up a setting in "generic", fix it and then would like all clones to be updated as well.

Since git doesn't allow "pushing downstream" (because the "generic" repo doesn't know about its "children") I would have to pull manually in each clone.

My ideal setup would look like this:

  • One repository for a family of cases
  • I have a "generic" setup for my case (most likely in the form of a "master" branch)
  • Changes in my "generic" setup will automatically be integrated into all modified (sub-)cases
  • When I need to run and compare several versions I can merely "outsource" them to separate working directories where there still automatically sync with changes to "generic"

In other words, unlike the original concept behind git (working on sub branches and slowly moving changes upstream to master), in my scenario the concept is more comparable to "inheritance of changes" like in object oriented programming.

Is this possible, or is there a way to get any closer to this than my current git setup which involves a lot of pushing and pulling? Since I am the only one working on this on a local machine, should I rather change to a centralized version control tool like subversion?

Update:

Thanks to the suggestions, I have made some progress. I found the git-new-workdir script to fulfill almost all my requirements concerning shared configuration files and "outsourcing" of working directories without having to push and pull all changes in between directories (I am also aware that this is already included as a git core function for more recent versions).

Concerning the "inheritance of changes"-part, I can cover most setups by letting all derived branches track changes in their local upstream branch. Merging could most likely be automated via post-commit hooks.

The only occasion where this falls short would be if a branch was derived by several "parent" branches. An example setup:

    modified geometry <--- generic ---> generic 2D  
               \                          /  
                \                        /  
                 > modified geometry 2D <

Am I right to assume that git can only manage one upstream branch for each branch and an automatic merge from two upstream branches is not possible?

Community
  • 1
  • 1
Niclas
  • 143
  • 6
  • A bit hard to understand so I might be wrong but if what you want is to have a similar set up that you can update on every branch of the repository, you can do that placing the common "configuration files" on a submodule. – PeCosta Nov 11 '15 at 02:17
  • Why don't you like git pulls to clones? I think you can even set (a cumbersome, yes, but still) hook in you main repo to automatically call git pull in clones on each commit in main. I think this will still require you to have several branches, but anyway most seems to be possible to automatize. – Petr Nov 11 '15 at 05:28
  • One way to accomplish what you want to do is to create the sub-cases as sub-folder into your general case, than use symbolic links to files in the generic case whenever you do not intend to change anything and instead copypaste the file if otherwise. Then commit always on the master branch so you keep everything coherent. However to this solution I still would prefer the multiple clones with multiple branches. remembering to pull and merge is not an issue from my point of view. – alexmogavero Nov 11 '15 at 11:53

0 Answers0