[J.H.59]

Hi there,
I'm trying to simulate an acoustic travelling wave in 3D with rhoPimpleFoam and no-reflecting outlets. For that I use a sinus inlet for the pressure and pressureInletOutletVelocity for the velocity and in the outlet waveTransmissive for both ones:

p

inlet
{
type uniformFixedValue;
uniformValue sine;
uniformValueCoeffs
{
t0 0;
amplitude constant 100;
frequency constant 10000000;
scale constant 1;
level constant 101325;
}
value uniform 101325;
}


outlet
{
type waveTransmissive;
value uniform 101325;
field p;
phi phi;
rho rho;
psi thermo: psi;
gamma 1.33;
fieldInf 101325;
lInf 8e-6;
}

U

inlet
{
type pressureInletOutletVelocity;
value uniform (0 0 0);

}

outlet
{
type waveTransmissive;
value (0 0 0);
field U;
phi phi;
rho rho;
psi thermo: psi;
gamma 1.33;
fieldInf (0 0 0);
lInf 8e-6;
}

The temperature is always constant 293.15 K and has zeroGradient as BC. The simulation box has the size of 1e-5 m.

First of all how is the velocity in wave direction with pressureInletOutletVelocity calculated? I thought it would be something like

U = p' / (rho *c)

with the amplitude p' of the wave, the density rho and the sound velocity c. But when I plot the velocity with ParaView I got much bigger values than expected. I just found an description of the BC:

Description
Velocity inlet/outlet boundary condition patches for where the pressure is
specified. zero-gradient is applied for outflow (as defined by the flux)
and for inflow the velocity is obtained from the patch-face normal
component of the internal-cell value.

but that doesn't help much.

Then when I place a sphere with radius 1e-6 in the middle of the box and calculate forces on it they are much bigger than the analytic solution or much smaller depends on which velocity I choose(the one I expect or the one from ParaView). For the calculation of the force I use forcesCompressible with:

CofR 0 0 0);
pitchAxis (0 1 0);
p p;
U U;
rho rho;
pRef 101325;

So I think there is something wrong with my simulation.

Thanks in advance

[lukasf]

Hi Johannis,

I hope you have figured out your question by now.

Velocity and pressure are coupled. Hence, I thought that if you use the zeroGradient boundary condition for e.g. the pressure you have to use a fixed boundary condition for the velocity.

In your case I would adjust the U field to something like:

inlet:

type zeroGradient


outlet:
type pressureInletOutletVelocity;
value uniform (0 0 0);


What do you think about this?

###

I am trying to use rhoPimpleFoam in a different setup but I want to find out how to use non-reflecting outlets. With the current new setting my simulation crashes.


With my old settings pressure waves are reflecting from the outlet in my simulation which leads to nonphysically results. I have a rectangular channel with an inlet and outlet.


I would be glad for any suggestions.

##################
old settings (bad result) :
##################
p:
INLET
{
type zeroGradient;
}
OUTLET
{
type fixedValue;
value uniform 100000;
}

U:

INLET
{
type timeVaryingMappedFixedValue;
setAverage 0;
offset constant (0 0 0);
value nonuniform List<vector> ...
}

OUTLET
{
type inletOutlet; //my idea was to get rid of backflow problems
inletValue uniform (0 0 0);


##################
new setting (crashes):
##################
p:

INLET
{
type zeroGradient;
}


OUTLET
{
type waveTransmissive;
gamma 1.4;
fieldInf 100000;
lInf 20; //length of the channel downstream of the outlet
value uniform 100000;
}

U:

INLET
{
type timeVaryingMappedFixedValue;
setAverage 0;
offset constant (0 0 0);
value nonuniform List<vector>
...
}

OUTLET
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}

[J.H.59]

Hi Lukas,


yes, I solved these problems (almost). You are right, that the velocity and pressure are coupled. My mistake was, that I thought I would simulate in liquid water instead of gas so the velocity of sound is different which explains the bigger values.
I'm not sure how the "zeroGradient" BC behaves if little waves are reflecting but as an inlet this should be fine. But I think since I get little reflectings "pressureInletOutletVelocity" is the better choice (but I'm not 100% sure about this!)


###


I changed my solver to sonicLiquidFoam since I want to simulate water and no gas, but I'm still using such non-reflecting boundaries.


What are the error messages you get when the simulation crashes? I got often calculating errors with rhoPimpleFoam earlier. An error source was the physical properties in the constant file you have to choose. Are there all right in your case?


What I'm using right now is a combination of waveTransmissive and the fvOption acousticDampingSource which is used e.g. in the demo case for acousticDampingSource:


https://www.openfoam.com/releases/op...nd-physics.php


I wrote in another thread how to use it for sonicLiquidFoam but that should be analog for rhoPimpleFoam


BC waveTransmissive in sonicLiquidFoam


I'm still getting little reflections with this combination when the damping starts. But they are really small and are even occurring in the demo case. So I think they should be fine for most cases.


If you have problems with the waveTransmissive conditions you could try to take "fixedValue" for your pressure and make the acoustic damping zone bigger. You have to play a little bit to get the right combination of these.


I hope this helps somehow.


Best regards
Johannes

[lukasf]

Hi Johannis,


I get a floating point exception with my new settings for p and U. Near the outlet the pressure drops in a large area which leads to very high velocities. Hence, the time step is decreasing towards 0 (I have a fixed Co-Number). Probably my lInfy is not set correctly for the simulation.



I have seen your post with the dampingSource. I will consider it but right now I am not sure how to use a circle or sphere like dampingSource to help with my problem at a rectangular outlet.


I am also having other issues at the moment so I do not know right now when I can pursue this particular problem in more detail.


I will tell you about it when I know more.



Best regards


Lukas

[J.H.59]

The reflexions are strongly depending on the lInf value, so that could be a possible source of error.



The problem could also be a bad mesh. I got similar errors (and decreasing time steps) when I built the mesh with gmsh and converted it to OpenFOAM. Then I switched to snappyHexMesh and the problem was gone.