gtspring2009:spieker_blog:near_wall

This shows you the differences between two versions of the page.

— |
gtspring2009:spieker_blog:near_wall [2010/02/02 07:55] (current) |
||
---|---|---|---|

Line 1: | Line 1: | ||

+ | ===== Near Wall studies ===== | ||

+ | |||

+ | **11/16/2009** So I've just started dabbling with [[:research:gibson:wallsolns|near wall solutions]] and I'm having a little bit of trouble. I've basically been experimenting with | ||

+ | |||

+ | couette -T0 0 -T1 400 -P 0.1 ustart.ff | ||

+ | |||

+ | I've been creating random velocity fields with linear combinations of turbulent trajectories and then integrating them with the above line of code. Based on the fact that I **always** get divergences at about time step 6 or so, I feel that I am doing something wrong. | ||

+ | |||

+ | So, after reading the research projects page, I tried something more along the lines of | ||

+ | |||

+ | couette -T0 0 -T1 400 -R 200 -P 0.01 ustart.ff | ||

+ | |||

+ | and that run is going quite a bit longer. I will keep tweaking the parameters until I'm told to do otherwise. | ||

+ | |||

+ | |||

+ | **11/17/2009 JFG ** :-) (great to see you dabbling in this). A few comments: (1) The proper scale for pressure gradient can be determined from the laminar solution for channel flow (//both// walls fixed at u=0 and flow driven by pressure gradient). This solution is //u = U(1-(y/h)^2) e_x// and // p = -2 nu x// or //dp/dx = -2 nu//(darned dokuwiki greek-enter tool doesn't have a nu character!) where U is the max velocity at the center of the channel. Define the Reynolds number //Re = Uh/nu// and rescale the variables to get the nondimensional solution //u = (1-y^2) e_x// and //dp/dx = -2/Re//. So this tells us that, to get a pressure-driven velocity of the same magnitude as the laminar velocity of plane Couette flow (scale of u=1 for walls moving at +/1), we should add a pressure of //dp/dx = -2/Re//. For //Re=400// that's //dp/dpx = -0.005//. Choose something smaller than this to perturb plane Couette flow and simply break the symmetry. (2) Again, you mean large CFL numbers rather than "divergence"! In fluid mechanics "divergence" without further specification means the divergence of the velocity field ∇⋅u. | ||

+ | |||

+ | ** 11/17/2009 DWS ** (2) I'll call it by it's correct name from now on ... sorry. I was wondering if there was a reason that I don't have the permissions to see the [[http://www.channelflow.org/dokuwiki/doku.php/research:gibson:wallsolns|Near Wall]] write up page. Is that one of the projects that you were keeping between yourself and other collaborators? | ||

+ | |||

+ | ** 11/18/2009 JFG ** Sorry, that's just a permissions bug. I'll fix it. I forgot to explain the large CFL number and subsequent blow-up above: Setting //dp/dx = 0.1// would lead to a laminar solution u = 20*(1-y^2) if laminar were stable, or about 1/3 that magnitude when the unstable laminar solution goes turbulent. That causes the CFL number to go way above 1.0 with the given time step. CFL is essentially a ratio between the magnitude of the velocity u and the gridspacing/timestep ratio: //CFL = |u|/|Δx/Δt|//. Crudely, //CFL > 1// means that the flow moves fluid from gridpoint //x_n// **past** gridpoint //x_{n+1}// in one time step Δt. When this happens certain jagged solutions to the discretized equations (that have nothing to do with the continuous equations they're modeling) become unstable and grow exponentially in time, swamping the true solution and leading to blow-up of //|u|//. So setting // dp/dx = 0.1 // causes |u| to grow to 10 or 20, which causes CFL to go from 0.50 to 5 or 10, which causes high-order jagged solutions to become unstable and grow exponentially, leading to blow-up of //|u|//. This is something you should understand well, so if you have questions let's talk. Any book on numerical approximation of PDEs should discuss the CFL number, though I have not yet found a really good introductory explanation. The trouble is that the exact definition of the CFL number depends on the numerical discretization method and the underlying PDE in complicated ways. | ||

+ | |||

+ | ** 12/07/2009 DWS ** A few initial, quick questions about near wall solutions. I have already integrated a velocity field with a pressure gradient. Now, I would like to look for solutions with a pressure gradient. In order to do this, I believe findsoln.cpp will have to be changed so that the user can pass a desired pressure gradient to it. Here is findsoln.cpp as it is right now: | ||

+ | |||

+ | dnsflags.constraint = PressureGradient; | ||

+ | dnsflags.dPdx = 0.0; | ||

+ | |||

+ | and here is what I have changed in it to hopefully allow user manipulation of the pressure gradient: | ||

+ | |||

+ | dnsflags.constraint = PressureGradient; | ||

+ | dnsflags.dPdx = args.getReal("-dPdx","--pressuregrad", 0.0, "Impose this pressure gradient"); | ||

+ | |||

+ | - Will this change be effective in the aim that I had specified above? | ||

+ | - In other pressure driven flows (pipe, duct), there are only traveling wave solutions, and this is because there is no translational phase breaking symmetry to keep traveling waves fixed. Will that be the case when we break the σx symmetry with a pressure gradient in PCF? Namely, will there be equilibria in the pressure driven case so that I know what to search for? | ||

+ | |||

+ | **12/07/09 JFG **. That proposed change to findsoln.cpp looks correct, and I agree that there should only be traveling waves in pressure-driven plane Couette. You'll need to search for close recurrences with the wavespeed as a free parameter. I have a utility tha does that, closereturn.cpp, but I don't think I've committed it to svn yet. Will check, document, and get back to you. | ||

gtspring2009/spieker_blog/near_wall.txt · Last modified: 2010/02/02 07:55 (external edit)