[Wolle]

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)?



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:

Undo iteration 0
----------------
Checking faces in error :
    non-orthogonality >  65 degrees                        : 0
    faces with face pyramid volume < 1e-13                 : 0
    faces with concavity >  80 degrees                     : 0
    faces with skewness >   4 (internal) or  20 (boundary) : 0
    faces with interpolation weights (0..1)  <  0.02       : 0
    faces with volume ratio of neighbour cells <  0.01     : 0
    faces with face twist <  0.02                          : 1
    faces on cells with determinant < 0.001                : 0
Detected 0 error faces on boundaries that have been merged. These will be restored to their original faces.

Detected 1 error faces in mesh. Restoring neighbours of faces in error.

Edge intersection testing:
    Number of edges             : 1005921
    Number of edges to retest   : 0
    Number of intersected edges : 42360
Constructing mesh displacer ...

Checking mesh manifoldness ...
Outside of mesh is multiply connected across edges or points.
This is not a fatal error but might cause some unexpected behaviour.
Writing 34 points where this happens to pointSet nonManifoldPoints

Calculating patchDisplacement as distance to nearest surface point ...
Wanted displacement : average:0.00364437 min:6.64418e-09 max:0.0203723
Calculated surface displacement in = 0.8 s


--> FOAM Warning : Displacement (0.00473027 -0.00277192 0.0110628) at mesh point 99138 coord (0.506196 0.0692469 0.180362) points through the surrounding patch faces
Smoothing displacement ...
Iteration 0
Iteration 10
Iteration 20
Displacement smoothed in = 7.09 s

Edge intersection testing:
    Number of edges             : 1022449
    Number of edges to retest   : 204569
    Number of intersected edges : 58574
Snapped mesh : cells:318771  faces:1022449  points:383614
Cells per refinement level:
    0    934
    1    1720
    2    5040
    3    9472
    4    131655
    5    23602
    6    146348
Writing mesh to time constant
Written mesh in = 24.46 s.
--> FOAM Warning : 
    From function layerParameters::layerParameters(..)
    in file autoHexMesh/autoHexMeshDriver/layerParameters/layerParameters.C at line 377
    Reading "/home/kretzschmar2/OpenFOAM/kretzschmar2-1.6/run/tutorials/incompressible/simpleFoam/motorBikeSingleCore/system/snappyHexMeshDict::layers" from line 184 to line 452
    Layer specification for minZ does not match any patch.

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...

[wyldckat]

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.

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?

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.

Suggestions?

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

[askjak]

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?

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

Ask

[Wolle]

Hi Bruno,

Originally Posted by wyldckat

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

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?

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.

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

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...

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

[Wolle]

Hi Ask,

Originally Posted by askjak

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

Yes, that makes sense indeed! Thanks a lot!

Cheers
Wolle

[wyldckat]

Hi Wolle and Happy New Year

Originally Posted by Wolle

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

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:

byacc bison texinfo

I hope these solutions work for you too

Best regards,
Bruno

[Wolle]

Hi Bruno,

Originally Posted by wyldckat

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!!

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.

Originally Posted by wyldckat

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:

byacc bison texinfo

I hope these solutions work for you too

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

[wyldckat]

Hi Wolle,

Originally Posted by Wolle

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...

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

[Wolle]

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.

...

[Wolle]

... 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:

lowerWall
{
type kqRWallFunction;
}

"motorBike_.*"l
{
type kqRWallFunction;
}

1.6.x-0/k:

lowerWall
{
type kqRWallFunction;
value $internalField;
}

"motorBike_.*"l
 {
 type kqRWallFunction;
  value $internalField;
}

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:

lowerWall
{
type kqRWallFunction;
}

"motorBike_.*"l
{
type kqRWallFunction;
}

1.6.x-0/omega:

lowerWall
{
type omegaWallFunction;
value $internalField;
}

"motorBike_.*"l
 {
 type omegaWallFunction;
  value $internalField;
}

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

[bastil]

Originally Posted by Wolle

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?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

[Wolle]

Hi Bastil,

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

Cheers
Wolle

[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.



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?



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).



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



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:

Time = 500

smoothSolver:  Solving for Ux, Initial residual = 4.27648e-05, Final residual = 2.04875e-06, No Iterations 4
smoothSolver:  Solving for Uy, Initial residual = 0.000843881, Final residual = 4.0716e-05, No Iterations 4
smoothSolver:  Solving for Uz, Initial residual = 0.000906448, Final residual = 4.27539e-05, No Iterations 4
GAMG:  Solving for p, Initial residual = 0.00336481, Final residual = 0.000116042, No Iterations 2
time step continuity errors : sum local = 1.77245e-05, global = 2.52181e-07, cumulative = -0.000389702
smoothSolver:  Solving for omega, Initial residual = 1.03476e-05, Final residual = 6.90257e-07, No Iterations 3
smoothSolver:  Solving for k, Initial residual = 0.000147569, Final residual = 1.11085e-05, No Iterations 3
ExecutionTime = 8794.01 s  ClockTime = 9769 s

End

[bastil]

Originally Posted by Wolle

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

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.

[Wolle]

Hi Bastil and thanks for your replies.

Originally Posted by bastil

20 m/s on the floor ("lowerWall") - as you do.
0 m/s on all stationary non-slip walls (!) not 20 m/s.

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

[bastil]

Originally Posted by Wolle

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.

No. motorbike is stationary but floor is a moving wall since it is moving with 20 m/s.

The motorbike and the floor are defined exactly the same apart from initialising (isn't that what takes place in timestep 0? only initialising?)

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.

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?

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

[Wolle]

Hi Bastil,

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

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!)

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.

and we get a (turbulent) boundary layer profile until we leave the boundary layer.

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

[bastil]

Originally Posted by Wolle

As I'm no native English speaker, I would translate the generic German word for "slip condition" with "stick condition" instead.

Its "Haftbedingung" in German ;-)

Originally Posted by Wolle

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

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

[Wolle]

Hi Bastil,

Originally Posted by bastil

Its "Haftbedingung" in German ;-)

Exactly..

Originally Posted by bastil

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.

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.

Originally Posted by bastil

NB: Velocity directly near the surfaces are strongly depending on turbulence modeling. Choosing another turbulence model might lead to completely diffenrent results.

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

[vprasu]

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