[olesen]

I've started a new thread with the first bits for updating pieces of the new OpenFOAM-1.5

In the interest of organization, it would be useful if everyone else posted their stuff on this thread as well.

To kick things off, attached are boundary conditions that reads the old massFlowRateInletVelocity boundary condition (with the 'massFlowRate' entry), but writes the new 'flowRateInletVelocity' boundary condition.
This helps with restarting from existing models without needing to edit anything.

After unpacking the files, you'll need to modify the src/finiteVolume/Make/files and re-make the finiteVolume library.

massflowrateupgrade.tar.gz

[hjasak]

We'll check all the code into SVN, where it can be operated on easily. I've also got some fixes - let's keep them for the moment until SVN for 1.5 becomes operational.

Hrv

[olesen]

I guess checking everything into svn is 'okay', but when I tried looking at the svn repository, it wasn't simple to distinguish between 'real' changes (patches, extensions) and trivial changes.

As the first questions in the forum showed, the name "OpenFOAM-dev" seems to cause some confusion. Since the svn is initially based on the official OpenCFD release, followed by a bunch of changes and extensions, perhaps terming it "OpenFOAM-extend" would be more appropriate.

[hjasak]

There are several lines in the SVN. First, there is the "undisturbed 1.4.1" version, then there is a 1.4.1 patched version and finally there is a version that used to be based on 1.4.1, with various developments from the Open Source community. This is necessary for several reasons, one of which is the way we need to deal with patches. We are going to do the same with the 1.5 dev line and move all bug fixes and community developments from the old repository to the new one.

I would not say that the SVN is "based on the OpenCFD release" and there is certainly nothing "official" about it. In any case, it is up to each one of us to contribute and make OpenFOAM more useful.

My biggest problem is that it is currently impossible to have only one version including everyone's work, because of lack of inter-release updates, bug fixes and community contributions and this is why things are the way they are now.

I am hoping this will be sorted out in the future, with some good will on all sides.

Hrv

[bertram]

Hello Hrvoje,
so far I have been quite happy with the 1.4.1-dev version, and I don't plan to update to 1.5 within the next few weeks.

But only to avoid confusion, could you please explain whether the 1.4.1-dev contributions on top of the "undisturbed 1.4.1" have been mostly included in the "undisturbed 1.5"?

If not, will we still be able to use the 1.4.1-dev contributions with 1.5?

Bertram

[hjasak]

Hello,

I have tried to pass on contributions from 1.4.1-dev to OpenCFD for the inclusion to the 1.5, but with no response - which is precisely the point. If there were a way to add contributions to an unified version from the open community, there would be no need for all this confusion. From what I hear, I am not the only person in this position. Even further, within 2 days of release both Mark and myself have bug fixes and there is no way to formally lodge them and make available to the community in a reasonably comfortable manner. This is in fact why we started the SVN and -extend effort in the first place.

The 1.4.1-dev will remain compatible with 1.4.1 and all its features will be re-based to 1.5 (no problem there). Thus, once the merge is completed, we will carry on with 1.5_patch and 1.5-dev, both including all contributions from 1.4.1_patch and 1.4.1-dev, respectively. Thus, in 2-3 weeks, you should be able to seamlessly switch to 1.5 line (patch, dev) with no loss of code or capability.

Hope this helps,

Hrv

[olesen]

within 2 days of release both Mark and myself have bug fixes

Just for clarification (before everyone races to download and compile what I had posted) - the modified massFlowRateInletVelocity boundary condition is *not* a bug fix. THe better description would be a 'hack' since it breaks the normal type system and reads massFlowRate, but write flowRate.

It is merely a convenience that you may or may not need. The complimentary hack would be a flowRateInletVelocity for OpenFOAM-1.3, OpenFOAM-1.4 that would read a flowRate BC and write a massFlowRate, but compatibility in every possible direction starts getting quite messy.

As to the svn, maybe cross repository modules would be good way to disentangle 'pristine', 'patch' and 'extend'.

[egp]

Despite some statements to the contrary http://www.cfd-online.com/cgi-bin/Op...how.cgi?1/8316, I would add that, in my opinion, the release notes for 1.5 are completely inadequate. They do not document the detailed changes made between 1.4.1 and 1.5, and therefore do not enable users to easily port their custom applications. Hopefully it will require only minor surgery.

Eric

[msrinath80]

Hi Eric,

In their defense I would like to point out that those are 'Release notes' as opposed to a detailed 'Changelog'.

Perhaps a request for the Changelog on this forum would help.

[olesen]

Could we please retain the original intent of the thread, namely posting hacks, tips & tricks etc for OpenFOAM-1.5