Hi,

I am using cartesian cut cell mtd to solve for the incompressible NS eqn. At Re=20,40, I managed to get very good ans for the drag coefficient for flow past a cylinder. However, at Re~300 and above, the solution explodes after around 50 time steps. I'm using CN2 discretization.

I've tried reducing time steps and changing the grids but to no avail. Hence, I believe I must have made some errors in my code and I'm trying to single out the possible cause.

So what could be the source of the error? Is it most likely due to diffusion terms, convection or the pressure correction eqn? Or is there something else which I've missed out....

Tks!

Hi,

Could I ask firstly: I wonder if you wrote the cut-cell code yourself?? Is it 3D?? If so could you point me in the direction of the references you 'actually' used/found useful in writing a cut-cell method?? What type of geometry definition do you read in, solid model, stl step??

I'm looking to move into this type of area, and wanted to get an idea of the useful literature. I've done some extensive reading, but so far have not found any papers that could allow me to actually start writing lines of code...

In answer to your question: At a higher Re, there will be a larger velocity gradient near the wall. I'd look at your wall boundary condition, I assume this is laminar flow?? Possibly it something simple like you're not properly enforcing zero mass flow through the wall. What do you mean by blow up? What variables go mad, where? Near the wall, in the free stream, in the wake, at the front of the cylinder???

Like I say any references would be appreciated.

Andy

I'd start by determining which terms in the NS equations start the blow-up first. Viscous, convective, pressures? Then take a close look at your coding of those terms. And, as suggested by 'cut cell', you'll want to see how the BC's are applied to those terms. Beyond that, I don't know.

Good luck.

I'm using the mtd by M.H. Chung in Computers & Fluids 35(2006)607-623. Also can look at ref by Mittal, Ye. T in J.comp physics.

I stopped the simulation when it exceeds u or v=5. It seems that some fluid are going into the solid, although such things doesn't happen at Re<200....

I should imagine at a lower speed, viscous effects are enough to stop, 'visibly' the flow going into the solid, but I will bet it is. The code at these speeds does not care about the mean velocity, so I'd say there is a bug with enforcing zero mass flow at the wall, which will be there in all case but only visible at higher speeds. Also look at the way you set pressure at the wall.

One thing to try is change the wall boundary condition, if it's easy to do so, to just attain a slip wall. i.e any speed you like along the wall, just no flow through, it's possible that may highlight your bug. Also try setting the viscosity, again since you've not said I assume the laminar, to zero, and see what answer you get....

Thanks for the references. If you think of any others let me know. You didn't say if it was 3D??

If your method fails beyond a certain Reynolds number it's conceivably related to the instability of the real flow (I think we had similar discussions before). Reynolds number 300 is about the critical point where the wake becomes inherently three-dimensional and turbulent. Are you modeling those effects? If not, you may simply see a failure of your code to produce a flow that does not exist. Increasing grid resolution and time resolution would not help in this case (it would actually hurt!).

However, even if your solution diverges, the boundary conditions (e.g. zero velocity at wall) should still be satisfied until your numerical errors get extremely large.

I have to say that I can't quite agree with an Re above 300 being turbulent flow behind a cylinder, I'm thinking book by Schlichting. Also if you do, or are, already running this as time dependent then there is a massive field of research that would say as you move to a higher grid density and time accurate marching, then you are in fact tending to their field, of implicit LES. Where you ignore the sgs terms and favour a well resolved time dependent laminar calc - not saying it's correct, I in fact solve a one-equation model for the sgs turbulent kinetic energy, and do not buy 'implicit LES' as it's termed, but non-the-less I'd be careful about that statement.

To the original poster:: I'd continue checking for bugs, given the above, which is correct, it's highly unlikely that you code would become unstable, and if anything it's just a (very) poor man's LES...

I am not sure good old Schlichting is the best reference in this case. Experiments on cylinder flow at such Reynolds numbers are not as simple as they may seem, and there is a wealth of information available from fairly recent experimental results. Check, for example,

Fey, "A New Strouhal-Reynolds-Number Relationship for the Circular Cylinder in the Range 47<Re<2e5", Physics of Fluids, Vol 10, 1998

or

Norberg, "Fluctuating Lift on a Circular Cylinder: Review and New Measurements", Journal of Fluids and Structures, Vol 17, 2003

to get an idea of the variety of vortex shedding modes (2D versus 3D, laminar versus turbulent) for the flow over a circular cylinder.

On resolution: Sure, if the real flow is indeed 2D, then you may expect to get good results if your scheme is able to produce a DNS solution (or at least quasi LES) as dx and dt go to zero. The problems are: a) the flow in that Reynolds number regime is simply not two-dimensional (check the references), b) before you get to an accurate solution you will see your convergence get worse.

Starting from a fairly coarse grid and large time steps, you might actually get a converged solution because on a coarse grid you have a lot of numerical dissipation which acts as a damper on the physical instability. Now, when you increase the resolution, you may actually see your convergence become worse: As your solution becomes more accurate, it picks up the physical instabilities and if you don't model the physics it may not converge (like a laminar flow model for high Reynolds number flow over an airfoil will not converge well). I know, it seems counter-intuitive, but this kind of situation is not a failure of your code, but a result of an insufficient model. If you keep increasing the resolution, you may indeed get to a point where you get a good solution, when the grid and time steps are fine enough to really resolve the physics without turbulence model (and it should be 3D). However, in case of turbulence (which is inherently 3D anyway), you'll have to have an extremely fine grid to even get a quasi LES solution.

I am not saying that the above scenario is the >only< reason why you're seeing problems, but it will strongly contribute to any bugs you may have in your code. Even without bugs, there will be a Reynolds number above which your code simply won't work, unless you use the appropriate resolution for that kind of flow, or some kind of model.

Anyway, even if this is not the case here (we haven't heard if you actually apply 3D and a turbulence model) it's always good to know what you are dealing with, reading up on the flow you are trying to simulate so you don't get any nasty surprises. The above references include a lot of data that you may use to test and validate your method.

Sure, I was really trying to let the original poster know, that given the information he gave us, the problem area is more than likely a boundary condition problem. And that he shouldn't now go off and spend x-months writing a turbulence model, with all the tricks required to keep them going like point implicit and time scale bounds, only to come back and find that his code does still not work... In this case, in debugging, more physics is not necessarily better.

And yes, your answer is more correct in terms of whether this is transitional flow or turbulent flow. BUT, I can tell you that if your code dies, solving turbulent flow, with a laminar code, rather than just giving you crap, then you code is not correct. Full stop. Instability is the flows problem at high RE, and there is no reason why a code will die due to this. It may not give you the right answer, but then again, turbulence as you pointed out is 3D, but I and everybody else can run my code in 2D can get an answer, the answer is approaching wrong if not crap, but the instability in the flow or its spatial dependence should not effect the stability of the code, not at this level of flow physics, i.e non-existent mach number and low/non-existent turbulence. I would suggest you look at the DNS world if you believe that 3D turbulence demands 3d codes....

In fact anybody who's coded a turbulence model, will know that that getting them to stay stable is bloody hard.

So I say again, forget flow instability, or lower the Re number until you still get unstable calculations but are within a 'laminar' like regime, and check your boundary conditions!!!

Once that works, I'd come back and read the previous post to find out if you should be treating the flow at Re=300 as turbulent or laminar, or transitional...good luck with the latter if that's the case.

--

>Instability is the flows problem at high RE, and there is no reason why a code will die due to this

That's not correct for all flows and codes. You are speaking for yourself, but you don't know if that's the case with zonexo's method. Everyone with experience on a variety of numerical schemes and flows will tell you that flow instabilities (like turbulence, separation, unsteadiness) can result in convergence problems if not properly modeled, and so it should at least be considered, i.e. avoided before debugging the code.

Yes, some codes will still converge to some unrealistic solution, but other codes may rightly fail. It's a question of robustness. Some codes are made very robust, and I wouldn't be surprised to get a "converged" result for even outrageously ill-posed problems. For example, commercial codes "have to be" that way to be kind of "fool proof" in the sense that it's preferred to get an unrealistic solution rather than no solution at all (I don't agree with that). Robustness usually comes as a trade-off to accuracy. More accurate research codes are often also more sensitive.

I agree with the ultimate advice, though: Try Reynolds numbers between 47-180 to stay away from turbulence and 3D wake structures (for simplicity), and debug your code for these kosher conditions. That's my bottom line.