# RiverVortexTest

### From Gerris

Revision as of 01:02, 20 May 2011Tdivett (Talk | contribs) ← Previous diff |
Current revisionPopinet (Talk | contribs) (→Summary) |
||

Line 425: |
Line 425: | ||

It is important to drive the flow through the channel with a pressure gradient rather than a velocity boundary condition. With larger arrays that partially block the channel, the dynamics of the channel change and the turbines extract energy from a lower velocity flow with a strong pressure gradient across the turbine. | It is important to drive the flow through the channel with a pressure gradient rather than a velocity boundary condition. With larger arrays that partially block the channel, the dynamics of the channel change and the turbines extract energy from a lower velocity flow with a strong pressure gradient across the turbine. | ||

- | Here is my single turbine parameter file and output to compare with Euler. | + | When I drove the flow in the channel with a pressure gradient across the boundaries in the 2D NS solver I got large reflections from boundaries. We also decided that depth averaging was a better approximation than a 2D NS for looking at arrays of turbines because the 2D NS solution assumes the domain is the same at all depths which is not true for a 20m turbine in 50m of water. |

+ | |||

+ | Here is my single turbine parameter file and output to compare with Euler. I use Umax = 2ms^-1 and speed up the tide so FM2 = 4470 s. | ||

<source lang=gfs> | <source lang=gfs> | ||

Line 550: |
Line 552: | ||

1 2 right | 1 2 right | ||

2 3 right | 2 3 right | ||

+ | </source> | ||

- | . | + | Output at t = 1117 s. Note, I speed up the tide by a factor of 10 to get reasonable run times for large arrays of turbines. At 350 s the wake hasn't developed much. I think the ocean and euler result look fairly similar. |

- | </source> | + | {| align="center" |

+ | |+ Zonal speed (colour). | ||

+ | |- | ||

+ | | [[Image:OceanSingleU01117.png|thumb|400px|center|Ocean]] | ||

+ | | [[Image:Euler_3500_0.png|thumb|400px|center|2D Euler]] | ||

+ | |} | ||

+ | {| align="center" | ||

+ | |+ Height (colour). | ||

+ | |- | ||

+ | | [[Image:press01117.png|thumb|400px|center|Ocean]] | ||

+ | | [[Image:Euler_3500_1.png|thumb|400px|center|2D Euler]] | ||

+ | |} | ||

{| align="center" | {| align="center" | ||

|+ Vorticity (colour). | |+ Vorticity (colour). | ||

Line 590: |
Line 604: | ||

fact that the model response is ultimately unstable suggests that these models | fact that the model response is ultimately unstable suggests that these models | ||

might be over-estimating that potential. | might be over-estimating that potential. | ||

+ | |||

+ | :''This is not a "model-dependent" problem (in the sense "numerical model"). What ultimately controls how many eddies are present is the balance between eddy creation and dissipation. Both are controlled by the model used for the viscous dissipation (in the sense theoretical/physical/mathematical model). At the moment these simulations assume that the only friction is through some parameterisation of bottom friction. This bottom friction is too small outside of the turbine area (or equivalently the spatial resolution is not high enough) and the simulations are thus essentially controlled by the numerical dissipation (hence the sensitivity of the results on the detail of the model used: advection scheme, limiters etc...). When averaging the Saint-Venant equations vertically, dissipation appears in two ways: a first term which is essentially the vertical average of the horizontal components of the viscous terms, which will look like an equivalent 2D viscous dissipation. A second term which is a vertical average of the viscous terms linked to the vertical gradient in horizontal velocity, which will be the "bottom friction" parameterisation. If the flow is really shallow i.e. all horizontal scales are much larger than depth, then the "bottom friction" term largely dominates and the 2D viscous term can be ignored. So, the main issue here is not really that this term is ignored where it shouldn't be but rather than the regime which is simulated is not consistent with the shallow water approximation in the first place.'' --[[User:Popinet|Popinet]] 09:38, 20 May 2011 (UTC) |

## Current revision

Testing the River version of Gerris. In particular interested in the possibility of tidal turbine like simulations in support of Tim Divett's thesis.

The basic issue is that we note in both the Linear Free Surface and Nonlinear Free Surface versions of Gerris that vortices generated from wakes caused by localised regions of high bottom friction (mimicing the presence of a turbine, say) can sometimes become unstable, i.e., the vortex continues to spin up as it moves downstream leading to (presumably) unphysical magnitudes of flow and fluid height. In the linear free surface version, such vortices persist and can be seen moving with the background flow. In the nonlinear free surface version, these vortices become tighter and more intense, and eventually grind the simulation to a halt via excessive magnitudes of flow and amplitude.

This issue is also relevant to a whole series of linear free surface tidal simulations around headlands and bays around New Zealand. In these simulations an increase in spatial resolution reveals the generation of many eddies that appear to be shed in a physical way via interactions with the coastline. As above, these eddies persist in the background tidal flow. They do not appear to be unstable (ie the runs keep going), but the question remains about the fidelity and actuality of these eddies (and to test this we need more field observations, and perhaps some more thought about the model).

Both models have been tested against the cases present by Signell and Geyer (1991) and both seem to do a good job of reproducing many of the features seen. Thus the underlying schemes seem to be correct, at least for the scales of interest in these tests.

Perhaps it's not surprising that these features arise. After all the models in question here are solving shallow water variants of reality, so that the likely possibility of 3D processes in the water column influencing the vortex behaviour is absent. For the shallow water the only explicit damping is via a bottom friction term, and the only implicit damping is through truncation terms in the advection scheme; these may be missing important physics that allow for a more complete representation of the vortex behaviour.

So, here show some examples of the unstable vortex behaviour in the River code. This can perhaps lead to a better understanding of the limitations of the shallow water models, and how far we should be pushing them to look at the (presumably) complex tidal interactions with coastline and in-situ structures.

## Contents |

## River Tidal Turbine 2D Problem

A typical 2D run set up with constant bathymetry of 50 metres depth, with an increased region of bottom friction defined by TT(x,y) in the centre of the domain. M2U(t) drives the tidal flow at the boundary, anticipating a maximum input speed of 1 m/s.

The change of relevance here is the choice of advection scheme. The default (Minmod) produces a stable simulation, with a smooth wake behind the turbine. Change that to Sweby, and the wake becomes unstable, leading to vortices that then continue to deepen and amplify.

The question is which is "correct"?

Run out to around t=5000, taking about the same number of cpu seconds on 6 processor elements.

# run me using: gerris2D -m

Define RXMID1 (1.0)

Define RYMID1 (0.0)

Define rmag1(rx,ry) ( sqrt((rx-RXMID1)*(rx-RXMID1)+(ry-RYMID1)*(ry-RYMID1)) )

Define RBIT1V(rx,ry) (rmag1(rx,ry) > 0.0 && rmag1(rx,ry) < 0.15 ? 1 : 0.0)

Define RBIT2V(rx,ry) ( (fabs(ry) < 0.4 && rx > -0.4 && rx < 2.4) ? 1 : 0.0)

Define RBIT1S(rx,ry) ( exp(-rmag1(rx,ry)/0.01) )

Define RBIT0V(rx,ry) (rmag1(rx,ry) > 0.0 && rmag1(rx,ry) < 0.35 ? 1 : 0.0)

Define LEVMAX 8

Define LEVMID 8

Define LEVMIN 5

Define LEVBIG 9

Define LEVBIGGER 11

Define R2 (RBIT2V(rx,ry))

Define R3 (RBIT1V(rx,ry))

Define LEVEL1 ( R3 ? LEVMAX : LEVMIN )

Define LEVEL2 ( R2 ? LEVMAX+1 : LEVEL1)

# Turbine parameters, diameter is in y direction, width in x direction,

Define DIAMETER 20.

Define WIDTH 10.

Define Cdbig 12.

#Spacing distance between turbines

Define XSPACING DIAMETER*5.

Define YSPACING DIAMETER*1.5

# M2 tidal frequency. The period is 12h25 (44700 seconds) and M2 tidal elevation.

Define M2F (2.*M_PI/44700.)

Define M2(t) (0.0*cos (M2F*t)+0.01*sin (M2F*t))

# Variable U is velocity*depth here, hence set

# M2U to be velocity (a number) by depth (P)...

#

Define M2U(t) (1.0*(P)*sin (M2F*t))

# Define tau (-0.8e-4)

Define tau (0.0)

Define cd (3.e-3 + TT(x,y)*Cdbig)

Define theta (1.0)

Define onemth (1.0 - theta)

Define abfac (dt*cd*Velocity/P)

Define bffac (tau*dt)

Define onepa (1.+abfac)

Define bth (bffac*theta)

Define bonemt (bffac*onemth)

# Use the "GfsRiver" model

3 2 GfsRiver GfsBox GfsGEdge {} {

Global {

/* Dimensional initial potential temperature profile */

#define TT(x,y) (fabs(x) < WIDTH/2. && fabs(y) < DIAMETER/2. ? 1. : 0.0)

}

# Box size (metres)

PhysicalParams { L = 250.0 g = 9.81 }

# I want the centre of the 2nd box at x = 0 so translate by x = 1000

GfsMapTransform { tx = -250 ty = 0 tz = 0 }

# End the simulation

Time { end = 8640 dtmax = 10 }

# Use terrain module

GModule terrain

Refine LEVEL1

VariableTerrain Zb {

basename = bathy50Wide

path = /data01/marine-physics/rickard/FROMTIM/COSB:/data01/marine-physics/rickard/FROMTIM

} { reconstruct = 1 }

Init {} {

P = MAX (0., -Zb)

}

## remember the initial grid Level...

Init{} {MYMINL = Level

RSEE1V = RBIT1V(rx,ry)

RSEE2V = RBIT2V(rx,ry)

CTT = TT(x,y)

}

#AdvectionParams { cfl = 1.0 }

AdvectionParams { cfl = 0.5

# gradient = gfs_center_sweby_gradient

# gradient = gfs_center_superbee_gradient

# gradient = gfs_center_van_leer_gradient

}

ProjectionParams { tolerance = 1e-6 }

ApproxProjectionParams { tolerance = 1e-6 }

AdaptGradient { start=360 istep = 1 } {

cmax = 0.06

cfactor = 2

maxlevel = LEVEL2

minlevel = MYMINL

} (P < 1e-4 ? 0. : P + Zb)

# Bottom friction parameterisation semi-implict, plus

# plus Coriolis terms added with implicitness parameter theta...

#

Init { start=360 istep = 1 } {

U = ( P > 1e-6 ? (onepa*(U-bonemt*V)-bth*(V+bonemt*U))/(onepa*onepa + bth*bth) : 0.)

V = ( P > 1e-6 ? (onepa*(V+bonemt*U)+bth*(U-bonemt*V))/(onepa*onepa + bth*bth) : 0.)

}

# Try to construct a Vorticity by dividing fluxes by local

# depth and applying gradient operators...here in 2D of course...

#

Init { istep = 1 } {

RU = ( P < 1e-4 ? 0.0 : (U/P))

RV = ( P < 1e-4 ? 0.0 : (V/P))

VORT = (P < 1e-4 ? 0. : (dx("RV") - dy("RU")))

}

# Vorticity criterion

# Takes 1 m/s as normalising maximum velocity

AdaptFunction { start = 360 istep = 1 } {

cmax = 5e-2

cfactor= 2

maxlevel = LEVEL2

minlevel = MYMINL

} (fabs(VORT*dL/1.0))

EventBalance { istep = 10 } 0.1

OutputTime { istep = 100 } stdout

OutputSimulation { step = 100 } boi_wiki_3-%g.gfs

OutputSimulation { start = end } boi_wiki_3_end.gf

}

GfsBox {

left = Boundary {

BcDirichlet U M2U(t)

BcNeumann P 0

}

top = Boundary

bottom = Boundary

}

GfsBox { top = Boundary

bottom = Boundary

}

GfsBox {

right = Boundary {

BcDirichlet U M2U(t)

BcNeumann P 0

}

top = Boundary

bottom = Boundary

}

1 2 right

2 3 right

## River Tidal Turbine 2D Sample Output

Solutions at 3500 seconds into each run using the default (left column) and Sweby (right column) advection schemes.

As perhaps expected the default (minmod) advection gives a smoother wake, with no hint at this time of wake instability and vortex generation.

In contrast with Sweby advection instability is clear and looks (to begin with) physical. However, as these frames show, there is a fairly 'singular' vortex formed, with deepening amplitude and associated flow speeds. This then later generates a whole raft of large amplitude waves over the whole domain, killing the simulation; this process is clearly unstable.

Note that adaptivity is turned on. Initially the grid is refined to the finest level in a zone around the turbine, with relatively coarse cells elsewhere. This region is then allowed to follow the evolution of the wakes through a vorticity criterion which certainly seems to work as expected. Thus the evolving vortices are resolved to the finest scale set.

## 2D incompressible Euler results

Given that the Froude number for this example is only Fr = 1./sqrt(g*H) = 0.045, it is entirely justified to use a rigid-lid approximation. The problem thus becomes depth-independent an can be solved using the incompressible Euler (no viscous terms) solver (GfsSimulation) with the same "bottom friction" parameterisation.

The parameter file is very similar to the GfsRiver one above

# run me using: gerris2D -m

Define RXMID1 (1.0)

Define RYMID1 (0.0)

Define rmag1(rx,ry) ( sqrt((rx-RXMID1)*(rx-RXMID1)+(ry-RYMID1)*(ry-RYMID1)) )

Define RBIT1V(rx,ry) (rmag1(rx,ry) > 0.0 && rmag1(rx,ry) < 0.15 ? 1 : 0.0)

Define RBIT2V(rx,ry) ( (fabs(ry) < 0.4 && rx > -0.4 && rx < 2.4) ? 1 : 0.0)

Define RBIT1S(rx,ry) ( exp(-rmag1(rx,ry)/0.01) )

Define RBIT0V(rx,ry) (rmag1(rx,ry) > 0.0 && rmag1(rx,ry) < 0.35 ? 1 : 0.0)

Define LEVMAX 8

Define LEVMID 8

Define LEVMIN 5

Define LEVBIG 9

Define LEVBIGGER 11

Define R2 (RBIT2V(rx,ry))

Define R3 (RBIT1V(rx,ry))

Define LEVEL1 ( R3 ? LEVMAX : LEVMIN )

Define LEVEL2 ( R2 ? LEVMAX+1 : LEVEL1)

# Turbine parameters, diameter is in y direction, width in x direction,

Define DIAMETER 20.

Define WIDTH 10.

Define Cdbig 12.

#Spacing distance between turbines

Define XSPACING DIAMETER*5.

Define YSPACING DIAMETER*1.5

# M2 tidal frequency. The period is 12h25 (44700 seconds) and M2 tidal elevation.

Define M2F (2.*M_PI/44700.)

Define M2(t) (0.0*cos (M2F*t)+0.01*sin (M2F*t))

# Variable U is velocity*depth here, hence set

# M2U to be velocity (a number) by depth (P)...

#

Define M2U(t) (sin (M2F*t))

# Define tau (-0.8e-4)

Define tau (0.0)

Define cd (3.e-3 + TT(x,y)*Cdbig)

Define theta (1.0)

Define onemth (1.0 - theta)

Define abfac (dt*cd*Velocity/50.)

Define bffac (tau*dt)

Define onepa (1.+abfac)

Define bth (bffac*theta)

Define bonemt (bffac*onemth)

# Use the "GfsRiver" model

3 2 GfsSimulation GfsBox GfsGEdge {} {

Global {

/* Dimensional initial potential temperature profile */

#define TT(x,y) (fabs(x) < WIDTH/2. && fabs(y) < DIAMETER/2. ? 1. : 0.0)

}

# Box size (metres)

PhysicalParams { L = 250.0 }

# I want the centre of the 2nd box at x = 0 so translate by x = 1000

GfsMapTransform { tx = -250 ty = 0 tz = 0 }

# End the simulation

Time { end = 8640 }

Refine LEVEL1

## remember the initial grid Level...

Init{} {MYMINL = Level

RSEE1V = RBIT1V(rx,ry)

RSEE2V = RBIT2V(rx,ry)

CTT = TT(x,y)

}

# Bottom friction parameterisation semi-implict, plus

# plus Coriolis terms added with implicitness parameter theta...

#

Init { start=360 istep = 1 } {

U = (onepa*(U-bonemt*V)-bth*(V+bonemt*U))/(onepa*onepa + bth*bth)

V = (onepa*(V+bonemt*U)+bth*(U-bonemt*V))/(onepa*onepa + bth*bth)

}

# Try to construct a Vorticity by dividing fluxes by local

# depth and applying gradient operators...here in 2D of course...

#

Init { istep = 1 } {

VORT = (dx("V") - dy("U"))

}

# Vorticity criterion

# Takes 1 m/s as normalising maximum velocity

AdaptFunction { start = 360 istep = 1 } {

cmax = 5e-2

cfactor= 2

maxlevel = LEVEL2

minlevel = MYMINL

} (fabs(VORT*dL/1.0))

EventBalance { istep = 10 } 0.1

OutputTime { istep = 10 } stderr

OutputProjectionStats { istep = 10 } stderr

# OutputSimulation { istep = 10 } stdout

OutputSimulation { step = 100 } boi_wiki_3-%g.gfs

OutputSimulation { start = end } boi_wiki_3_end.gfs

GModule gfsview

OutputView { step = 20 } { ppm2mpeg > vort.mpg } vort.gfv

}

GfsBox {

left = Boundary {

BcDirichlet U M2U(t)

BcNeumann P 0

}

top = Boundary

bottom = Boundary

}

GfsBox { top = Boundary

bottom = Boundary

}

GfsBox {

right = BoundaryOutflow

top = Boundary

bottom = Boundary

}

1 2 right

2 3 right

The results at t = 3500 look like this. Of course, these results will be grid-dependent since no explicit viscosity has been added.

## Ocean Simulation Output

A single turbine simulated in the linear free surface solver looks very similar to the 2D NS solution.

It is important to drive the flow through the channel with a pressure gradient rather than a velocity boundary condition. With larger arrays that partially block the channel, the dynamics of the channel change and the turbines extract energy from a lower velocity flow with a strong pressure gradient across the turbine.

When I drove the flow in the channel with a pressure gradient across the boundaries in the 2D NS solver I got large reflections from boundaries. We also decided that depth averaging was a better approximation than a 2D NS for looking at arrays of turbines because the 2D NS solution assumes the domain is the same at all depths which is not true for a 20m turbine in 50m of water.

Here is my single turbine parameter file and output to compare with Euler. I use Umax = 2ms^-1 and speed up the tide so FM2 = 4470 s.

#run with gerris3D -m single.gfs

# Upstream tidal pressure at boundaries

Define PUP 4.5

# M2 tidal frequency. The period is 12h25 (44700 seconds).

# Use 1/10th T for faster simulations

Define M2F (2.*M_PI/4470.)

#levels used in adaptive refinement

Define MINLEVEL 3.

Define MAXLEVEL 10.

# Turbine parameters, diameter is in y direction, width in x direction,

Define DIAMETER 20.

Define WIDTH 5.

Define Cd 12.

3 2 GfsOcean GfsBox GfsGEdge {} {

# Set the max timestep to sthg small compared to the tidal period

Time { dtmax = 20 end = 4500 }

# We want more accuracy in the projection than the default 1e-3

ApproxProjectionParams { tolerance = 1e-6 nitermax = 10 }

# Set the box size to 1000 m

PhysicalParams { L = 1000. g = 9.81 }

# Use an initial refinement of maximum level 10 with very fine refinement on the turbine

Refine {

if ( (fabs(x) < WIDTH * 2. && fabs(y) < DIAMETER)

|| (fabs(x) < WIDTH * 2. && fabs(y) < DIAMETER) )

return MAXLEVEL;

else if ( (fabs(x) < WIDTH * 15.)

&& (fabs(y) < DIAMETER * 4.) )

return 6;

else return MINLEVEL;

}

#Load modules needed for translating centre of domain

GModule map

# I want the centre of the 2nd box at x = 0 so translate by x = 1000

GfsMapTransform { tx = -1000 ty = 0 tz = 0 }

#Mean depth = 50 everywhere

Solid (z + 50.)

#Initialise the variables T1 and T2 to 1 where there is a turbine, 0 elsewhere

# T is 1 where either turbine or 0 where there is no turbine

Init {} {

T = (fabs(x) < WIDTH/2. && fabs(y) < DIAMETER/2.)

}

# Adapt the mesh using the vorticity criterion at every timestep

# down to a maximum level of 10 and with a maximum tolerance of 1e-2

AdaptVorticity { istart = 1 istep = 1 } {

minlevel = MINLEVEL

maxlevel = {

if (fabs(x) < 1100. && fabs(y) < 300.) /* In near wake, want highest refinement */

return MAXLEVEL;

else if (fabs(x) > 1300. || fabs(y) > 375.) /* Near edges need one box of level 3 for CFL criteria */

return MINLEVEL; /* revisit this sometime */

else

return 7.; /* elsewhere, moderate level */

}

cmax = 1e-2 }

#But keep the mesh at high resolution within the turbine

AdaptGradient { istart = 1 istep = 1 } { maxlevel = MAXLEVEL cmax = 1e-3 } {return T;}

# Quadratic bottom friction plus turbine drag applied explicity

# at each time step

# The turbine drag is applied anywhere T = 1, bottom friction applied everywhere

Init { istep = 1 } {

U = U/(1. + dt*Velocity*(2.5e-3 + T * Cd)/H)

V = V/(1. + dt*Velocity*(2.5e-3 + T * Cd)/H)

}

OutputTime { istep = 10 } stderr

OutputBalance { istep = 10 } stderr

OutputProjectionStats { istep = 10 } stderr

OutputTiming { start = end } stderr

#Movies, need the correct .gfv files in gfv folder

GModule gfsview

OutputView { step = 10 } { ppm2mpeg -s 3000x1000 > Vort0-0.6.mpg } {

format = PPM width = 3000 height = 1000

} /home/divettt/simulations/gfv/Vort0-0.6.gfv

OutputView { step = 10 } { ppm2mpeg -s 3000x1000 > Pressure-1-1.mpg } {

format = PPM width = 3000 height = 1000

} /home/divettt/simulations/gfv/Pressure-1-1.gfv

OutputView { step = 10 } { ppm2mpeg -s 3000x1000 > Vort0-0.6CloseUp.mpg } {

format = PPM width = 3000 height = 1000

} /home/divettt/simulations/gfv/Vort0-0_6CloseUp.gfv

#Output simulation file

OutputSimulation { istep = 1 iend = 20 end = 100 } ressimulation%05.0f.gfs

OutputSimulation { start = 200 step = 200 } ressimulation%05.0f.gfs

OutputSimulation { start = end } ressimulation%05.0f.gfs

OutputSimulation { start = 1117 step = 1117 } ressimulation%05.0f.gfs

#Output power extracted from the flow by each and both turbines as well as KE and PE in both turbines

OutputScalarSum { istep = 1 } powerT.txt { v = T*(Cd/2. * (U*U + V*V) * U * fabs(sqrt(U*U +V*V))) }

#Write output for key locations

OutputLocation {istep = 1} leftBoundary.txt {-1500 0 -25}

OutputLocation {istep = 1} rightBoundary.txt {1490 0 -25}

}

GfsBox {

left = Boundary { BcFlather U 0 H P (PUP * sin(M2F * t)) }

front = Boundary

}

GfsBox { front = Boundary }

GfsBox {

right = Boundary { BcFlather U 0 H P (-PUP * sin(M2F * t) ) }

front = Boundary

}

# All the boxes are linked by left to right links

1 2 right

2 3 right

Output at t = 1117 s. Note, I speed up the tide by a factor of 10 to get reasonable run times for large arrays of turbines. At 350 s the wake hasn't developed much. I think the ocean and euler result look fairly similar.

Using the GfsOcean simulation we get some similar super vortices generated as the tide reverses back through an array of turbines. The super vortex (red area above the array in figure below) forms to the right of the array at the reversing of the tide and passes near the top right turbine in the array which whips across to its current position. It grows in magnitude as it moves. I don't see this in a simulation of a single turbine.

## Summary

This form of instability is not peculiar to the nonlinear free surface code, but the nonlinearity feeds the effect of the vortex to the wider field, causing a model crash. The growth of the vortex is similar in the linear free surface code (might need an example from Tim) but it doesn't generally lead to a model crash.

I suspect that we're expecting too much from these versions of the model, ie, shallow water with their own advection scheme variants. It may well be that a full resolution will have to be in 3D (and indeed Sebastien has tried that and found how tricky and expensive that is!).

Underlying the problem remains the fundamental issue; what is the eddy generation potential of tidal flow interacting with coastline? The Gerris models suggest that there are potentially a lot of eddies out there to be found; however the fact that the model response is ultimately unstable suggests that these models might be over-estimating that potential.

*This is not a "model-dependent" problem (in the sense "numerical model"). What ultimately controls how many eddies are present is the balance between eddy creation and dissipation. Both are controlled by the model used for the viscous dissipation (in the sense theoretical/physical/mathematical model). At the moment these simulations assume that the only friction is through some parameterisation of bottom friction. This bottom friction is too small outside of the turbine area (or equivalently the spatial resolution is not high enough) and the simulations are thus essentially controlled by the numerical dissipation (hence the sensitivity of the results on the detail of the model used: advection scheme, limiters etc...). When averaging the Saint-Venant equations vertically, dissipation appears in two ways: a first term which is essentially the vertical average of the horizontal components of the viscous terms, which will look like an equivalent 2D viscous dissipation. A second term which is a vertical average of the viscous terms linked to the vertical gradient in horizontal velocity, which will be the "bottom friction" parameterisation. If the flow is really shallow i.e. all horizontal scales are much larger than depth, then the "bottom friction" term largely dominates and the 2D viscous term can be ignored. So, the main issue here is not really that this term is ignored where it shouldn't be but rather than the regime which is simulated is not consistent with the shallow water approximation in the first place.*--Popinet 09:38, 20 May 2011 (UTC)