2 questions about boundary conditions
 

Hi. I'm starting to use OpenFOAM, and I'm not very used to it yet, so I believe my doubts are really simple. I've had some difficulties about setting some boundary conditions:

(1) Is there a way of setting a BC for p in an inlet to be extrapolated from the internal field, for the use of a solver for incompressible flows, like icoFoam?

(2) Is there a way of setting a given expression as a BC (a given velocity profile, for example)?

hi
1) extrapolated from the internal field?? for what?
2) groovyBC
http://openfoamwiki.net/index.php/Contrib_groovyBC

thanks
 

groovyBC, I'll check it.

I want to set BCs to be extrapolated from the internal field in cases where there's no physical consistency in setting other BCs. Then p should be extrapolated from the last volumes near the boundary...

That sounds like zeroGradient to me

what I want is similar to zeroGradient, but zeroGradient uses only one point to extrapolate (equals the value on the face to that on the last volume center), and I want some BC that uses more points to extrapolate (it could use the last two volume centers to extrapolate to the face using a linear straight, or the last three volume centers to extrapolate to the face using a quadratic function...).


Another doubt: is it possible to use groovyBC (or something similar) to create the inicial internalField???????

If there is no physical consistency, then what is the reasoning in doing it like this? Can you comment on the physics you're trying to simulate?


For the initial field you can use funkySetFields.

thanks for the tip for the initial field. I'll take a look.

the reason for setting a BC to be extrapolated is that it's a better choice for when there's no physically consistent choice of BC applicable. Sometimes the physics of the problem just specifies one BC, but the algorithms of solution require that you specify the BC at all boundaries, so the extrapolation from the internal field is a better choice than others.

Right now I don't wanna simulate anything specifically, but in general such a BC would be useful. For instance, in the simple incompressible laminar flow in a tube, mathmatically it would be necessary just the specification of one BC for p in the axial direction (the inlet OR outlet, usually), but in openFOAM you must specify the inlet AND the outlet. What's usually done is specifying a fixedValue at the outlet and a zeroGradient at the inlet, but that's physically untrue (the gradient is NOT ZERO in the real problem), what causes a bigger entrance length than it would be required. This is a typical case where setting the BC to be extrapolated from the internal field would do a better simulation.

A case in which this is really significant is the simulation of viscoelastic fluids flow, for example. It's necessary to specify BCs for the tension tensor at all boundaries, and, without a better solution, it's usually used zeroGradient, but in this case that's a really bad approach, cause the tension gradient is indeed big and far from zero at the walls. That's a case in which the tension at the walls could be extrapolated from the internal field like a better approximation than the zeroGradient.

Do you understand the problem?

OpenFoam BC hoe to define an extrapolation BC
 

Hi All
I like to ask how I can define an extrapolation BC at my channel outlet using
OpenFoam BC.
regards,
Samir

Hi, mateusps

Have you find answer for you problem 1?

Best,

Lianhua

Hi,
has anyone found a solution of the problem one?

Hello mateusps

1- for what you want to do (extending the zeroGradient to someting like zerozeroGradient:p), there is no easy and clean way to do. You can:
a- do the thing at "hand" by the following trick: for a boundary face, first access to its neighbor cell "CN" say, second use the cellCells of CN to access a second order stencil. Using the normal of each face of CN and taking the dot product with the boundary face normal, you can do job. BUT it is very dirty job and can encounter problems in a parallel framework (nevertheless, barely to happen in real cases...).
b- try to use the extendedStencil framework (in finiteVolume/fvMesh) to do a cleaner and safer job.

2- I think you do some confusions in the "problem" of using of zeroGradient. Typically your example of the tube is not good. Don't forget that velocity and pressure are always coupled and mathematically as you said you need to specify one (and only one) of the two variables both at inlet and outlet. Specifing zeroGradient for pressure takes sense when specifing prescribed value for velocity. When you say that "physically" the pressure is not zeroGradient, I believe you speak about something that in a "infinite" Poiseuille flow, the pressure is linear so gradient is not zero? Clearly you have right from this point of view. But it doesn't mean we cannot use zeroGradient for pressure when prescribing velocity. It just implies than in the first cell layer related to your BC, the flow is not "stricto sensus" a Poiseuille one. But in all the domain it is. Last but not least, what is the most important is the convergence of the flow on mesh size. And zeroGradient BC leads to overall convergence in standard norms.

I don't see why is this so difficult: use the fixed gradient boundary condition and adjust the graduent based on the solution

Hello hjasak,

thanks for giving your help on this topic.

Using the fixedGradient BC with a "good" gradient specified is good idea from implementation point of view but there is still the need to build this "good" gradient. And from this point of view, mateusps wants something little special I think: building a directional gradient (which direction? normal to the BC or following the flow? I don't know what mateusps wants) with a possible high order stencil (he wants to emulate something like 3rd order reconstruction). From this point of view, for me, it is not so direct. How do you define the gradient? I think you cannot bypass the notion of direction for mateusps. So you need to use a gradient construction which depends on the flow direction or on the face normal (more difficult I think). Morever, you must build a high-order (>2) reconstruction. Is it so direct? If yes, can you post the settings for gradient reconstruction and/or the coding if any? It will be usefull for us.

Lastly, I am not really sure that there is a real need of this kind of construction for mateusps problem if I read well his posts.

Easy. Make a grad in top level code, look it up from the boundary condition and do a patch internal field.

The grad boundary condition will always be implicit only I the first cell because you don't have the addressing for that.

True, you can build yourself the implicit extended molecule and my students have done this for eg ILUCp preconditioning, but I would this pretty advanced

Hello hjasak,

first excuse me but my english is quite poor...

Ok, yet few points:

1- I understand the trick (add a grad at top level, access it in the BC, put it in the patch internal) but I still don't know how to build an ad hoc gradient for two reasons.
Ok let me say I want to work on a field "h" with a fixedGradient (yet not determined at this stage) in a BC. In top level code, if I write something like dh = fvc::grad(h) but since I have a fixed gradient BC with a snGrad value not yet determined, the value of dh in cells adjacent to the BC will take the undetermined snGrad value into account. Not good no?
Second point, related to the first in fact: I want the dh gradient to be "upwind on n (the BC face normal)" in the sense that I want to eliminate its dependance on the undetermined snGrad value. How can I do this? For upwinding on an existing field like U it is ok with standard tools but for the normal face which doesn't exist on the interior domain, how can I do? (not by "hand", i.e working directly in the cells adjacent to the BC face)
Last but not least, beyond the standard Gauss or leastSquare methods for grad, what tools are available for high-order stencils? I'm not acquainted enough with the extendedStencil framework. Is it a pertinent and validated tool for the present needs?

2- for the implicit extended stencil, is it available in your last release of OF extend. I think yes but I am not sure?

3- I think you will (?) be present at the first OpenFoam french users day at Rouen with M. Reveillon (from Coria institute --> http://journeeutilisateursof.foam-u.fr/ -- I do a little publicity / I known it is not good but ... :rolleyes:). If yes, we could discuss more deeply (not only this topic but also much more things).

Thank for your feedback.