groovyBC: using gradientExpression instead of valueExpression
 

Hello,

I am attempting to emulate a BC using groovyBC. I require pure Neumann BC's and so I believe I should employ gradientExpression rather than valueExpression? By simply changing fractionExpression simply to "0" does this mean I do not need to specify valueExpression given what is mentioned here about the use of valueExpression and value?

http://openfoamwiki.net/index.php/Co...s_in_the_patch

As in I specify the gradient at the boundary and let the value be solved for (initialised with uniform 0 or whatever).

Any help would be very much appreciated.

Cheers,
Greg

whats wrong using standard BC like fixedGradient or zeroGradient?

I require near-periodicity, that is very similar to a cyclic BC but with a specified pressure difference across the domain.

did you see fan boundary condition it is a like cyclic with the difference pressure

It seems to me that the cyclic fan applies the pressure difference across a patch given what I've read here:

http://www.tfd.chalmers.se/~hani/kur...ningReport.pdf

I require the pressure difference from inlet to outlet across the domain not at a specific location. The flow in my problem is driven by a moving wall where the pressure and velocity profiles are specified at inlet or outlet as a result of periodicity and a pressure difference. Can I achieve this with cyclic fan BC's at both inlet and outlet?

You're right. Setting fractionExpression to 0 makes groovyBC use only the gradientExpression (basically groovyBC is a wrapper around the standard mixed BC)

The business with value vs valueExpression was a bit confusing in the section you mentioned due to a misformatting. Basically value is only used as a standin in certain situations where for technical reasons valueExpression can't be used

Excellent, thanks.

Does this mean that when using gradientExpression the variable specified by value is the gradient for the 1st iteration or the actual value for the 1st iteration? I require zero here in either case so probably best to leave out value unless I get an fpe?

when you specify a fan boundary condition, you have to specify the neighbor patch for each of the patch you have declared as fan. Eg:
inlet
{
type cyclic;
nFaces 240;
startFace 62080;
matchTolerance 0.0001;
neighbourPatch outlet;
}
outlet
{
type cyclic;
nFaces 240;
startFace 62320;
matchTolerance 0.0001;
neighbourPatch inlet;
}
It will then apply whatever pressure drop you mention between inlet and outlet. i.e Poutlet-Pinlet = specified value. So I believe fan BC should serve your purpose even though the two patches are separated by a distance.

Thanks for the reply, unfortunately I need more control over the solution than the cyclic fan BC seems to provide. Probably should have mentioned that I am looking into a Fluid Structure Interaction problem where eventually I will be scaling velocities at inlet and outlet according to strain (deformation). Effectively I need access to the nodal values of velocity and pressure at inlet and outlet so that I can apply my CFD BC's. This is the reason for my enquiries into groovyBC.

Whether groovyBC might help you with your problem depends on where the "source" of the deformation comes from (patch on another mesh for instance) and whether that deformation is uniform. The problem that you might have is that groovyBC supports getting values from other patches (even from other meshes), but you can only use a uniform value on the "target" patch (for instance: the average displacement on the "other" patch). The reason why a general mapping from one patch to another isn't implemented is not so much that the mapping is difficult to do, but to find out (or let the user specify) whether a mapping is appropriate at all

Hi, Bernhard!

I had a look into the Examples/groovybc folder looking for an example of gradientExpression but I did not find anything that helps... the point is I would like to set the next BC:

"normal()&grad(J)=-h&k", being h and k vectors.

Up to the moment I tried unsuccessfully:
What do you think?? Thanks in advance!
Best!

What do you mean with "unsuccessfully": the gradients are not set the way you expect them to or the simulation does not behave the way you think it should? Best way to distinguish these two cases is to look at the first timestep that is written to disc. There the BC should have additional values: refGradient would be the result of your expression etc.

Hold on: "grad(J)". That works? Anyway. The thing you want (gradient of J in normal direction) would be done better with "snGrad(J)"

Hi again and thanks for your reply!! I mean with unsuccessfully I don't get the result that I should... Well, I had a look to the refGradient part in my first written time step and it's not right... So, could you tell how to set this BC with groovyBC ("snGrad(T)=-h&k")??

Thanks in advance!!
Best!

In OpenFOAM on patches "gradient" always means "gradient in the direction of the surface normal" not "gradient in general cartesian coordinates". So an expression "-h&k" should be sufficient (sign may be wrong)

Hello everyone
I need set a boundary condition similar to maalan's:
It is a outlet boundary condition for ephi:
where ephi is a volScalarField,U means velocity,M is a constant volVectorFiled, and n is the normal vector.

I set it as:
But the calculation became divergence after some step times.

I think the problem lies at this boundary condition because when I change the boundary condition to :
everything goes well.

I am not sure can I set the boundary using GroovyBC since U is a variable I need solve.

Thank you for your suggestion!

regards!

bryant

Well. groovyBC only enables you to set BCs. Whether they are stable is not its responsibility. Especially gradients are tricky. Because if you have high gradients then the solution might "overshoot" what makes physical sense. The trick then is usually to switch to fixedValue (the standard heat transfer-BCs in OpenFOAM do that all the time). I discussed the problem of the overshoot with somebody else a couple of weeks ago on the Forum so I'm not going to go into that again