[maka]

I'm running a channel case, driven by specified pressure gradient with mesh 128x48x64 in xyz (8 PI , 2, 2 PI), stream-wise, wall-normal, span-wise.

I started by field generated by perturbU. The periodic pressure increases from 0 to 130 in 2e-02 dimensionless time unit (10 time steps). Re_tau = 150.

Is there a possibility that this is due to: system/fvSolution: RefCell?

PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 0;
// mesh-dependent part
pRefCell 3073; // (128x48)+1 problems if coupled boundry see forum.
pRefValue 0;
}

I attach log file. LOG Thanks.

best regards,
Maka

[maka]

I noticed that near the periodic inlet there is a huge jump in pressure or order 100. But this is only in the inlet. Can the choise of pRefCell, being near this boundry, cause this big spacial gradient of p? The scale of pressure goes through 100 dimensionless unit which is strage.

best regards,
Maka

[eugene]

Not likely. The code will complain if it finds the ref cell next to a coupled boundary. Could you post a picture or something to illustrate what you are trying to describe?

I take it you are running a modified channelOodles code? Your log file is not very informative.

[maka]

yes, I'm running a modified channelOodles without any subgrid model (DNS) and with energy equation (using Boussinesq assmp.), my formulation agrees with Henery comment on the following message:
http://www.cfd-online.com/OpenFOAM_D...ges/1/815.html

I attach pictures of Umag, p, T at the very early stage of transition from laminar to turbulent, time 0.02 and 0.08 and 19 with time step 0.002. I think that the value of pressure grow so fast because, I have done a DNS of isothemal flow at the same Re and it was not near that. The Grashof number is almost 10^5.

here are the pictures:















early Temprature is like initial condition = 0.5.

Thanks for trying to help.

best regards,
Maka

[eugene]

Your pictures dont appear to have taken.

[maka]

I can see the picture now in my previous message, can you?

[eugene]

Yep, in glorious colour.

The low pressure artifact near the inlet is quite pronounced. Seeing as its location appears to be constant it probably has something to do with the way your code interacts with the reference cell.

I'm guessing, but switching off the buoyancy term probably gets rid of the problem?

In any case, there are several possible reasons for this:
1. The aforementioned interaction between the buoyancy term and the reference cell. Have a look at buoyantFoam to check for differences of reference pressure implementation. Put your reference cell away from the boundary. Currently it is very near the inlet.
2. wall pressure boundaries are not zero gradient in a gravity field. Make sure you are using wallBuoyantPressure instead.

[maka]

I changed the boundary condition from zeroGradient to wallBuoyantPressure and I got the following error message.

It seems that the b.c. is expecting a rho to be a calculation variable. How can I let this b.c. deal with Ui, p, T formulation. What is physical meaning of wallBuoyantPressure? I would be grateful if you can suggest a reference or provide a simple description. Many thanks for your help.

--------------------------------------------

Starting time loop

Mean and max Courant Numbers = 0.0718929 0.761134
Time = 0.002

BICCG: Solving for Ux, Initial residual = 0.00220446, Final residual = 2.14008e-06, No Iterations 2
BICCG: Solving for Uz, Initial residual = 0.0620016, Final residual = 1.5716e-05, No Iterations 3


--> FOAM FATAL ERROR :
request for volScalarField rho from objectRegistry region0 failed
available objects of type volScalarField are

8
(
p
T_0_0
div(phi)
ddt0(T)
nu
1|A(U)
T_0
T
)


From function objectRegistry::lookupObject<type>(const word&) const
in file /home/maka/OpenFOAM/OpenFOAM-1.2/src/OpenFOAM/lnInclude/objectRegistryTemplates. C at line 122.

best regards,
Maka

[maka]

this is using OpenFOAM V 1.2.

[maka]

I switched off the buoyancy term, and the problem is much less than before but this was using zeroGradient for wall pressure b.c. The spacial pressure difference increases with time.

I notice that in the previously attached log file the global conservation of mass dropped from 10-17 to 10-7 in one iteration between 0.002:0.004 time. This is not the case when I switch off the buoyancy. I also tried to keep the buoyancy and move the refCell to some place inside the channel, I got the same effect as switching off the buoyancy (the problem reduced and no drop in global conservation of mass). But this was the case for serial run, when I switched to parallel (8 processor), I tried different places for refCell but, it is challenging to find a place that is not on a constrained bounday and reduces the previous problem at the same time.

I would be grateful if you can explain:
a) why do we need to set and unset the refCell every iteration?

b) How does it affect the pressure field value?

I tried to look at fvMatrix.H but it is not clear for me as a beginner.

I also looked at buyantFoam, to see how the formulation in pd (pressure difference) is done but it uses a compressible formulation which I'm not familier with. I only derived the boussinesque formulation.

c ) will using pd free us from specifying this refCell?

Finally, I would be thankful if one comments on:

d) the above error, regarding using wallBuoyantPressure.

best regards,
Maka

[eugene]

I just wrote a lot of stuff and then looked at your additional term:

+ g*alpha*(T-TRef)

According to this it is incorrect:
Boussinesq

And I think you will still have to specify the pressure gradient at the wall.

Also, if you are using 1.2 then the check for a ref cell adjacent to a coupled patch might not be in.

[maka]

in the link you refered to, g is a scalar so the term must be on the right hand side with the following form:
+ g*alpha*(T-TRef)

but in my case g is a vector (gi) that alow for -ve sign (the defult sign is +ve) so the term must be on the right hand side with the following form:

- gi*alpha*(T-TRef)

for gavity to be downward where the hot surface:

gi=[0, -1, 0]

both forms are equivalent.

If we also check the temperature pic. above, we can see the thermal plumes goes in the right direction.

And I think you will still have to specify the pressure gradient at the wall.

I do not disagree, just I do not know what is wallBuoyantPressure? how can I modify the wallBuoyantPressure to accept temperature formulation instead of rho, you may see the above error message.

Also, if you are using 1.2 then the check for a ref cell adjacent to a coupled patch might not be in.

coupled patch like processor boundries? I noticed that when the code is run in parallel, I get no complain about constrained boundary while, I get it for the same case when run in serial. Unfortunately, I can not move to V 1.3 now since, I will have to solve some installation problems and retest my modifications.

I would be grateful if you can comment on my above questions a) to d) Thanks for your help.

best regards,
Maka

[eugene]

a) I used to know...

d) Because you don't have a rho volScalarField defined and the wallBuoyantPressure BC assumes that you do.

To your other comments:
1) I was referring to the "gz" term not the change in the temperature dependent term.

2)Normally we take snGrad(p) on the wall = 0. When you are running a buoyant solver this is no longer the case. The pressure gradient at the wall should be finite and proportional to the buoyancy force. Take a look at the wallBuoyantPressure implementation $FOAM_SRC/finiteVolume/fields/fvPatchFields/derivedFvPatchFields/wallBuoyantPres sure/wallBuoyantPressureFvPatchScalarField.C
I cant help you more than this.

3) Just change the reference cell to a number that is not an integer (or +1) of the number of cells in the x and y directions.

[maka]

the p in formulation that I use is a redefined pressure (dynamic pressure) p = p0 + g y (in case of g is scalar in the -ve y direction) or in a general tensorial form, p = p0 - g_i x_i, where g = [0, -1, 0]. That is why gz does not show in the formulation. Actually, that is why also gravity term does not show in momentum equation for isothermal flows, because the pressure is redifined.

I agree with you perfectly about the wallBuoyantPressure where, snGrad(p) is balanced by buoyancy term, which is clear by considering laminar flow equations for a horizonal buoyant channel. I did not notice that before, thanks for making that clear to me.

Best regards,
Maka

[Edy]

Hi Maka,

I am having the same kind of problem with the wallBuoyantPressure B.C.. Actually, I am using OF 1.7.x, and it seems that this BC has been renamed buoyantPressure but the principle is the same.

How did you finally set your value for the pressure gradient?

Besides, a rho value is expected from this BC, and i dont have any rho. What does this rho represent, which density? How did you solve this problem?

I would be very grateful if you could help me on that.
Thanks in advance.

/Edy