SIG Turbo ERCOFTAC Centrifugal Pump - OF Revision Problem?
 

Hi everyone,

i am a student at the University of Stuttgart, Germany and i'm currently working on my seminar paper which among other things requires me to reproduce the "ERCOFTAC centrifugal pump with a vaned diffuser" validation test case [1] published by the SIG Turbomachinery, with focus on the twodimensional case solved with MRFSimpleFoam and GGI [2].

My first steps were to download the latest Revision (1861) of OpenFoam 1.5-dev from the Subversion Repositories of the OpenFoam Extend Project [3] and the OF1.5 ThirdParty Sources from the SourceForge Repository [4].

After some tiny workarounds I managed to compile OF 1.5-dev successfully with my System Compiler GCC 4.6.1 (System: 64bit QuadCore, running Kubuntu 11.10). I also compiled the MRFSimpleFoam solver, SimpleFunction Objects and the OpenFoamTurboLibrary according to the SIG Turbo Wiki.

Unfortunately when I tried to run the validation test case (i made no changes) the MRFSimpleFoam Solver aborted with a floating point exception. Even when I try to run the MRFSimpleFoam Tutorial the solving process almost initially aborts with a floating point exception.

(With a little tuning I could get the ECPGgi2D case to run, but the results were not very good, the residuals were still relatively high (~10E-2) and started to oscilate at the end. The MRFSimpleFoam tutorial I couldn't get to run at all.)

After some resarch I found a thread here in this forum [5] which says that this behavior is caused by some problem in newer revisions and recommends to stick to the revision used by SIG Turbo which would be Rvn 1238.

So I downloaded 1.5-dev RVN 1238 from the ExtendProject Repositories. But now I have the problem that I can't get it to compile with my GCC 4.6.1. The recommended version of GCC for that revision was 4.2.2 if I recall it correctly.

The next logical step for me would be to get all the old software (gcc-4.2.2, gdb-4.6, cmake-2.4.7, dx-4.4.4) stated in the buildInstructions.txt and then try to compile the old OpenFoam Revision 1238, which would be quite time-consuming as i am imagining it, since i'm not quite the expert

Now my question(s) to you:
Would that be worth the effort?
Does anyone have any similar experience (and maybe even a solution)?

In the end all I want to have is a good result of the validation test case...
Maybe that would be possible with a newer Version of OF, maybe 1.6-ext?

Any help would be appreciated! ;)


[1] ERCOFTAC centrifugal pump with a vaned diffuser - validation test case

[2] MRFSimpleFoam ECPGgi2D

[3] SourceForge Subversion Repositories by OF Extend Project

[4] SourceForge OpenFoam 1.5 Repository

[5] CFD-Online Thread about ERCOFTAC centrifugal pump

Greetings Marcel and welcome to the forum!

First a disclaimer: I'm most familiar with the official OpenFOAM versions and only know a little bit about compiling the 1.5-dev and 1.6-ext variants.

Now for the issues I know of:
Don't use Gcc 4.6.1 for 1.5-dev. I'm not very familiar with the latest changes to 1.5-dev, but I believe that the latest working gcc on 1.5-ext is the 4.4.x series, maybe 4.5.x. If you are not familiar with the necessary modifications made in the official version, then do not blindly use 4.6.1 on 1.5-dev!
Kubuntu 11.10 still has in its repositories gcc and g++ 4.4.6. If you install that version of both gcc and g++ and be certain it's that version that is used for compiling 1.5-dev, then you should be able to get results that might be a bit more reliable.


Again, I'm not familiar with the evolution over time of 1.5-dev, but my guess is that you'll do fine with gcc 4.3.3 that OpenFOAM 1.5 and 1.5.x used.
I've got this tutorial in my blog: Blast from the past: installing OpenFOAM 1.5 in modern Linux boxes - like the title implies, it's for the official 1.5 series of OpenFOAM, but I think that you'll be able to hack a bit the script and use it for 1.5-dev! If not, I can take a look at it this weekend.

Good luck!
Bruno

thank you very much for your reply! due to an exam I won't have the time to check it out until next wednesday, but I'll keep you postet about my results as soon as I have any! :)

Hello Marcel,

maybe you want to use the live DVD with OF1.6-ext from the 6th OpenFoam Workshop @ Penn State download
http://rcc.its.psu.edu/ofw6/ofw6_v8.iso
You should have all things running with that Distri

For precompiled Ubuntu Packages (1.5-dev & 1.6-extend) you have to look for Personal Package Archive from CAE-TEAM
http://ppa.launchpad.net/cae-team/pp...nfoam-1.6-ext/
keep in mind that sources list contains LUCID but you can install them on newer Ubuntu distries as well
deb http://ppa.launchpad.net/cae-team/ppa/ubuntu/ lucid main
deb-src http://ppa.launchpad.net/cae-team/ppa/ubuntu/ lucid main
do not forget to add non-free for libparmetis3.1

you can always download the precompiled binaries.

there is an article in the wiki explaining step by step how to do it. fairly easy actually.

please note: i need the 1.5-dev or 1.6-ext version for the ggi-stuff to work! are there precompiled packages of those versions? i didn't find any!

Thank you elvis, I will take a look at it since it seems to be the simplest way to success :)

I already tried that, the result is always "can't find package" :(

Hello Marcel,
Oliver Borm made Packages for Ubuntu these were used for the LiveDVD

http://www.cfd-online.com/Forums/blo...m-1-6-ext.html

wierd, i just did a brand new installation no later than last week. have.you added the source as explained in the wiki? have you run a sudo apt-get update?

now i i've got it. the problem was that these packages were made for 10.04 lucid, however i was running 11.10 oneiric (actually since last night it's 12.04). so i had to add the lucid repositories explicitly, since the openfoam-packages can't be found in the oneiric-repositories!

(i just saw elvis already wrote that... sorry, seems i've missed it)

now let's see if it works :)

Okay, I finally managed to install the Openfoam-1.5-dev package from the CAE-Tam PPA repositories.
- Did an icoFoam testcase, everything went well.
- Compiled the TurboLibrary, SimpleFunctionObjects and MRFSimpleFoam. Everything seemed okay so far
- Ran an MRFSimpleFoam Testcase. Results looked good
- Then I ran the SIGTurbo ERCOFTAG Centrifugal Pump Testcase in its original state, no changes at all: and my good friend Mr. Floating Point Exception is back :(

It's the same behavior as I described in my first post: With a little tuning I can get the case to run, but the Residuals don't go lower than 10E-4 (actually they go up again and start to oscilate at around 10E-3).

FYI: I compiled LibTurbo, SimpleFunctionObjects and MRFSimpleFoam with GCC 4.6.1, might that be the problem? Should I try GCC 4.4 or lower?

What else could be the difference to the validation results of the SIGTurbo???

EDIT: This is what I get:
https://docs.google.com/open?id=0B9X...WlNNlpIVDZWUWM

This is what SIGTurbo gets:
http://openfoamwiki.net/images/f/ff/Pump_residuals.png

Any ideas?

I think your residuals are not that bad (according to your picture) and then you get a floating point exception?
For this test case, I can recommend to decrease the relaxation factor at the beginning, but then it should run.
this compiler is not recommended, so you have to test! you can compare the results, which have been run with different compilers!?

Best

are you sure you mean the right picture? i posted two pictures... one that shows the residuals that i get and one that shows the residuals that i'm SUPPOSED to get.
and i'm really not that satisfied with the ones I get...

no, i only get a floating point exception when I run the case in its original settings. then the FPE comes after 10 timesteps or so.

i have indeed decreased the relaxation factors of k and epsilon from 0.7 to 0.6 or lower. i tried a few but always had similar (unsatisfying) results.
but you say "at the beginning" do you think I should turn the relaxation factors back up after some timesteps? you think that works?

by now all my efforts to get this case running end up in the very same results. i have tried several ways:

- OF-1.5-dev RVN 1949 (latest Revision), MRFSimpleFoam, TurboLibrary, SimpleFunctionObjects all self-compiled with GCC 4.6

- OF-1.5-dev precompiled package from CAE-Team Repositories + MRFSimpleFoam, TurboLibrary and SimpleFunctionObjects compiled with GCC 4.6 and with 4.4

- OF-1.5-dev from the LiveDVD ISO Image. Then compiled MRFSF, LibTurbo, SFO with GCC 4.5, GCC 4.4 and GCC 4.3

everytime the same behavior.


According to this post (klick) Olivier Petit, who was part of the SIGTurbo, recommends to stick to the old revision 1240 (which is in fact 1238) due to some problem. So I think my best chance would be to get this old revision compiled, which I haven't succeeded yet.

One general question from a newbie: When I install GCC 4.4, i have "gcc-4.4" and "gcc-4.6" in /usr/bin. the link "gcc" is set to "gcc-4.6" per default. If I set "gcc" to point to "gcc-4.4" instead, will wmake use the gcc-4.4 compiler or do I have to change some other settings, too?

@timo_IHS: I see you're not seated very far from me, do you have experience with running this case? if so, maybe we could meet? i'm really growing desperate here

thanks again to all who are helping! it is greatly appreciated!

Okay I have not read your post properly.

The residuals, mmh, I think mine are also not that good.

To start with a lower relaxation factor is a usual way to start such a simulation, than you can increase it again! (This should work, but does not always)

You do NOT have to test rev 1238! This issue is solved!
Do you still delete the rotating faces (with the faceSet faceSetDict_noBoundaryFaces)? I think this is not necessary any more (I think, because I am using 1.6-ext, but for latest 1.5-dev revisions it should be the same). So check your BC of your runner!

I decreased the Relaxation Factors of k and epsilon from 0.7 to 0.6 and let the case run for 1000 time steps (that's where the residuals are the lowest). then I turned the relaxation factors back up to 0.7 and continued the case. residuals went back up and started to oscilate again... same thing

The makemesh script contains:
and in faceSetDict_noBoundaryFaces there is:
so the makemesh script indeed seems to remove the boundary faces from the "rotor"-set. if i just remove that passage from the makeMesh script the case won't run (doesn't say why). what exactly is the purpose of removing/not removing these boundary faces? what does that to the case?

My boundary conditions are still the initial conditions, I haven't changed anything. Is there something I am supposed to modify?

I still don't quite understand why it's not possible to get the same results as SIGTurbo if I run the same case with the same boundary conditions? is this a compiler issue? or were there some fundamental changes in between the revisions?

I run with 1.5-dev rev. 1861,

you do NOT need in the makeMesh anymore:
ALL faceSets (for rotating stuff)
it has been changed in the code between rev. 1238 and somewhere later

in the log-file you can see the message:
MRFZone rotor : did not find a faceZone; using 1872691 faces from the cellZone instead.
that is okay now...

Best and good luck

okay, i removed all the faceSet-commands and ran the case again (k & epsilon relaxation factors set to 0.6 due to FPE)

in the logfile i get the message "MRFZone rotor : did not find a faceZone; using 82558 faces from the cellZone instead."
@timo: you get 1872691 faces. did you run the same case? or was that just some random number?

residuals for u_x und u_y converge to ~10e-4, the residuals for p, k and epsilon converge to ~10e-3. still not quite what i expected since the residuals of SIGTurbo drop to around 10e-6, still decreasing.

the results for u and p are actually worse than before! before i removed the facesets my results were at least similar to those of SIGTurbo. now they're not.

I wonder if the preset boundary conditions of this case are really the ones I should use. I'm seriously beginning to doubt it!

Just FYI: I solved my problem. in fact there were 2 problems.

the faceSet-thing was just the one half. that's why it seemed like it didn't change anything when I corrected it.

the other half was to define the inlet and the ggi-patch as "nonRotatingPatches" in the MRFZones file. quite plausible when you think about it... still you just have to know it.

this thread was the key: http://www.cfd-online.com/Forums/ope...ing-walls.html

still, thanks everyone for your help!
consider this case solved! ;)