CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   Gradients at boundary for NSCBC (http://www.cfd-online.com/Forums/openfoam-programming-development/122393-gradients-boundary-nscbc.html)

fportela August 19, 2013 04:12

Gradients at boundary for NSCBC
 
2 Attachment(s)
Hello everyone,

I am trying to implement the characteristic boundary conditions as formulated by Poinsot and Lele.

For this, I compute the strengths of waves crossing the boundaries and adjust the boundary conditions accordingly.

In order to compute the wave strengths I need some gradients to be defined at the boundary. In the general case, these gradients have to be taken along all directions, so I am avoiding using the surface normal gradient.

Since I can't compute directly the gradients when I am updating the boundary value, I create and store (at each time step) the gradient fields (in the whole domain) that I need. I also noticed I have to update the boundary condition of the field associated with the gradient, and that this field has by default a zero gradient boundary condition.

This all works fine in 1D. However, when I move to 2D, I notice that the gradients at the boundary cells get strange values. For example, if I set up all variables as constant, the gradients will be zero in the interior points, but not at the boundary cells!

Although this value is still very small, I suspect that this is somehow affecting the performance of the b.c. (since it depends explicitly on these values).

Does any one have any idea of what is going on?

Cheers,
Felipe

fportela August 19, 2013 06:02

I forgot to mention that the components of the gradient are only affected in the direction in which they are defined, i.e., gradP.x() is exactly zero at the top and bottom boundaries, but not zero at the right and left.

cosimobianchini August 20, 2013 04:35

Hi Felipe, I did some work on NSCBC in OpenFOAM too ( paper 2012 paper 2011).
If you are interested in the simple original version of Poinsot e Lele you only need gradients normal to the boundary and the implementation should be quite straightforward starting from OpenFOAM waveTransmissive b.c. (only thing is that NSCBC are derived for density based solvers while the majority of OF solver are pressure based).
If instead you want to consider also transversal gradients, only needed in my opinion in case of largely 2D fields close to the boundary, as proposed by Lodato et al. you should look at the implementation of finiteArea discretization and apply these operators to the 2D mesh discretizing the boundary patch.
Concerning your question:
1) you should verify if this imprecision is connected to use of empty patches on the side boundary. go to 3D and verify if you have the same behaviour in the center of the domain
2) if the error remains of the same level in case of more complex variable fields, it will most likely cancel out when summed to non zero quantity. verify defining a known pressure field (i.e. linear profile)
Regards,
Cosimo

fportela August 20, 2013 06:54

2 Attachment(s)
Hi Cosimo,

Thanks for your reply :)

It seems like I don't have access to those papers, perhaps that's why I missed them when looking for previous work on this topic. Perhaps you could e-mail me a copy of the papers?

My (perhaps too ambitious) goal is to use these b.c. on a fully turbulent mixed super/subsonic compressible flow, in particular, I will be testing the b.c. on a supersonic channel flow, for which I already validated the solver with periodic b.c.. I also use rhoPimpleFoam for comparison, though I have found that it's performance is less than ideal for this kind of flow.

I mentioned Poinsot and Lele as it is the most known reference for non-reflecting b.c., however, I directly implemented the compatibility relations as found in the book of Hirsch. I believe this is a similar approach as that of Lodato et al. The boundary update is done on the primitive variables and the solver then handles the computation of the conservative variables (for the viscous part I have to re-write the equations to get the corresponding viscous terms in the equations for the primitive variables).

As soon as I get the inviscid case working fine, it should be straightforward to include the viscous terms (provided they are computed correctly). So my question about the accuracy of the gradients holds not only for the first stage (inviscid case) but also for the when the viscous terms are included.

Regarding your suggestions, I initialised a parallelepiped with all variables constant and saved the the gradients after one time step. It seems like the situation is unrelated to the empty patches: I attached two snapshots of the gradient for pressure (one for the magnitude and one for the x component) after one time step, the fields are all uniform. I am aware that the values are quite small, but I don't understand why they are not exactly zero (since everything is constant).

The non-reflecting conditions seem to work OK on subsonic test case (although some reflections still remain, as seen in droplet.png). I tried the supersonic vortex test case from Poinsot and Lele and I get a lot of numerical reflections (the waves actually travel upstream).

There might be something wrong with my implementation, or maybe something I missed when implementing the compatibility relations. But I would like to be sure that this thing with the gradients is not (negatively) affecting the performance of the b.c.

I also have some questions on the "viscous conditions" (their meaning and how to enforce them), but maybe we can discuss it over pm?

Cheers,
Felipe


All times are GMT -4. The time now is 20:31.