<p><b>dwj07@fsu.edu</b> 2012-02-08 16:01:21 -0700 (Wed, 08 Feb 2012)</p><p><br>
-- BRANCH COMMIT --<br>
<br>
Adding the beginnings of a design document for monotonic advection.<br>
</p><hr noshade><pre><font color="gray">Added: trunk/documents/ocean/current_design_doc/monotonic_advection/monotonic_advection.tex
===================================================================
--- trunk/documents/ocean/current_design_doc/monotonic_advection/monotonic_advection.tex (rev 0)
+++ trunk/documents/ocean/current_design_doc/monotonic_advection/monotonic_advection.tex 2012-02-08 23:01:21 UTC (rev 1489)
@@ -0,0 +1,180 @@
+% File: TracerVFlux3rd.tex
+% Created: Fri Feb 03 07:00 AM 2012 M
+% Last Change: Fri Feb 03 07:00 AM 2012 M
+%
+\documentclass[11pt]{report}
+\usepackage{amsmath}
+\usepackage{amsfonts}
+\usepackage{subfigure}
+\usepackage{placeins}
+\usepackage{graphicx}
+\usepackage{listings}
+\usepackage{float}
+\title{Monotonic Tracer Advection}
+\setcounter{secnumdepth}{5}
+\setcounter{tocdepth}{5}
+\begin{document}
+\maketitle
+
+\chapter{Summary}
+This document outlines the monotonoic tracer advection implementation within
+the MPAS framework. The issues section relates to trying to make this a shared
+routine between all cores.
+
+\chapter{Requirements}
+
+\begin{itemize}
+ \item Horizontal and Vertical Advection of Tracers
+ \item Monotonic Advection
+ \item FCT
+\end{itemize}
+\chapter{Formulation}
+This section only relates to the monotonic advection.\\
+
+The monotonic advection routine can be written in pseudocode in the following form.
+\begin{center}
+ \line(1,0){250}
+\end{center}
+\begin{lstlisting}
+Advect one tracer at a time:
+ Determine bounds on tracer value at a cell. This involves the
+ minima and maxima of the current cell, and all cells that
+ share an edge with it (both horizontally and vertically)
+ We call these q_min and q_max
+
+ Compute 3rd order dispersive fluxes in vertical, and horizontal
+
+ Compute 1st order diffusive upwind fluxes in vertical and
+ horizontal
+
+ Removing the 1st order upwind component from the 3rd order flux,
+ compute a dispersive component of the flux. We will later scale
+ this portion of the high order flux in order to preserve
+ monotonicity.
+
+ Determine scale factors.
+ First, compute the maximum updated tracer value. This value
+ combines the previous value with all possible incoming fluxes
+ that postively contribute to it's value. We call this q_max_new
+
+ Second, compute the minimum updated tracer value. This value
+ combines the previous value with all possible outgoing fluxes
+ that negatively contribute to it's value. We call this q_min_new
+
+ Third, compute the upwind update tracer value. This value
+ combines the previous value with the 1st order upwind
+ tracer update value. We call this q_upwind_new
+
+ Compute the two scale factors.
+ scale_factor_in =
+ (q_max - q_upwind_new) / (q_max_new - q_upwind_new)
+ scale_factor_out =
+ (q_upwind_new - q_min) / (q_upwind_new - q_min_new)
+
+ Apply the newly computed scale factors to the remaining dispersive
+ flux components.
+
+ Accumulate the upwind flux, and the scaled dispersive fluxes. These
+ provide a higher order monotonic flux.
+\end{lstlisting}
+\begin{center}
+ \line(1,0){250}
+\end{center}
+
+\chapter{Design and Implementation}
+In trying to implement the monotonic tracer advection these modules are placed
+in src/operators. There are standard non-monotic advection routines and a
+monotonic advection that are provided. This allows all cores to have shared
+modules and a shared interface for advecting tracers. \\
+
+The previously described psuedocode is implemented in a monotonic advection module.\\
+
+Implementation of these advection modules provides the following interfaces.
+\begin{lstlisting}[language=fortran,escapechar=@,frame=single]
+subroutine mpas_tracer_advection_tend(tracers, uh, w,
+ h, dt, zDistance, zWeightK, zWeightKm1, grid,
+ tend_h, tend)
+subroutine mpas_tracer_advection_std_tend(tracers, uh,
+ w, zDistance, zWeightk, zWeightKm1, grid, tend)
+subroutine mpas_tracer_advection_mono_tend(tracers, uh,
+ w, h, dt, zDistance, zWeightK, zWeightKm1, grid,
+ tend_h, tend)
+\end{lstlisting}
+
+within this interface $uh$ defines a thickness weighted
+velocity, $w$ is a vertical velocity, $h$ is a thickness field defined at cell
+centers, $dt$ is the timestep over which advection is being performed,
+$zDistance$ defines distances between vertical interfaces, $zWeightK$ defines
+the weights required to map tracers from vertical cell centers to vertical cell
+edges from the cell below the edge while $zWeightKm1$ is for the cell above the
+edge, $grid$ is the actual grid data structure, $tend_h$ is all tendencies on
+the thickness field in order to update it to a new state, and $tend$ is the
+tracer tendency array. \\
+
+The mpas\_tracer\_advection\_tend routine is part of a driver module for the
+standard and monotonic advection modules. Inside of a core, one simply has to
+call this routine to compute the tracer tendencies for monotonic or standard
+advection. \\
+
+\chapter{Implementation Issues}
+
+\section{Vertical Level Idexing}
+In the atmosphere, every cell has nVertLevels levels. Because of this,
+computations can span the entire column. However, in the ocean bottom
+topography creates land cells which might be in the range of 1:nVertLevels.
+Because of this, arrays are created as part of the grid structure called
+maxLevelCell, maxLevelEdgeTop, and maxLevelEdgeBot. These represent the maximum
+index of water cells in each column, the max index of an edge that has water
+cells on both sides of it, and the max index of an edge that has at least one
+water cell on eiter side of it.\\
+
+In order to create a shared framework for tracer advection, all cores need to
+have a shared method of changing the number of layers in a cell or on an edge. \\
+
+\section{Vertical Advection}
+\subsection{Vertical Flux Directions}
+There are issues present in all vertical advection sections. This is due to
+indexing of vertical levels. In the atmosphere, k is indexed positively as
+cells move upwards. Because of this, positive vertical fluxes occur in
+direction of increasing k. In the ocean, k is index positively as cells move
+downwards, so vertical fluxes are positive in the direction of decreasing k.
+This needs to be accounted for if the routines are to be shared across cores.
+\subsection{flux3 mapping}
+\subsubsection{MPAS-O}
+To begin, the tracerTop array is filled. When applicable a 3rd order stencil is used. The stencil for 3rd order is written as follows.
+
+\begin{align*}
+ tracerTop = &((-1 + C) * q_{k-2} \\
+ &+(7- 3*C) * q_{k-1} \\
+ &+(7+ 3*C) * q_{k} \\
+ &+(-1 - C) * q_{k+1})/12.0
+\end{align*}
+
+Expanding this, we arrive at the following form.
+
+\begin{align*}
+ tracerTop &= ((-q_{k-2} + C*q_{k-2}) \\
+ &+ (7*q_{k-1} - 3*C*q_{k-1}) \\
+ &+ (7*q_{k} + 3 * C * q_{k}) \\
+ &+ (-1 * q_{k+1} - C*q{k+1}))/12.0
+\end{align*}
+
+\subsubsection{Atmosphere}
+In the atmosphere a 3rd order stencil is used to compute vertical fluxes. This stencil is written as follows.
+
+\begin{align*}
+ flux3 &= (u * (7 * (q_{k} + q_{k-1}) - (q_{k+1} + q_{k-2})) \\
+ &+C * |u| *((q_{k+1}-q_{k-2}) - 3 * (q_{k} - q_{k-1})))/12.0
+\end{align*}
+
+If we try to refactor this to arrive at a similar expression as in the MPAS-O section we find the following form:
+
+\begin{align*}
+ flux3 &= ((-u * q_{k-2} - C * |u| * q_{k-2}) \\
+ &+ ( u * 7 * q_{k-1} + 3 * C * |u| * q_{k-1}) \\
+ &+ ( u * 7 * q_{k} - 3 * C * |u| * q_{k}) \\
+ &+ (-u * q_{k+1} + C * |u| * q_{k+1})) / 12.0
+\end{align*}
+
+\end{document}
+
</font>
</pre>