[coops]

Hello,

I have recently been playing with the forwardSetp case using the sonicFoam application. I have changed the meshing to suit the case I am interested in but when I do this I want to specify a zeroGradient boundary condition. I attempt to do this for U (changing the patch from symmetryPlane to zeroGradient) and I get the following:

Calculating field e from T

Reading field U



--> FOAM FATAL IO ERROR : inconsistent patch and patchField types for
patch type symmetryPlane and patchField type zeroGradient

file: /home/shaun/OpenFOAM/shaun-1.3/run/editting/forwardStepmeshing/0/U::top from line 52 to line 52.

From function fvPatchField<type>const fvPatch&, const Field<type>&, const dictionary&)
in file /home/shaun/OpenFOAM/OpenFOAM-1.3/src/finiteVolume/lnInclude/newFvPatchField.C at line 137.

FOAM exiting

What is happeing here and how can I fix this problem.

Thanks in advance,

Shaun

[mattijs]

Simple: a symmetry plane patch type needs a symmetry patch field type.

[coops]

Hi Mattijs,

What you have said makes sense, my question is, where is it in the case is it defined to be a symmetry plane patch type? Symmetry plane patch type is not mentioned in the blockmesh file, it is only in the initial fields files.

Does it have something to do with the application (sonicFoam) being used?

Thanks

[mattijs]

Check your boundary file (constant/polyMesh/boundary). It might have preserved any settings from FoamX. Delete it and rerun blockMesh.

[coops]

Hi Mattijs,

Once I deleted the boundary file and rerun blockMesh it did allow other boundary conditions.

Thanks again

Shaun

[ralph]

Hello,
I want to simulate the flow around an airfoil.
The flow is incompressible.
The computational domain I used so far is of rectangular shape with the airfoil placed inside.
As boundary conditions I used:
inlet: fixed velocity
outlet: fixed pressure
airfoil: wall
sidewise domain bound: slip

The simulation showed that the domain was too small to model a farfield.

To avoid extending the domain I asked, if there is a kind of farfield boundary condition available.
Are the "freestream" and "freestreamPressure" boundary conditions suitable for that kind of problem (instead of using the slip condition)?
Is there a better choice as the fixed pressure at the outlet (in order to avoid extending the domain)?
Can anyone give me a hint?

Thanks in advance

Ralph

[dmoroian]

Hi Ralph,
Unless you don't have a specific request for the solver, I would recomend you a different approach: a boundary layer method is much cheaper and usually more accurate than RANS.
An open source software that implements such a method is called XFOIL.

Dragos

[ralph]

That´s not quite what I´m looking for Dragos.
But thanks for the hint.
I intend to further use OpenFOAM with a (U)RANS approach.
I got quite familiar with this code and am pleased with it´s capabilities.
The analysis of the airfoil should be the basis for further investigations with an (U)RANS approach.
I´d be thankful for further hints concerning the boundary conditions.

Ralph

[ralph]

Hi all,
by further looking at the boundary conditions I got a little more insight.
But there are still two things I don´t get.

1) I think to know what a inletOutlet is.
But what is the derived boundary condition freestream?

2) When an inletOutlet switches between inlet and outlet, what does a outletInlet? (isn´t it the same?)

Is one of both BC´s suitable for the farfield boundary of an external flow?

Ralph

[hjasak]

The idea of inletOutlet is that the boundary condition will change its behaviour based on the direction of the flux on the boundary. Thus, if the flux is going in on a face, the b.c. acts as fixed value; if it is going out, it acts as zero gradient.

outletInlet will (of course) do the exact opposite.

Enjoy,

Hrv

[ralph]

Thanks Hrvoje,
could you also tell me what the freestream condition is?
It is derived from inletOutlet.

Ralph

[maka]

Base - numeric(primitive, derived)- physical type b.c.

I went trough the documentation to understand the difference between the above boundary types. I came up with the following. I will be thankful if you can correct me:

1) physical type (optional): only affects the way FoamX works but has no effect if you are editing the files manually (as I do). I tried to specify any invalid name in front of physicalType and solver did not complain. Specified in boundary file.

2) base type: only affects geometrical or data communication functionality. Also wall is need by wall functions. Specified in blockMeshDict or boundary file.

3) numeric (primitive or derived): are needed by numerical algorithm that works on the fields. Specified in Field file.

4) base and numeric type has to match in case the base type was "symmetryPlane" or "empty". otherwise, they can be different.

Problem:
5) changing patch type in blockMeshDict and rerunning blockMesh will not update boundary file content (if the file already exist) but will update its access date. As a result the computation will not be affected by such change. blockMesh will print no warning about that and will not check the validity of new patch type.

The change is blockMeshDict is only effective if:

1. we change, for example the number of cells and the patch type, then boundary file will be update successfully.
2. we remembered to delete the existing boundary file.

Should this be reported as a bug?

Thanks in advance!
best regards,
Maka

[hjasak]

Nope - it is done deliberately to preserve boundary types in FoamX. Just delete the boundary file, run blockMesh and all will be well.

Hrv

[hjasak]

Both derived from basic symmetry, ie. doing the same thing. You can hook up slip on any kind of patch (e.g. for a slippery wall) whereas a symmetry plane is a geometrically enforced type.

Enjoy,

Hrv

[marhamat]

Hello everyone
One basic quastion

In N.S equation we see laplacian of velocity and gradient of pressure .So with 3 boundry conditions (2 for velocity&1 for Pressure )the equation must be solved.

But in OpenFOAM the condition of Velocity&pressure in inlet&outlet must be realized.

This means 4 boundry conditoin for NSE.

How this has justified?

[marhamat]

I mean that for solution flows such as pipe flow by imposing velosity in inlet&wall and pressure in inlet we can reach to result(such az velociy in outlet and pressure in wall&outlet) .
But in OpenFOAM in each boundry the condition of velocity&pressure both must be realized.
For example if we impose wall to wall boundry condition then velocity is fixed & pressure gradient is zero.
How this has justified?
Really i want to know can i make new boundry condition that condition of pressure in wall be unknown ?(and in similar cases in other boundries)

Thanks alot
Marhamat

[marhamat]

Hello everyone
Sorry for frequent questions

The conception of boundry condition in FOAM isn't clear for me.

For example when we impose wall to wall boundry condition then velocit value & pressure gradient are zero in this boundry .

What means zero pressure gradient.

What happens if we don't impose it to wall?

This means the result after convergence gives pressure and it's gradient in wall.

Assume that in pipe flow we make boundry conditions that in it only pressure&velocity in inlet &velocity in wall &velocity gradient in outlet are known.

And assume in another case we impose inlet to inlet boundry condition that in it velocity value is know & pressure grdient is zero and wall to wall and inltOutlet to outlet boundry condition that in it pressure value & velocity gradient is known.

1)Can we make the first case boundry conditions in OpenFOAM?
2)Do results differ in case 1and 2?How much and why?
any help is useful for me

Best regards
Marhamat

[maka]

consistency check between patch and patchField type:

such consistency check does not always work. There are two cases to consider:

a) when symmetryPlane, cyclic, empty (I have not tested wedge or processor) is specified in "blockMeshDict " but other type in field file (for example, Fixed value):

the check only works in case of symmetryPlane.

b) when symmetry, cyclic, empty (I have not tested wedge or processor) is specified in "field file" but other type in blockMeshDict (for example, patch):

The check works in all cases.

I tested that in cavity tutorial case.

IMPORTANT Note: Do not forget to remove "boundary" file every time you modify blockMeshDict if you want to test such effect.

As a result one can modify boundary condition in field file and run a computations that seems to ignore such modification. Actually, one can ask which of the two condition will override the other? I noticed that the geometrically enforced one (defined in blockMeshDict) does overrides the field b.c. Is that always the case?

Is that a big or it works this way for a reason that was not obvious to me. Thanks.

Best regards,
Maka

[aderliner]

Hi， everyone

I've find a "turbulence inlet" boundary condition in the solver oodles and Xoodles, but, if I want to use this boundary condition in another solver which does not have the choice,"turbulence inlet", in FoamX, what should I do?

Thanks~~!

Bobby

[maka]

Is that a bug?

In the above message 23 March 2007,
"Is that a big or ...". :-) I meant is that a bug. Sorry for the typing mistake.

Best regards,
Maka.