Sharp corners
1 Attachment(s)
Hello,
What is the most common way of dealing with sharp corners in a FDM/FVM solver if we have a nodecentered, colocated, approach (i.e. the corner coincides with a computational node). I have implemented the boundary condition in such a way that node A "feel" a vertical wall at C. Node B "feel" a horizontal wall at C. (This is used with the normal momentum equation when calculating the pressure boundary condition) Is this correct? Are there any drawbacks in this approach? Cheers! 
Roache's book, "Computational Fluid Dynamics", has a good section on defining corners.

Quote:
Cheers! 
Roache's section is based on the streamfunctionvorticity set of equations, and one suggestion is to use the value of the wall being used in the computation. That means that, in your diagram, computing from left to right, the value at C would be based on node A first, since the vertical wall would be the first BC, and the when the horizontal wall is the BC it would be based on B.
So, when 0<x<c them point C is based on A, and when c<x<end C is based on B. Make sense? I used that method doing a backwards facing step with good results. 
Quote:
Ok, so this is basically the same approach as I use, except I do not change the value of C, instead I keep it at zero and add it as a source term in points A and B. Alternatively I modify my sparse coefficient matrix to incorporate the boundary conditions. Now my problem is that I can solve cavity flow with my code to very nice accuracy. If I solve flow without internal obstacles I get good results as well. However, if I solve using an internal obstacle I get some (very minor) asymmetries in the solution even though I should not (I think). Flow over a cylinder in 2d gives ok values I guess but I want the asymmetries to disappear. I thought this was related to the treatment of corners. Well back to debugging I guess ;)  Well unless anyone has any additional comments. Cheers! 
when I did the backwards facing step the value of C , vorticity in my example, definitely changed. It was updated each time, and also after each iteration the values were averaged to further take into account nearby node(s)  C in this example. Then, thru the iteration again, which would depend on the nearby/updated node values.
This works are low Re. I tried to incorporate this into a scheme with high Re that would let me see separation at a point, but I couldn't get that to work 
All times are GMT 4. The time now is 14:00. 