[carsten]

Dear colleagues,

currently I'm a little concerned about the fact, that bugfixes from 1.5.x don't make it into 1.5-dev. I just stumbled across a problem with "pressureInletUniformVelocity", which doesn't work correctly in 1.5-dev if executed in parallel. As I found out, this was fixed in 1.5.x in February and the fix didn't make it into 1.5-dev until now (checked out at 20.5.).

So I fear that there are more errors, which are fixed in one codebranch and not in the other. I would be very glad if the branches would be closer to each other again ...

Okay, here is the bug report:

Codebranch 1.5-dev:

in file src/finiteVolume/fields/fvPatchFields/derived/pressureInletUniformVelocity/pressureInletUniformVelocityFvPatchVectorField.C

replace

operator==(patch().nf()*sum(patch().Sf() & *this)/sum(patch().magSf()));

with

operator==(patch().nf()*gSum(patch().Sf() & *this)/gSum(patch().magSf()));


Have a nice day,

Carsten

[henry]

1.5.x on our git repository is developed and released by OpenCFD. We keep our development line, which also includes all 1.5.x bug-fixes, internal until it is stable enough for release and we can support the large numbers of users of it. Any other repositories of OpenFOAM you might find are not setup by OpenCFD and we cannot take responsibility for them: we release OpenFOAM open-source so other people can create repositories of the sources if they wish but they should make it clear when they do this that OpenCFD are not responsible for them.

So if you would like to take advantage of our patches and bug-fixes of our 1.5 release please use 1.5.x.

Henry

[carsten]

Thanks Henry,

got it.

I previously assumed that 1.5-dev was some kind of official development branch ...

Thanks again,

Carsten

[hjasak]

I am happy to confirm that OpenFOAM-1.5-dev repository has got absolutely nothing to do with OpenCFD, who are not involved in its development nor have they chosen to contribute.

I am formally in charge of this development line, set up to allow community contributions into OpenFOAM and support for numerous OpenFOAM features not supported or developed by OpenCFD. As you know, between versions 1.0 and 1.5, the OpenCFD line has lost about 40% of functionality (they are not able to support it or keep it in function); as the author of a substantial part of this code, I take it as my responsibility to keep it alive.

Further to this, there are new features and implementations unrelated to OpenCFD which are contributed by various groups and individuals and are include in the -dev line. Most important features here (and I am sure I will forget at least a dozen) are
- new linear equation solvers, with substantial performance increase (described in CFD Canada 2007 conference papers)
- working support for topological changes, eg. sliding and layering
- tet-FEM based automatic mesh motion
- finite area method and liquid film support
- improvements in ordinary differential equations solvers and related basic polyomial support
- a suite of dynamic moding mesh classes
- IC engine-related developments (contributed by Politecnico di Milano)
- viscolelastic flow solver by Jovani Favero
- solid stress analysis, contact stress, plasticity, crack propagation, fluid-structure interaction (UC Dublin)
- 6-DOF solid body motion solvers, including 1-phase and multi-phase free surface VOF solvers
- development line of level-set methods
- improved and updated error estimation and residual tracking tools
- contribution of python bindings for the library (to the level of physics solvers)
- GGI, cyclic GGI and partial overlap GGi implementation with full parallelisation
- (in development): block-matrix and block solver support
- (in development): immersed boundary method (Uni Zagreb)
- additional tutorials, utilities and top-level solvers

and others (sorry if I've forgotten yours). Further to this, the control of the development line is performed by an open committee, with several groups contributing and guiding the development. As a part of the effort, automated test loops and validation cases are in preparation by Special Interest Groups (SIGs) - you will be able to hear more about this in Montreal next week.

Various bug fixes and similar from the 1.5.x git repository are incorporated as things develop, making sure we preserve the inter-operability form the user's point of view.

In an ideal world, there would be a single development line; however, my effort on this over the last 5 years have proven fruitless. In any case, some competition is alwas a good thing.

Hope this helps,

Hrv

[albcem]

Hi Hrvoje,

I think many people including myself are generally confused about OpenFOAM's organizational structure. For instance, to this day I had thought there was one unified group streamlining the debugging, development and support efforts for all versions of OpenFOAM.

May be a brief document, explaining who is who and his role in relation to versions of OpenFOAM is appropriate. Else people will keep bugging the wrong people for the wrong reasons and turn them off along the way...

Cem

[bastil]

Originally Posted by hjasak

- contribution of python bindings for the library (to the level of physics solvers)

Coll was not aware of this? How to use it? is there some documentation?

Regards.

[olesen]

Originally Posted by carsten

I previously assumed that 1.5-dev was some kind of official development branch ...

Of course if the OpenFOAM-extend project actually called their version something like 'OpenFOAM-1.5-extend' or 'OpenFOAM-1.5-ext' it would all be much less confusing.
Why isn't that being done?

[hjasak]

Hello Mark,

I appreciate your concern for the health and well-being of the OpenFOAM-extend project. Why don't you write to the Committee and explain your reasons and confusion and we will consider your proposal. As a matter of fact, the Committee is due to meet today - if you are on the Workshop in Montreal, please come and join us.

Hrv

[olesen]

Originally Posted by hjasak

Why don't you write to the Committee and explain your reasons and confusion and we will consider your proposal.

That sounds great, but looking through the http://openfoam-extend.wiki.sourceforge.net, http://sourceforge.net/projects/openfoam-extend and http://openfoamwiki.net pages, there is no evidence of contact information for the OpenFOAM-extend Committee.

[mbeaudoin]

Hello,

I guess the best way to get rid of confusion is to inject more information into the system.

So indeed, we will add a lot more information on the OpenFOAM-extend Web pages (http://openfoam-extend.wiki.sourceforge.net/ ) in order to inform newcomers and experienced users about the nature of this user-driven collaborative project.

In the meantime, there were two rather complete presentations made about the OpenFOAM-extend project at the 2nd OpenFOAM Workshop held in Zagreb in 2007 (http://powerlab.fsb.hr/ped/kturbo/Op...Zagreb2007.pdf), and at the 3rd OpenFOAM Workshop held in Milan in 2008 (http://www.openfoamworkshop.org/08/i..._Gschaider.pdf).

A 3rd presentation about OpenFOAM-extend was presented this week at the 4th OpenFOAM Workshop in Montreal (http://www.openfoamworkshop.org/2009...itle=Main_Page). This presentation will also be made available online shortly.

As for contacting the people in charge of the project, please visit the following SourceForge.net page: http://sourceforge.net/projects/openfoam-extend , click on the button labelled "Details", and there you will see the list of the admins of the project.

These people are, in alphabetical order:

• Martin Beaudoin
• Bernhard Gschaider
• Hrvoje Jasak
• Hakan Nilsson

You can easily contact either one of us by Email by simply following the URLs on this Web page associated to the admin names.

We will make our best effort to provide as much information as possible on the main OpenFOAM-extend and to keep it up-to-date. In any case, please don't hesitate to contact us for more information.

And please note that the OpenFOAM-extend project is not affiliated with OpenCFD; OpenFOAM-extend is a community-driven project. So please don't bug them about stuff you have downloaded from this project.

Martin Beaudoin

[alberto]

Hi,

just my two cents. In my experience, and from the feedback I have from friends and colleagues using OpenFOAM, what is confusing is the spread of information: some information can be found on forums, some on the OF wiki, some on the sourceforge pages, something else on other websites.
This might not represent a problem for those who followed OpenFOAM since the beginning, and know it history, but for newcomers it is quite disorienting. So, I really appreciate the idea of starting to create a page collecting information about the -dev and -extend initiatives.

About -extend, I find it interesting for the community contributions that are not accepted by OpenCFD, but I think community contributors should try at first to have their contributions first accepted upstream, if OpenCFD offers this possibility (it would be interesting to discuss with them this possibility, if there is interest), which would add maintainance work on their shoulders. In this way, the contribution would be immediately available to the final user, without the need to look for it into repositories.

Moreover, I think those additional contributions should be, for what possible, thought as add-ons to the OpenCFD release, instead of requiring to deal with a separate release, which often results in managing two parallel OF versions, for various reasons.

As a side note, the validation initiative is very interesting too. Is some material on the topic already available? What kind of test-cases are being considered?

Best,

[gschaider]

Originally Posted by alberto

Moreover, I think those additional contributions should be, for what possible, thought as add-ons to the OpenCFD release, instead of requiring to deal with a separate release, which often results in managing two parallel OF versions, for various reasons.

Only two versions? You're lucky.

Seriously: if you're not very unlucky utilities usually compile with 1.5.x and 1.5-dev unless .... unless they are manipulating the mesh or use a feature not present in both versions

[alberto]

Originally Posted by gschaider

Only two versions? You're lucky.

Seriously: if you're not very unlucky utilities usually compile with 1.5.x and 1.5-dev unless .... unless they are manipulating the mesh or use a feature not present in both versions

Hehe, well two, if you don't need to go backward with the versions, but for now I didn't need this. However I find it already difficult to convince people to use OpenFOAM because of the learning curve, and telling them "oh for that feature you need to compile the -dev version yourself" does not help.

About "new-features as plugins/extensions", I was specifically thinking to some cases where this does not happen already, which are quite frequently those adding the most interesting functionalities. In particular the coupled solver classes, which I think are quite a widely needed feature for various applications (just started to look at them ), given that doing everything with iterative solvers is often very tricky, and sometime impossible. I'm not so sure it is easily feasible though and maintainable on the long run (feedback from devs? )

Best,

[mbeaudoin]

Originally Posted by alberto

As a side note, the validation initiative is very interesting too. Is some material on the topic already available? What kind of test-cases are being considered?

I presented a glimpse of what's to come at the 4th OpenFOAM Workshop in Montreal.

But this is work in progress and most certainly a subject for another thread. I will share more information in due time.

Martin

[alberto]

Thanks for the info Martin, I'm looking forward to see them. I don't want to be pushy, just curious: any estimated time?

Thanks,

[olesen]

Originally Posted by hjasak

Hello Mark,

I appreciate your concern for the health and well-being of the OpenFOAM-extend project. Why don't you write to the Committee and explain your reasons and confusion and we will consider your proposal.

Hello Hrv,
Sorry about taking so long to get back on this.

As you can gather from the start of the thread, the naming with the '-dev' suffix introduces more than some confusion since people generally expect it denotes the current development version (ie, a preview of what will come into the next stable full version). Similarly, if it used 'rc', they'd expect it denotes a release candidate.

Since the OpenFOAM-extend project is based on the standard OpenFOAM release as its upstream source and includes a number of differerent/improved/changed features, calling your source repository '-ext' rather than '-dev' would avoid any possible confusion ... without costing any extra characters to type. It would also be more commensurate with the project name OpenFoam-extend itself.

Another aspect that I feel to be vitally important: to properly utilize the OpenFOAM-ext version, the end-user must be able to identify the changes from the standard version and to decide which bits to use from which repository. At the moment, the continued use of svn essentially blocks this possibility. Without any common ancestors, it is completely impossible to merge the OpenFOAM-1.5.x git version with your svn version without encountering literally thousands of merge conflicts.

If the OpenFOAM-ext were also to use git (for example, like the FreeFOAM project is doing), it would not only be possible to pick individual combination of features from OpenFOAM-1.5.x, OpenFOAM-1.5-ext and FreeFOAM, but it would be possible to identify which bug fixes have been included in which version. Furthermore, the end user could use whichever repository and still be able to merge in the bugfixes from the upstream sources.

If you cast this into git terms, we are talking about making OpenFOAM-ext a git branch from the OpenFOAM-1.5.x git master, but maintaining this branch on sourceforge (or elsewhere) and not within the same repository. It would thus work exactly the same as FreeFOAM, except that I can merge FreeFOAM back into my sources. I can't do that with OpenFOAM-ext!

Presuably if you switched to git for managing the OpenFOAM-ext branch, it should also be possible to use git-rebase to graft the entire changeset onto a future OpenFOAM version, or simply use git-merge to update to the upstream changes.

When I discussed some of these points with Henrik earlier this year, it sounded like he'd be a good source if you need more information about working with git. In this case using git isn't just about a bit of technology (although it's a good bit of technology), but about promoting more transparency in the OpenFOAM-extend project and improving user choice.

cheers,

/mark

[henrik]

Dear Mark,

1) yes, there is confusion, especially among new users. But those who make an effort, can find the necessary information and tell them apart - one uses git and the other uses svn . Apart from regular discussions on this forum, the history and status of the OpenFOAM-extend project has been presented at every OpenFOAM workshop, see here for the latest slides

http://www.openfoamworkshop.org/2009...OAM_extend.pdf

I accept, that this does not seem to be enough and I can assure you that the OpenFOAM-extend project is working hard to remedy this.

2) You are raising the question of "What is the right version control system". I told you at the Stammtisch in Munich that the OpenFOAM-extend admins considered moving to git, but decided against it. The main reasons were: gits inability to check-out parts of the branch (needed for the SIGs), impact on existing users and higher priority of other projects. This decision will be reviewed at some point.

Since you regard "proper usability of OpenFOAM-extend" as vitally important, I suggest that you join the OpenFOAM-extend team and make a contribution by setting up a system that works automatically while covering the needs of its users.

In reply to the original thread:

The patch had been checked into GIT 24/4 and was committed into SVN on 22/5 whereas the thread was started 26/5. Since somebody needs to revisit the patches to avoid complications, I don't know what the fuzz is about and for the record:

The OpenFOAM-extend team tries to apply all paches from the git repository as soon as possible. If you find that this is not the case, please drop us a line - you know where to find us.

Henrik

[carsten]

Hi Henrik,

just a small correction for accuracy's sake:

The original fix was commited into GIT on 4th of February. I checked out the SVN version on 20th of May, more than three month later. As you correctly stated the bug was already fixed at the time of my posting (i apologize for not checking out every day, but OpenFoam is not my main business), but this doesn't help for the general problem of synchronization.

There have been several posts by people that seem to be more deeply involved in OpenFoam-development. Actually I hope that you will find a good way to manage further developments.

Happy computing

Carsten

[henrik]

Carsten,

yepp, you are right. One month was already a bit late. I agree that three and a half months are too much.

More importantly I did not re-read your original thread where you explain the situation.

Please do not stop kicking our butt.

Henrik

[olesen]

Originally Posted by henrik

2) You are raising the question of "What is the right version control system". I told you at the Stammtisch in Munich that the OpenFOAM-extend admins considered moving to git, but decided against it. The main reasons were: gits inability to check-out parts of the branch (needed for the SIGs), impact on existing users and higher priority of other projects. This decision will be reviewed at some point.

I don't know how the SIG stuff is being used, but it is presumably separate from the OpenFOAM core and thus could easily/safely reside in its own repository. In fact, it could continue to use the existing svn and the OpenFOAM-ext core could move out.

Since you regard "proper usability of OpenFOAM-extend" as vitally important, I suggest that you join the OpenFOAM-extend team and make a contribution by setting up a system that works automatically while covering the needs of its users.

Thanks for the invite, but committee-work really isn't my cup of tea.
If you are looking for ideas of using svn and git, there is of course the git-svn command itself, or I believe that raduko is doing something similar to build against a particular version of parrot - you might find some ideas there.

The OpenFOAM-extend team tries to apply all paches from the git repository as soon as possible. If you find that this is not the case, please drop us a line - you know where to find us.

But the point is actually that there is no easy way to determine which bugfixes from OpenFOAM-1.5.x have been applied. Or even which content has come from where.
An svn commit with "git updates" doesn't say anything. As a minimal I'd expect "updated to git commit XXXXX" for the bugfixes and "created from git commit XXXX" for the initial version.
Even so, there is still no easy way for the user to see if the bugfix really has been applied, other than finding out the hard way (as Carsten did).

/mark