|
[Sponsors] |
Strange behaviour when using LienCubicKE and NonlinearKEShih |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
September 27, 2007, 06:08 |
Here's a picture of a strange
|
#1 |
Senior Member
Håkan Nilsson
Join Date: Mar 2009
Location: Gothenburg, Sweden
Posts: 205
Rep Power: 18 |
Here's a picture of a strange behaviour at the surface of a water turbine runner, when using LienCubicKE and NonlinearKEShih in OF-1.4. The surfaces are colored by the turbulent kinetic energy, and everything that is not blue is incorrect. It looks like those colors should belong to some other variable. The behaviour does not appear when using the kEpsilon and RNGkEpsilon models.
I was first thinking that this might be post-processing, but since it appears both in Ensight and in paraFoam there is a risk that this actually affects the solution. The solution yields flow features that I can't explain physically, but they probably origin from this strange behaviour. I also had a look at the domain decomposition for the parallel simulations, but there is no processor interface exactly in this position. Did anyone see anything like this before? Håkan |
|
September 27, 2007, 06:24 |
as i posted some weeks ago, i
|
#2 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
as i posted some weeks ago, i had something similar.
i run a turbulent channel flow (normal one and also one with wall suction and blowing). with the nonlinear models ( i tried both with wall functions and lowre) the turbulent kinetic energy and the dissipation were always at one wall. first of all the kinetic energy should be zero at the walls and second in the normal channel flow the behaviour should be axissymetric. nobody could help me with that. i tried everything like playing with relaxation parameters and using the rng k-epsilon field as initial condition etc. how is your velocity field. does it give correct results? |
|
September 27, 2007, 06:56 |
Looking at circumferentially a
|
#3 |
Senior Member
Håkan Nilsson
Join Date: Mar 2009
Location: Gothenburg, Sweden
Posts: 205
Rep Power: 18 |
Looking at circumferentially averaged velocity profiles below the runner, the velocity actually looks fine. But then they are circumferentially averaged, and I expect that there is a difference in different positions in the circumference.
Looking at a pressure iso-surface there is a strange behaviour that might have its origin in the previously mentioned problem. In the following picture there is a non-axisymmetric (and non-periodic) pressure distribution at the runner cone. I am actually looking for this kind of structure, but the problem is that its location is steady in time (in the rotating coordinate system), which it shouldn't be. I also see that the pressure is not periodic on the five blades, so there will be a net force on the runner which there shouldn't be. This non-axisymmetric pressure at the blades is also steady in time in the rotating coordinate system. Håkan. |
|
September 27, 2007, 07:16 |
the problem looks similar to m
|
#4 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
the problem looks similar to mine. i also had problems with the pressure distribution. what are your boundary conditions for inlet outlet? and do you start the simulation with a converged rng-k-epsilon solution as initial condition?
|
|
September 27, 2007, 07:47 |
The simulations are started fr
|
#5 |
Senior Member
Håkan Nilsson
Join Date: Mar 2009
Location: Gothenburg, Sweden
Posts: 205
Rep Power: 18 |
The simulations are started from a converged kEpsilon solution.
Boundary conditions: U: INLE (specified inlet b.c., looks good) { type fixedValue; value nonuniform List<vector> OUTL { type zeroGradient; } WALL { type fixedValue; value uniform (0 0 0); } ROTI (some rotating walls) { type fixedValue; value nonuniform List<vector> ROTW (some rotating walls) { type fixedValue; value nonuniform List<vector> p: INLE { type zeroGradient; } OUTL { type zeroGradient; } WALL { type zeroGradient; } ROTI { type zeroGradient; } ROTW { type zeroGradient; } k: INLE (specified inlet b.c., looks good) { type fixedValue; value nonuniform List<scalar> OUTL { type zeroGradient; } WALL { type zeroGradient; } ROTI { type zeroGradient; } ROTW { type zeroGradient; } epsilon: INLE (specified inlet b.c., looks good) { type fixedValue; value nonuniform List<scalar> OUTL { type zeroGradient; } WALL { type zeroGradient; } ROTI { type zeroGradient; } ROTW { type zeroGradient; } Håkan. |
|
September 27, 2007, 10:53 |
Have you recompiled using the
|
#6 |
Member
E. David Huckaby
Join Date: Mar 2009
Posts: 57
Rep Power: 17 |
Have you recompiled using the bug fix for "TensorI.H" ?
"Tensor bug fix" This might explain the differening behavior with the linear k-eps models (kEps, RNGkeps,..) which calculate the turbulent production, G, from the square of strain magnitude, G = 2 * nu_t * magSqr( grad(U) ) as compared to the nonlinear models which calculate the production from a contraction ("&&" operator) of the velocity gradient and the turbulent stress, G = stress && grad(U) |
|
September 27, 2007, 11:10 |
oh wow thanks for that hint. a
|
#7 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
oh wow thanks for that hint. actually what does recompüile means? do i only have to overwrite that certain file on my hardrive or also something else?
|
|
September 27, 2007, 11:18 |
and also is that patch working
|
#8 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
and also is that patch working as well for openfoam 1.4?
|
|
September 27, 2007, 11:29 |
The bug also applies to openfo
|
#9 |
Member
E. David Huckaby
Join Date: Mar 2009
Posts: 57
Rep Power: 17 |
The bug also applies to openfoam 1.4 and I don't think "TensorI.H" changed between 1.4 and 1.4.1.
(you might check this before doing a replace) By recompile, I meant to replace (edit) the existing "TensorI.H" with the posted version and recompile your OpenFOAM library. Dave |
|
September 27, 2007, 11:45 |
should i recompile the whole s
|
#10 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
should i recompile the whole src and applications or only src?
is that the right command? foam cd src ./Allwmake cd ../applications ./Allwmake |
|
September 27, 2007, 11:49 |
I did not include this bug fix
|
#11 |
Senior Member
Håkan Nilsson
Join Date: Mar 2009
Location: Gothenburg, Sweden
Posts: 205
Rep Power: 18 |
I did not include this bug fix in these simulations. That is actually the kind of bug I expected to be the reason for this behaviour.
I hope that I will have the time to test the bug fix soon. Thank you Dave! Håkan. |
|
September 27, 2007, 11:53 |
Robert,
You only need to re
|
#12 |
Senior Member
Cedric DUPRAT
Join Date: Mar 2009
Location: Nantes, France
Posts: 195
Rep Power: 17 |
Robert,
You only need to recompile from the first wmake you find in your tree: OpenFOAM/OpenFOAM-1.4.1/src/OpenFOAM so, after you changed the TensorI.H, go there and wmake there this is C++ power :o) regards, Cedric |
|
September 27, 2007, 13:24 |
when do the wmake i always get
|
#13 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
when do the wmake i always get an error message like that:
maduta@linux-hiwi1:~/OpenFOAM/OpenFOAM-1.4/src/OpenFOAM> wmake make: Warning: File `Make/linuxGcc4DPOpt/dontIncludeDeps' has modification time 10 s in the future make: Warnung: Mit der Uhr stimmt etwas nicht. Die Bearbeitung könnte unvollständig sein. SOURCE=OSspecific/Unix/signals/sigFpe.C ; g++ -m32 -Dlinux -DDP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -DWM_PROJECT_VERSION='"'1.4'"' -I/home/maduta/OpenFOAM/OpenFOAM-1.4/src/zlib-1.2.1 -IlnInclude -I. -I/home/maduta/OpenFOAM/OpenFOAM-1.4/src/OpenFOAM/lnInclude -fPIC -pthread -c $SOURCE -o Make/linuxGcc4DPOpt/sigFpe.o /bin/sh: g++: command not found make: *** [Make/linuxGcc4DPOpt/sigFpe.o] Fehler 127 maduta@linux-hiwi1:~/OpenFOAM/OpenFOAM-1.4/src/OpenFOAM> what could that be? |
|
September 29, 2007, 07:53 |
hi i managed to overwrite the
|
#14 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
hi i managed to overwrite the TensorI.H file in the Tensor directory.
what i did then is going with the terminal to the /src/OpenFOAM directory and i made the command: wmake /OpenFOAM/OpenFOAM-1.4.1/src/OpenFOAM/primitives/Tensor/TensorI.H after making all the dependencies at the end i get an error like this: finished, there are no rules to create TensorI.H someone knows if that could be a compilation error due to ubuntu which i am using because suse didnt work. or is there any mistake in my commands? and also does this wrong tensor definition also affect the rsm-models? i guess so cause they also give me wronmg results it would be nice if someone could help me :-) |
|
October 1, 2007, 07:29 |
Hi Robert!
You have to rema
|
#15 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Hi Robert!
You have to remake the libOpenFOAM.so: cd $FOAM_SRC/OpenFOAM wmake libso Bernhard
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
October 1, 2007, 14:28 |
i just want to give an update:
|
#16 |
Member
robert maduta
Join Date: Mar 2009
Posts: 33
Rep Power: 17 |
i just want to give an update:
i finally managed to do a wmake libso in ubuntu with the new TensorI.H file. it all went well but the nonlinear models are still giving wrong results for channel flow, like totally non symmetric. so Håkan Nilsson if you find out something new plz let me know. |
|
May 10, 2012, 12:02 |
|
#17 |
Member
Aniko Rakai
Join Date: Oct 2009
Location: Geneva
Posts: 30
Rep Power: 17 |
Hi all!
It's been a while since you wrote here but did someone find out what is wrong with the nonlinear models? I am also trying to use them, first some tests with a boundary layer flow. The results are different from the analytical solution and I thought maybe because from the original Shih paper mentioned in the code the dirac terms, i.e. the double dot products or the gradU are not implemented. Did someone have the same feeling when comparing with the paper? Aniko |
|
January 30, 2013, 06:16 |
generation term
|
#18 |
New Member
Jongtae Kim
Join Date: Mar 2009
Location: Daejeon, Republic of Korea (South)
Posts: 8
Rep Power: 17 |
Is there anyone who knows correct generation term for nonlinear turbulence model?
In all the nonlinear models in OpenFoam, the generation term looks like G = nu_t * symm(grad(U)) && grad(U) - nonlinear_term (1) I think the first term of G must be same as one in linear models. In linear models such as kEpsilon, G = nu_t * 2 * symm(grad(U)) && grad(U) (2) = nu_t * 2 * magSqr(symm(gradU)) I can't understand why factor 2 is omitted in eq. (1). If you know the reason or the correct generation for nonlinear turbulence model, please give your help to me. Many thanks |
|
March 6, 2013, 10:50 |
Courant number increases
|
#19 |
New Member
Akbar Mohammadi Ahmar
Join Date: Oct 2012
Location: Tehran , Iran
Posts: 4
Rep Power: 14 |
Hi all,
When run with the Cubic non-linear model Lien with the linear wall Function Courant number increases sharply and so soloution of problem is stops. but when run with Nonlinear wall function I haven't this problem. Please friends help me that how to solve this problem. Thanks. |
|
March 6, 2013, 11:01 |
|
#20 |
New Member
Akbar Mohammadi Ahmar
Join Date: Oct 2012
Location: Tehran , Iran
Posts: 4
Rep Power: 14 |
Hi jkim,
I agree with you , Because I work with nonlinear models for example quadratic Shih . when that me use the first term of G (nu_t * symm(grad(U)) && grad(U)) result of solution is uncorrect . I run same model with G = nu_t * 2 * symm(grad(U)) && grad(U)- nonlinear_term that result is very good. so, I think this approach is correct. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
IcoFoam strange behaviour when gravity is included | nicasch | OpenFOAM Running, Solving & CFD | 5 | August 29, 2014 11:09 |
buoyantFoam OF15 very strange behaviour in hotRoom | andrea_barbera | OpenFOAM Running, Solving & CFD | 4 | July 30, 2009 10:06 |
Strange multicomponent source behaviour | Zitron | CFX | 4 | July 12, 2007 16:32 |
Strange Behaviour in CFX-Mesh | Kasper | CFX | 0 | May 14, 2007 09:24 |
Strange behaviour in Coffus | Luis Filipe Fabiani | Phoenics | 0 | June 1, 2006 12:23 |