Changes between Version 3 and Version 4 of 2016WP/NocWad

Timestamp:

2016-04-07T13:16:39+02:00 (8 years ago)

Author:

acc

Comment:

--

2016WP/NocWad

@@ -64 +64 @@
 [[Image(fig04.png)]]
 
-
+flux limiter is needed if:
+
+[[Image(fig05.png)]]
+
+So:
+
+[[Image(fig06.png)]]
+
+[[Image(fig07.png)]] is the time step, U is the vertical integrated velocity, q is the source rate from
+precipitation, evaporation, and river inflow, Fi is water flux rate across each boundary
+of the control volume, which is positive for outflow and negative for inflow. The
+subscript i identifies each boundary  in the west, east, north, and south directions.
+Dmin is the minimal water depth to be kept in a dry grid cell while D is the total depth
+of the grid cell. [[Image(fig08.png)]] is the horizontal area of the water column. sign() is
+the sign function. Obviously,  [[Image(fig09.png)]] should have the following property:
+
+
+ [[Image(fig10.png)]]
+
+
+In other words, the strength of limiter varies from 0 to 1 which corresponding to the fully shutting down the outflow and no limiter on outflow respectively.
+
+One case needs to be paid attention here is the above equations can produce a negative
+value of [[Image(fig11.png)]] , This is corresponding to a large evaporation rate. In that case, we need to
+turn off the evaporation on that grid cell during that time step.
+
+The limited flux (only in the horizontal directions) has the following form:
+
+ [[Image(fig12.png)]]
+
+The above equation is applied to all the continuity equation and tracer equations. The
+resultant water column on each grid cell will have its depth greater than or equals to the
+predefined minimal depth Dmin.
+
+==== Continuity Equation and Tracer Equations. ====
+
+We need to be careful with the explicit time splitting method when the flux limiter is
+applied to the continuityequation.Therearemanyexternaltimestepswithineach
+internaltimestep.Themulti- barotropic stepping updates the sea surface height and vertical
+integrated horizontal velocity. It is tedious to keep the consistency between these two
+modes on the W/D grid cells. The reason to do the explicit time splitting is because of
+the big ratio of gravity wave speed to the baroclinic velocity. We argue here that this
+ratio must be a small value (less than or equals to 1) in the W/D area because of the
+relatively small water depth. So, we simplify this case by turning off the time splitting
+procedure on the W/D grid cells.
+
+A few iterations may be needed to take into account of the interactions between the two
+neighbouring cells when the limiter coefficient is calculated. As this flux limiter only
+effects around the W/D front, the iteration should converge very quickly. Also, the
+iteration is only needed for the continuity equation and should not be a very much extra
+burden to the whole computation.
+
+For the tracer Equation, it can simply be implemented by applying the flux limiter
+coefficient to the horizontal velocities. In such way, we don’t need change anything in
+the original source code except update the velocities.
+
+==== Momentum equations ====
+
+For the momentum equations, the grid cell water depth is just the weight averaged depth of
+the two neighboring water depths, hence it always keeps positive as long as the water
+depth on the tracer grid cells is positive. So, we don’t need to apply any momentum flux
+limiter.
+
+The critical issue is how to maintain the model stability. The velocity nodes can be
+categorized into ocean nodes, land nodes, and W/D nodes based on whether wetting/drying
+happens or not on it. For the ocean nodes, which never got dried out, we don’t need to
+implement any W/D work there. For the land nodes, which never got flooded with water, we
+can just set the velocity to zero and don’t need to solve any equations. For the W/D
+nodes, some specific improvements need to be implemented to keep model stable. These
+improvements include filtering out the unrealistic hydrostatic pressure gradient and other
+nonlinear and the Coriolis forcing term. 
+
+A momentum grid cell which is between a wet grid cell and a dry grid cell, will have modified
+barotropic pressure gradients as demonstrated in the following two equations:
+
+[[Image(fig13.png)]]
+
+[[Image(fig14.png)]]
+
+where:
+
+[[Image(fig15.png)]]
+
+[[Image(fig16.png)]]
+
+Where, sign() is the Fortran sign function. D is total depth, [[Image(fig17.png)]] is the sea surface height. g is gravity acceleration. P is the barotropic pressure gradient.
+
+The bottom friction on DDW will automatically increase when the “log layer” configuration
+is used. The vertical viscous/diffusive coefficient on DDW will be increased manually to
+keep the model stable.
+
+The surface wind stress and surface heating/cooling will be neglected at DDW cells. The
+justification is that these cells are thought fully or nearly dried.
+
+==== Code implementation: ====
+
+One problem with to implement the current method is the sigma coordinate redistribution
+with time. The existing NEMO code uses coefficient “mut(uvf)(:,:,:)” which is based on the
+physical initial vertical length scale factors. In wetting/drying case, people might
+encounter zero depth in some grid cells at the initiation stage. So, it is modified to use
+the initial sigma coordinate vertical scale to do the redistribution.
+
+The current method tries to be independent of the existing code as much as possible, that
+is to say, to minimise the interferences from the wetting/drying module to the existing
+code. CPP method seems to be the most ideal one. But we were reminded that NEMO
+development policy is trying to reduce the use of CPP. So, the code is implemented with
+some extra coefficients which have value of 1 or zero when applied to the
+non-wetting/drying case.In some other parts, the wetting/drying code was added in some IF
+or CASE blocks. We are currently working on the implementation of this method onto NEMO
+v3.6 r:6397. Will provide a detailed list of the code modifications when the
+implementation is finished.
 
 This section should be completed before starting to develop the code, in order to find agreement on the method beforehand.