[frubicle93]

I have been attempting to implement "do-nothing" or "traction-free" boundary conditions for outlets in OpenFOAM. This is the condition that

- p n + nu*(n dot grad) u = 0.

I've seen it a lot in theoretical work as it eliminates some terms from the variational formulation of Navier-Stokes (Gresho, 1990), and I think some commercial CFD codes have this as an option.

Has anyone already attempted to implement this BC in OpenFOAM?

It is easy to make this BC starting from the mixed type BC. However, SIMPLE requires more boundary conditions than are required analytically (e.g. zeroGradient pressure at inlets/walls), and I am unsure what to do with the pressure on the outlet patch. If I set p = 0 at the outlet, then the above reduces to zeroGradient. I could set p (or the mean value of p) to any value (which would clearly have a large influence on the result).

[SmileMax]

You can use codedFixedValue to implement any boundary condition you want.

[frubicle93]

Originally Posted by SmileMax

You can use codedFixedValue to implement any boundary condition you want.

Thank you for your reply, Max. However, I don't think codedFixedValue can couple fields as I require. Also, it is a wrapper around fixedValue, so there would have to be some lag in the computation of the normal velocity gradient in the BC.

Implementation of a BC is not the problem, and I have already modified the mixed type BC files to give me what I want.

My problem is to do with the fact that SIMPLE requires more boundary conditions than are required analytically. Analytically, you can solve Navier-Stokes with Dirchlet velocity conditions on some parts of the domain (e.g. inlet part + no-slip part), and with the condition

- p n + nu*(n dot grad) u = 0,

[p=pressure, n=normalVector, nu = kinematicViscosity, u=velocity]

on the rest of the domain (outlet). To get SIMPLE to run, I need to overprescribe the system. Say I use my new BC for velocity. How I choose p at the outlet clearly has a huge effect on what the coupled condition does, when analytically it should be determined as part of the solution.

Is there some error that doesn't converge to zero as the system iterates due to the overprescription of boundary conditions in OpenFOAM?

[Tobermory]

I can see that this could be a real problem for a pressure-correction method like SIMPLE - it's not possible to do a simple one step pressure correction to the velocity for the cells at the boundary, since the boundary pressure field keeps changing as the velocity field (and therefore boundary velocity gradient) changes. And we have lost the U/p decoupling that we can assume for the regular SIMPLE algorithm. You need an iterative approach for each "traction outlet" boundary face to find the boundary pressure and velocity gradient that balance each other, and that fit within the rest of the pressure field for the domain ...

Does the system converge if you make a simple choice of boundary pressure (i.e. start with last iteration's value) and then run multiple pressure corrector loops? This would be rather expensive computationally, ofc, so I wonder whether there is any ultimate benefit in this approach?

Apologies if the above has not been too much help ...

[MamboJambo]

Is this paper helpfull? https://onlinelibrary.wiley.com/doi/....1002/fld.4039 ?

[frubicle93]

Thanks for your replies, I didn't see the notification email. I think I need to have a coupled set of custom BC files that satisfy the traction free BC and also ensure that continuity eqn is satisfied. Haven't had time to play with it recently, however.

[alimokh91]

Hi
Did you find a solution to implement this in OpenFOAM?