[msrinath80]

I would not change many things together. My recommendation is to take a case which gives you a fairly smooth profile for Cd/Cl and *only* change the outlet B/C to convectiveOutlet. If you see spikes now, it is very likely that this is due to the outlet B/C. If you don't see any spikes, go ahead and change the time discretization to "crankNicholson 1" and see what happens.

All said and done, my experience with OpenFOAM tells me that this is because of using "crankNicholson 1" in fvSchemes. For a more detailed exposition, read this[1] thread where Dr. Weller clearly explains why using "full crankNicholson" isn't really a good idea.


References:
[1] http://www.cfd-online.com/OpenFOAM_D...tml?1195511709

[mali]

Hai pU|,

I have run the simulation again, and this time i was using backward second order time discretization scheme. No problems arise this time and i got smooth force oscillation.

I think you are right. This is not because of the convectiveOutlet, but more probably to 'full' crankNicholson scheme.

Thank you again.

[7islands]

Hi all,

In case if any one of you needs a clarification for the discretizations and testing results of the convectiveOutlet bc code, I have written a quick summary [1]. The description starts from section 2.4 at page 5.

[1] http://oshima.eng.niigata-u.ac.jp/Op..._0287-open.pdf

[lakeat]

Wow, proceedings of Inter-noise 2008 (Shanghai), Should have pay you a visit, haha.

[pi06jl6]

Greetings all,

As a final touch in my forthcoming graduation, i am about to use convective outlet, this in order to minimize the corridor in my FSI program, but i cannot use wmake, i am guessing i am missing something but neverthenless the error message indicates no proper definitions, all of the error messages refers to "no matching function" followed by "candidates are", then i get like a few hundreds of lines, all related to fixedGradientPatchField. My educated guess is that wrong ld path is used, so here comes the settings in the option file: -lfiniteVolume. Anyone please help me?

Best Regards

Johan

[7islands]

Hi Johan,
It sounds like a compilation error, not a linker error. Can you post a full build log?

Takuya

[7islands]

Hi Johan,
I saw the log via email. I guess you are trying to compile one of the older versions. Can you try the newest one, 20070905 (see my post on Sep. 05, 2007) if my guess is correct?

Takuya

[7islands]

Hi Johan,

Thank you for the answer, i am quite positive that i am missing something
like a flag or enviromental settings, since other people have used it. To
your question, of course, the latest as you suggested on the thread. Take
a look on the include -I, is that correct?

Best Regards

> SOURCE=convectiveOutletFvPatchFields.C ; g++ -m32 -Dlinux -DDP -Wall
> -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O3
> -DNoRepository
> -ftemplate-depth-40
> -I/home/pi06jl6/OpenFOAM/OpenFOAM-1.4.1/src/finiteVolume/lnInclude
> -IlnInclude -I. -I/home/pi06jl6/OpenFOAM/OpenFOAM-1.4.1/src/OpenFOAM/
> lnInclude -fPIC -pthread -c $SOURCE -o
> Make/linuxGccDPOpt/convectiveOutletFvPatchFields.o

In fact, no. Since Make/options in the 20070905 distribution contains the following lines
<pre>EXE_INC = \
-I$(LIB_SRC)/finiteVolume/lnInclude \
-DWM_PROJECT_VERSION_MAJOR=`echo $(WM_PROJECT_VERSION) | awk 'BEGIN{FS="."}{print $$1;}'` \
-DWM_PROJECT_VERSION_MINOR=`echo $(WM_PROJECT_VERSION) | awk 'BEGIN{FS="."}{print $$2;}'` \
-DWM_PROJECT_VERSION_PATCH=`echo $(WM_PROJECT_VERSION) | awk 'BEGIN{FS="."}{if (length($$3) > 0) print $$3; else print "0";}'`</pre>their corresponding lines should appear in the log, and that's why I suspected if you were trying an old version. Can you check if your Make/options contains the lines? If the file does contain the lines, can you try compiling some other user libraries floating around in this forum or on the Wiki in order to see if your environment is properly set up?

Takuya

p.s. please keep the discussion on the forum whenever possible.

[pi06jl6]

Thank you, this solved my problem!

[mali]

Hi all;

I was running a 2-d square cylinder at low reynolds number and defined the outlet as convectiveOutlet. However the results of the vorticity contour was not as i expected. Instead of Karman vortex shedding distrubution, i got weird vorticity contour near the outlet.

I have tried many type of spatial and temporal discretization schemes. But the results were still the same.


1) anybody know what was actually happened.
2) What type / how should i defined on the initial condition of the pressure at the outlet.

Thank you

-sukri-

[mali]

Hi all;

I recently noticed the mistake i have made when doing the convectiveOutlet simulation. I defined the startFrom in the controlDict as latestTime. Now, i have fixed it, and the results seem good for me.

Thank you Takuya for sharing the convective outlet code.

Thank you again

-sukri-

[brugiere_olivier]

Hi all

I am a new user. I was running a diffuser and defined the outlet as convectiveOutlet. But I've the same problem than Cedric. When I use the convectiveOutlet condition in parallel, I've this message :

[1] --> FOAM FATAL ERROR :
gradientInternalCoeffs cannot be called for a defaultFvPatchField (actual type convectiveOutlet)
on patch sortie of field U in file "/craya/data/brugiere/poursuitesortie/processor1/765.52/U"
You are probably trying to solve for a field with a default boundary condition.
[1]
[1] From function defaultFvPatchField<type>::gradientInternalCoeffs( ) const
[1] in file fields/fvPatchFields/basic/default/defaultFvPatchField.C at line 694.
[1]
FOAM parallel run exiting
[1]
[compute-0-0.local:08265] MPI_ABORT invoked on rank 1 in communicator MPI_COMM_WORLD with errorcode 1

[0]
[0] --> FOAM FATAL ERROR :
gradientInternalCoeffs cannot be called for a defaultFvPatchField (actual type convectiveOutlet)
on patch sortie of field U in file "/craya/data/brugiere/poursuitesortie/processor0/765.52/U"
You are probably trying to solve for a field with a default boundary condition.
[0]
[0] From function defaultFvPatchField<type>::gradientInternalCoeffs( ) const
[0] in file fields/fvPatchFields/basic/default/defaultFvPatchField.C at line 694.
[0]
FOAM parallel run exiting
[0]
[compute-0-8.local:15020] MPI_ABORT invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 1

Somebody have any ideas ?

Thank you

Olivier

[brugiere_olivier]

Hi all

I am a new user. I was running a diffuser and defined the outlet as convectiveOutlet. But I've the same problem than Cedric. When I use the convectiveOutlet condition in parallel, I've this message :

[1] --> FOAM FATAL ERROR :
gradientInternalCoeffs cannot be called for a defaultFvPatchField (actual type convectiveOutlet)
on patch sortie of field U in file "/craya/data/brugiere/poursuitesortie/processor1/765.52/U"
You are probably trying to solve for a field with a default boundary condition.
[1]
[1] From function defaultFvPatchField<type>::gradientInternalCoeffs( ) const
[1] in file fields/fvPatchFields/basic/default/defaultFvPatchField.C at line 694.
[1]
FOAM parallel run exiting
[1]
[compute-0-0.local:08265] MPI_ABORT invoked on rank 1 in communicator MPI_COMM_WORLD with errorcode 1

[0]
[0] --> FOAM FATAL ERROR :
gradientInternalCoeffs cannot be called for a defaultFvPatchField (actual type convectiveOutlet)
on patch sortie of field U in file "/craya/data/brugiere/poursuitesortie/processor0/765.52/U"
You are probably trying to solve for a field with a default boundary condition.
[0]
[0] From function defaultFvPatchField<type>::gradientInternalCoeffs( ) const
[0] in file fields/fvPatchFields/basic/default/defaultFvPatchField.C at line 694.
[0]
FOAM parallel run exiting
[0]
[compute-0-8.local:15020] MPI_ABORT invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 1

Somebody have any ideas ?

Thank you

Olivier

[lakeat]

Originally Posted by msrinath80

@Eugene:

I just pulled out an excerpt from a very recent paper in Journal of Computational Physics (Vol: 206, page 661), and I can see now what you mean by 'slightly confused'.

"...The Convective Boundary Condition (CBC) has been used by Najjar and Vanka [4] and Najjar and Balachandran [5] in computing uniform flow past a normal flat plate. Cheng and Armfield [6] have employed it in computing uniform, two-dimensional flow past a circular cylinder. It has also been employed by Pauley et al. [7], Arnal et al. [8], Sohankar et al. [9] and Biswas and co-workers [10] for the computations of uniform, two-dimensional flow past a square cylinder. However, it is felt that the CBC lacks in a proper physical basis for elliptic and parabolic problems and it is also somewhat awkward to implement. The quantity U in the Equation is loosely defined in the literature as different authors have defined it in a different manner [4-*7]. The value of U, which yields minimum distortion in the vorticity structure at the exit, has to be determined by trial..."

Sorry, please bear with me, I still can't get the point, Why convectiveOulet is prefered by many? Can anybody give me some good explanations?
Is it bcoz CBC can shorten the length towards outlet? Do you have a complete review of this bc that I may refer to?

Another question, what are the requirements for the other turbulence quantities at the outlet, such as nuSgs, if CBC is used, is there any caution I should note?

Thanks for your patience!

[askjak]

Hi everybody,

I am looking into getting a convective outlet boundary condition for use in LES.

I can see that Takuya have done a lot of great work creating the convectiveOutlet BC which is supported for older version OpenFOAM and some has managed to use it under OF 1.5.

In the release documentation for OF 1.5 it is stated that it includes a generalized advective outflow boundary condition which is the basis for for example the waveTransmissive BC.

My question is now the following: Has anyone tried to make a convective BC based on the generalized advective code included in OF 1.5?

/Ask

[askjak]

Hi again,

I am trying to create a convectiveOutlet BC which uses advectiveFvPatchField (see post above). The idea is to set a constant speed at the outlet by overriding advectionSpeed() from advectiveFvPatchField.

Everything is in place but I can't manage to return a constant scalarField (see below) due to a lacking overview of the OF code and not optimal c++ skills.

template<class Type> tmp<scalarField> convectiveOutletFvPatchField<Type>::advectionSpeed () const

Please help with this simple problem. When I have tested that everything works I will post the BC to the forum for everybody benefit.

Best regards,Ask

[askjak]

I figured out how to solve the above problem.

I have made a convective outlet BC based on the generalized advective bc included in OF 1.5. I have not done thorough testing and have assumed that the generalized advective BC has been implemented correctly. I have only tested with the LES solver oodles.

Attached is the code for the boundary condition and a simple example.

convectiveOutlet20090612.tar.gz

pitzDaily_convectiveOutlet.tar.gz

Let me know if there is any problems.

/Ask

[lakeat]

Thanks, Ask!

[lakeat]

Hi Takuya, and hi Foamers,

A good day to you!
When I use O-type grids to simulate my flow past a circular cylinder, I cannot get good results using convectiveOutlet. The streamwise velocity (UMean) near the outlet drops greatly. So in the end I enlarge my domain, and using zeroGradient and now the results looks pretty good, but whenever I use convectiveoutlet, the outlet flow field was greatly disturbed.

I don't know who invented this boundary condition, and I don't quite understand why there'are many who speak good of this boundary condition. Does it make sense by saying?

"This condition ensures that vortices can approach and pass
the outflow boundary without significant disturbances or reflections into the inner domain"

And I don't know whether there's something wrong in the code itself.

Is there something wrong on my side? What's your experience, can you justify your results using convectiveOutlet?

[7islands]

Hi Daniel,

Is the outlet of your O-mesh perpendicular to the mean stream? convectiveOutlet tries to convect physical quantity in the perpendicular direction to the boundary. Or alternatively you might be able to try the advective BC in the standard OF release.

As written in README I don't use this particular convectiveOutlet code for any of CFD but this type of BC worked very well when I did unsteady flow-past-a-cylinder simulations with my in-house LES code in the past.

Takuya