motorBike tutorial doesn't work out-of-the-box
 

Hi all,

The motorBike case didn't work out for me, sadly. At first, meshing seemed to have worked out. (Is it appropriate to check the visualisation of vtkCompositeIndex for observing of the refinement level? I thought I read that, just don't remember where...)

After the run (nothing changed in the dicts, just read!), I visualized the write steps of velocity U as wireframe in ParaFoam and the velocity seems to be 0 everywhere at first glance. At write step 5 (equals time 500s) the velocity seems to be 0 at most points except for several points, where the velocity seems to be the maximum value (unbelievable high values like 4e37!). Why is that? I thought, the tutorial should present a case that is working (assumption: no changes made by the learner)? What did I do wrong here? I noticed, the residuals at endTime (i.e. 500, deltaT=1) are much higher than the tolerance settings, so the solver stopped iterations due to endTime rather than due to a "good" result. Is it just a matter of more iterations (don't think so personally)?

http://img36.imageshack.us/img36/685...mfoto10.th.png

Further observation showed the following:

In the 0/p file, the dimensions for p is set to [0 2 -2 0 0 0 0], what would be equivalent to (m*m)/(s*s) which is obviously not a pressure unit... How come? Anyway, the pressure is set to uniform 0...

The snappyHexMesh log gives the following:
I don't know, where or what to investigate any further. I looked through ALL the logs of each step (blockMesh, snappyHexMesh, simpleFoam) completely and couldn't find any other stuff that looked strange. I also checked ALL of the case files forth and back prior to meshing and running and except of the 0/p file (see above) I didn't find anything suspect...

Suggestions?

Cheers
Wolle

P.S.: A merry christmas and a happy new year to all the forum users. Hope to read you next year...

Season Greetings Wolle,

First of, you didn't mention if you are using OpenFOAM 1.6 or 1.6.x. Nor if it's the 32 or 64bit version, and/or which gcc version you are using... since that could also affect the results ;)

By my experience, the 1.6 version doesn't converge, but the 1.6.x does. Additionally, the 64bit version seemed to give a better mesh in much less time than the 32bit version.

It's not the first time I see tutorial cases that use pressure variance in time (dp/dt) instead of pressure itself. I'm not sure why either, but my best guess is that it is better to use the variation of pressure rather than absolute pressure.

I believe I've mentioned something about the motorBike version 1.6 not working properly in another thread (actually, it was this one), so if you looked for search hits on motorBike, you might have already gotten a hint to use the 1.6.x version ;) I've seen other fixes in another thread also...

Best regards and a Merry Christmas and a Happy New Year to you too Woole :)

Bruno

The incompressible solvers in OpenFOAM solve the density normalized Navier-Stokes equation. The units corresponds to p/rho.

Ask

Hi Bruno,

Oh. I wouldn't have expected that to affect the results (esp. gcc version and architecture). But here you go: I use the OpenFOAM 1.6 binaries (32bit) on Xubuntu 9.04-32bit. Gcc is 4.3.3 (as supplied with the Third Party binary pack, I suppose). Sadly, the compilation of OF1.6 from git (would that be what you call 1.6.x?) fails. (See here for details). Is there another way to obtain 1.6.x than to compile from git sources?

Time is not important at the moment. Convergence would be nice though... ;)

I thought, I'd been through ALL of the threads a forum search for "motorbike" (shouldn't be case sensitive?) gave... they aren't that much (35). I'll have a look again.

Cheers & a happy new year
Wolle

Hi Ask,

Yes, that makes sense indeed! Thanks a lot!

Cheers
Wolle

Hi Wolle and Happy New Year :)

I forgot to focus on one thing: you actually only need to borrow the 1.6.x motorBike case and then you can use it with the 1.6 OpenFOAM applications! The 1.6 motorBike case didn't converge, it diverged and blows up!!

As for building the 1.6.x from git, I haven't had problems in 32 and 64bits versions of Ubuntu. Although I didn't use the cookbook, I did it all by hand and I was targeting cross-compilation in Linux for Windows (see here). I've been following that cookbook thread, but haven't had the time to test things and make sure what is going on there... Anyway, compared with the cookbook for Ubuntu, I've also installed the following packages:I hope these solutions work for you too :)

Best regards,
Bruno

Hi Bruno,

Oh! That's very interesting to know! At the moment, I'm running the old (1.6) case with pyFoamPlotRunner as suggested in the thread you mentioned. When finished, I intend to make some screenshots (or whatever gnuplot provides to caputer the plots) and put them online tomorrow. Then I'll try the 1.6.x version of the case and compare both.

Hm. I think that cross-compilation isn't an option at the moment, though it might be interesting later. The cookbook install script simply does a git pull and then the make commands. I can see no differences to "compilation by hand". Maybe I give it another try...

Cheers and thanks for your help
Wolle

Hi Wolle,

Cross-compilation currently isn't in the mainstream. Although you can find "mingw32" in the rules folder of wmake, they are still unofficial modifications (there are a few variants that you can check in the end of that link to openfoamwiki.net) and I don't think they have been adapted to the openfoam-dev/-extend variants either.

Oh, and don't forget to install those packages I mentioned before trying to recompile OpenFOAM ;)

Best regards,
Bruno

Hi all,

especially for others who might have the same problem, I'm going to post, what I found out on this problem.

As Bruno mentioned, the 1.6 version of the motorBike tutorial seems not to reach convergence. One can monitor this by a programme called pyFoamPlotRunner included in a tool collection called PyFoam. pyFoamPlotRunner calculates plots (via gnuplot) of the residuals and other solver output on runtime of the solver. I attach a screenshot made after the run of pyFoamPlotRunner/simpleFoam ended.

As one can clearly see, the residuals for the components of U, k and omega stay way above the defined tolerance, which is 1e-8 for each of the variables and can be found in the system/fvSolution file.

To proceed, I obtained the git version of OpenFOAM 1.6.x just to get the 1.6.x version of the tutorial. I run this with OpenFOAM-1.6 (as git 1.6.x version still wont compile) and check both case versions for differences in the meantime.

...

... while checking the different versions of the motorBike case, one comes across the file 0/turbulentBoundaryField, which obviously doesn't exist in the 1.6.x version of the case.

Differences are found in the 0/k and 0/omega files.

1.6: 0/k includes the 0/turbulentBoundaryField file, while the 1.6.x version contains the relevant information directly. However, the relevant information differs between the versions.

1.6-0/k respectively 1.6-0/turbulentBoundaryField:
1.6.x-0/k:
1.6: 0/omega includes the 0/turbulentBoundaryField file, while the 1.6.x version contains the relevant information directly. However, the relevant information differs between the versions.

1.6-0/omega respectively 1.6-0/turbulentBoundaryField:
1.6.x-0/omega:
One can see, that the wall functions differ between the versions!

Another difference is, that the 1.6 version contains a file constant/turbulenceProperties, which doesn't exist in the 1.6.x version. This file obviously activates turbulence calculation based upon a SpalartAllmaras turbulence model in the 1.6 version. I suppose turbulences are not calculated upon a model, but directly upon the locally refined mesh in the 1.6.x version, is that right?

All other files are identical.

Cheers
Wolle

No, 1.6.x uses wall functions (omegaWallFunction and kQRWallFunction). And it added turbulence values which where obviously missing in the 1.6 tutorial.
You can find the history here:
http://repo.or.cz/w/OpenFOAM-1.6.x.g...orBike/0/omega

Regards BastiL

Hi Bastil,

okay then, but why is the constant/turbulenceProperties file missing?

Cheers
Wolle

Hi all again!

Finally, the run of the 1.6.x case version on OF-1.6 seems to be more successful. But I'm still confused with some results.

See in my first screenshot, the motorbike presented as pressure by cells. The values at the scale do at least seem to be reasonable.

http://img697.imageshack.us/img697/1...mfoto12.th.png

See in the second screenshot the same picture, just with velocity by cells. Third is velocity by points (where does that purple come from???). On both screenshots scales, the magnitude of maximum velocity seems to be reasonable again. But why is velocity zero almost everywhere?

http://img10.imageshack.us/img10/137...mfoto13.th.png http://img402.imageshack.us/img402/3...foto14j.th.png

A fourth screenshot shows streamlines generated from vector U, see the settings on the left. The streamlines show, that there IS velocity, why doesn't the regular view (velocity by points/cells) show something like that around the motorbike or at least nearby? (Center point for stream line generation is approx. where the mouse pointer is located).

http://img9.imageshack.us/img9/4599/...mfoto15.th.png

Fifth screenshot is just a detail to show, that velocity isn't zero _everywhere_ on the bike... (velocity by points, wireframe).

http://img94.imageshack.us/img94/970...mfoto16.th.png

I'd expected the velocity to be around 20m/s nearby the bike (Sorry, forgot to include the scale in the screenshot.The yellowish green on the floor equals approx. 20m/s)? Why isn't that? One can see, that the floor ("lowerWall") shows exactly this - velocity is around 20m/s there - and both have the same settings in 0/k and 0/omega files?

Cheers
Wolle

EDIT: About convergence... not yet below the tolerance settings but waaay better, than the 1.6 case:

Because settings are included into 0/k and 0/omega now as you realized before. It is up to you how to define this, both should be possible.

Regarding the velocities I can not really see this in your screeshots, but you should expect to get for point data(!):

20 m/s on the floor ("lowerWall") - as you do.
0 m/s on all stationary non-slip walls (!) not 20 m/s. So this seem reasonable too, as far as I can see.

Regards.

Hi Bastil and thanks for your replies.

I'm trying to understand, but I'm not getting this point. The floor/lowerWall and the motorbike are stationary non slip walls, as far as I can see. upperWall and frontAndBack are slip walls. The motorbike and the floor are defined exactly the same apart from initialising (isn't that what takes place in timestep 0? only initialising?) the floor with 20m/s and the bike with 0m/s. In my understanding, both should behave the same after some iterations.

Maybe it's also a problem of imagination? I think of it as a motorbike in a wind tunnel. Floor and bike are fixed and air is blown from front to back. So I'd say, the velocities measured near the fixed objects should be around 20m/s, but not zero? What's wrong with my imagination of the problem?

Cheers & Thanks for your patience
Wolle

No. motorbike is stationary but floor is a moving wall since it is moving with 20 m/s.
No once more. For the internal field, 0 only does initialisation but for all the boundary patches this values are the boundary condition values that are kept during all the calculation. So 0 does two things: Initialising the volume and defining boundary conditions on all boundary patches.

The Floor is not neccessarily fixed in a wind tunnel, this is indeed dependend on the wind tunnel type. In reality it is always moving and this is why it is calulated that way, too.
Regarding velocities: This strongly depends where to measure. The velocity directly on the surface is zero (slip-condition, this is what you see when you use point values!) and we get a (turbulent) boundary layer profile until we leave the boundary layer. Hope this makes it clear.

Regards BastiL

Hi Bastil,

Thanks for your enlightment, I don't know, why I didn't realize this.

That's clear, but interesting though. As I'm no native English speaker, I would translate the generic German word for "slip condition" with "stick condition" instead. To me, that sounds more appropriate to the generic German word but on the other hand I concern "stick" and "slip" as opposing words. I wasn't aware of that special vocabulary.

Okay. Now... what if I would like to visualize this boundary layer velocities? Is there another way than to visualize the steamlines?

Cheers & Thanks again for your reply
Wolle

Its "Haftbedingung" in German ;-)

This is slightly more difficult. It depends on what you exactly want to see? You can try create cutting planes e.g. It might also be possible to create oil-flow like surface streamlines but this is difficult to do in paraview. NB: Velocity directly near the surfaces are strongly depending on turbulence modeling. Choosing another turbulence model might lead to completely diffenrent results.

Regards

Hi Bastil,

Exactly.. ;)

Steamlines I've tried, and by now I think (as mentioned somewhere in the users guide), to obtain a "good" steamline plot is simply a matter of trial and error. I didn't think of the cutting planes though.

Yes, I'm aware of this. I'm just thinking of this tutorial as a showcase and what options of postprocessing there are. (I know there's a special subforum for this, just didn't want to completely roll it up there again).

So thanks again, I think I've got a pretty good imagination of what one can do. Sadly, I've got to focus on different things at the moment... I'll get back to it later, I think.

Cheers
Wolle

motorbike case
 

I have also got a working case of motorbike 1.6.x git . I am including stream tracer plot

Hi,

although I'm out of this at the moment, it would surely be nice for others, if you'd share your case...

Cheers
Wolle

Beside the case files in the OF distribution, is there any written text to this tutorial, probably including paraview postprocessing?

As far as I know: no. That's why I asked to share his case (also Paraview cases can be saved!).

Regards

motorbike1.6.x case
 

Now my Internet connection is very slow and it will take lot of time to upload it . probably on next week I can do that, Thanks for your response

Prasanth