...
 
Commits (31)
No preview for this file type
......@@ -433,6 +433,91 @@ year = "2012"
publisher={Addison-Wesley Professional}
}
@book{Ar89,
title={Vectors, tensors, and the basic equations of fluid mechanics},
author={Aris, R.},
year={1989},
publisher={Dover Pubns}
}
@article{McRaeBMHC,
author = "A.T.T. McRae and G.-T. Bercea and L. Mitchell and D.A. Ham and C.J. Cotter",
title = "Automated Generation and Symbolic Manipulation of Tensor Product Finite Elements",
journal = "SIAM Journal on Scientific Computing",
Volume = "38",
number = "5",
pages = "S25--S47",
year = "2016"
}
@article{WitherdenVJ2016,
author = "F.D. Witherden and P.E. Vincent and A. Jameson",
title = "Chapter 10 -- High-Order Flux Reconstruction Schemes",
journal = "Handbook of Numerical Analysis",
volume = "17",
year = "2016",
pages = "227-263"
}
@book{Kopriva,
title = "Implementing Spectral Methods for Partial Differential Equations: Algorithms for Scientists and Engineers",
author = "David A. Kopriva",
publisher = "Springer",
year = "2009"
}
@book{CottrellISO,
title = "Isogeometric Analysis: Toward Integration of CAD and FEA",
author = "J. Austin Cottrell and Thomas J. R. Hughes and Yuri Bazilevs",
publisher = "John Wiley and Sons",
year = "2009"
}
@article{jallepalli2017treatment,
title={On the treatment of field quantities and elemental continuity in {FEM} solutions},
author={Jallepalli, Ashok and Docampo-S{\'a}nchez, Julia and Ryan, Jennifer K and Haimes, Robert and Kirby, Robert M},
journal={IEEE Transactions on Visualization and Computer Graphics},
volume={24},
number={1},
pages={903--912},
year={2017},
publisher={IEEE}
}
@article{sanchez2016multi,
title={Multi-dimensional filtering: Reducing the dimension through rotation},
author={Docampo-S{\'a}nchez, Julia and Ryan, Jennifer K and Mirzargar, Mahsa and Kirby, Robert M},
journal={SIAM Journal on Scientific Computing},
volume={39},
number={5},
pages={A2179--A2200},
year={2017},
publisher={SIAM}
}
@article{ClenshawC,
author = "Lloyd N. Trefethen",
title = "Is Gauss Quadrature Better than Clenshaw-Curtis?",
journal = "SIAM Review",
volume = "50",
issue = "1",
pages = "67-87",
year = "2008"
}
@article{Vostime,
author = "Peter E.J. Vos and Sehun Chun and Alessandro Bolis and Claes Eskilsson and Robert M. Kirby and Spencer J. Sherwin",
title = "A Generic Framework for Time-Stepping PDEs: General Linear Methods, Object-Oriented Implementations and Applications to Fluid Problems",
journal = "International Journal of Computational Fluid Dynamics",
volume = "25",
issue = "3",
pages = "107-125",
year = "2011"
}
%% NekPy references
@misc{BoostPythonTutorial,
......@@ -526,4 +611,5 @@ year = "2012"
title = "Reference Counting - Python 2.7.14 documentation",
url = "https://docs.python.org/2/c-api/refcounting.html",
note = "[Accessed 21 March 2018]"
}
\ No newline at end of file
}
......@@ -3,6 +3,7 @@
\DeclareOldFontCommand{\bf}{\normalfont\bfseries}{\mathbf}
\usepackage{makeidx}
\usepackage{bm}
\usepackage{hyperref}
\hypersetup{
colorlinks=true,
......@@ -21,7 +22,27 @@
\newcommand{\GIT}{\textit{git}}
\def\code#1{\texttt{#1}}
\newcommand\hlink{\hyperlink}
\newcommand\htarget{\hypertarget}
\newcommand\htarget{\hypertarget}%%%
\newcommand{\BM}[1]{\mbox{\boldmath $#1$}}
\newcommand{\BMB}[1]{\mbox{$\mathbb #1$}}
%Yu Pan's commands
\usepackage{tikz}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
% \usepackage{multicol}
% \setlength{\columnsep}{0.5cm}
\tikzset{abs1/.style={xshift=3cm,yshift=2cm}}
\usetikzlibrary{shapes.geometric,arrows,automata}
\tikzstyle{arrow}=
[thick,->,>=stealth]
\tikzstyle{arrow1}=
[thick,dashed,->,>=stealth]
\usepackage{standalone}
\usepackage{rotating}
%end of Yu Pan's commands
\title{A Programmer's Guide to Nektar++}
......@@ -70,6 +91,7 @@
\part{Solvers} \label{part:solvers}
\input{solvers/solvers-master.tex}
\input{solvers/compressible-solver.tex}
%%
\part{Utilities} \label{part:utilities}
......
%
\section{The Fundamentals Behind GlobalMapping}
\ No newline at end of file
\section{The Fundamentals Behind GlobalMapping}
Based upon the appendix in \cite{CantwellYKPS14}, we
outline a rigorous derivation of the Laplace-Beltrami operator.
We use the convention that
indices appearing once in the upper position and once in the lower position are
considered dummy indices and are implicitly summed over their range, while
non-repeated indices are considered free to take any value. Derivatives are also
denoted using the lower-index comma notation, for example $g_{ij,k}$.
{\em Covariant} vectors such as the gradient are those which, under a change of
coordinate system, change under the same transformation in order to maintain
coordinate system invariance. In contrast, {\em contravariant} vectors, such as
velocity, should remain fixed under a coordinate transformation requiring that
their components change under the inverse of the transformation to maintain
invariance.
With this in mind, we now construct the fundamental differential operators we
require for a 2-dimensional manifold embedded in a 3-dimensional space.
In order to express these operators in curvilinear coordinates we start by
assuming that we have a smooth surface parametrization given by
\begin{align*}
\bm{x}(\xi^1,\xi^2):=(x^1(\xi^1,\xi^2),x^2(\xi^1,\xi^2),x^3(\xi^1,\xi^2)).
% \label{A:parametrization}
\end{align*}
Next we will define the Jacobian of $\bm{x}$ as the tensor
\begin{align*}
J_i^j = \frac{\partial x^j}{\partial \xi^i}
% \label{A:jacobian}
\end{align*}
where $J_i^j$ can be viewed as a covariant surface vector (by fixing the upper
index) or as a contravariant space vector (by fixing the lower index). The
surface metric tensor $g_{ij}$ can be defined in terms of the $J_i^j$ as
\begin{align}
g_{ij} = \sum_{k=1}^3 J_i^k J_j^k.
\label{A:metric_tensor}
\end{align}
which can be considered to transform a contravariant quantity to a covariant
quantity. Similarly the conjugate tensor $g^{ij}$, which does the reverse
transformation, is given by
\begin{align}
g^{11} = g_{22}/g,\quad g^{12} = g^{21} = - g_{12}/g,\quad g^{22} = g_{11}/g,
\label{A:conj_tensor}
\end{align}
where $g$ is the determinant of $g_{ij}$. The metric tensor and its conjugate
satisfy the condition
\begin{align*}
\delta_i^j = g_{ik}g^{jk} =
\begin{cases}
1,\; &\mbox{if } i = j,\\
0,\; &\mbox{if } i\ne j.
\end{cases}
\end{align*}
% %
To construct the divergence operator we will also need the derivative of
$g$ with respect to components of the metric, $g_{ij}$. We know that $\bm{g}$
is invertible and from linear algebra we have that the inverse of the metric
\eqref{A:conj_tensor} satisfies
$\bm{g}^{-1} = \frac{1}{g}\tilde{\bm{g}}^{\top}$, where $\bm{\tilde{g}}$ is the
cofactor matrix of $\bm{g}$. Therefore $\bm{\tilde{g}}^{\top} = g\BM{g}^{-1}$,
or in components $\tilde{g}^{ij} = g(\BM{g}^{-1})_{ji}$. Using Jacobi's formula
for the derivative of a matrix determinant with respect its entries, and since
$\bm{g}$ is invertible, the derivative of the metric determinant is
\begin{align}
\frac{\partial g}{\partial g_{ij}} = \mathrm{tr}\left(\tilde{\bm{g}}^{\top}\frac{\partial \bm{g}}{\partial g_{ij}}\right)
= \tilde{g}^{ij} = g(\BM{g}^{-1})_{ji} = gg^{ij}.
\label{A:g_deriv}
\end{align}
\subsection{Divergence operator}
The partial derivative of a tensor with respect to a manifold coordinate system
is itself not a tensor. In order to obtain a tensor, one has to use
\emph{covariant} derivative, defined below.
% %
The covariant derivative of a contravariant vector is given by
\begin{align}
\nabla_k a^i = a^i_{,k} + a^j \Gamma_{jk}^i.
\label{A:cov_diff}
\end{align}
where $\Gamma_{jk}^i$ are \emph{Christoffel Symbols of the second kind}.
% %
The \emph{Christoffel symbols of the first kind} are defined by
\begin{align*}
\Gamma_{ijk} = \frac{1}{2}\left[g_{kj,i} + g_{ik,j} - g_{ij,k}\right].
% \label{A:CS1}
\end{align*}
Here we note that $\Gamma_{ijk}$ is symmetric in the first two indices. To
obtain the Christoffel symbols of the second kind we formally raise the
last index using the conjugate tensor,
\begin{align}
\Gamma_{ij}^l = \Gamma_{ijk}g^{kl}
\label{A:CS2}
\end{align}
which retains the symmetry in the lower two indices. We can now express the
derivatives of the metric tensor in terms of the Christoffel symbols as
\begin{align*}
g_{ij,k} = \Gamma_{ikj} + \Gamma_{jki}
= g_{lj}\Gamma_{ik}^l + g_{li}\Gamma_{jk}^l.
% \label{A:metric_through_CS}
\end{align*}
We now define the divergence operator on the manifold,
$\nabla\cdot \bm{X} = \nabla_k X^k$. Consider first the derivative of the
determinant of the metric tensor $g$ with respect to
the components of some local coordinates system $\xi^1,\xi^2$. We apply the
chain rule, making use of the derivative of the metric tensor with respect to
components of the metric \eqref{A:g_deriv} and the relationship \eqref{A:CS2},
to get
\begin{align}
\frac{\partial g}{\partial \xi^k} = \frac{\partial g}{\partial g_{ij}}\frac{\partial g_{ij}}{\partial \xi^k} =
gg^{ij}g_{ij,k} = gg^{ij}(\Gamma_{ikj} + \Gamma_{jki}) = g(\Gamma_{ik}^i + \Gamma_{jk}^j) = 2g\Gamma_{ik}^i.
\label{A:g_deriv2}
\end{align}
We can therefore express the Christoffel symbol $\Gamma_{ik}^i$ in terms of this
derivative as
\begin{align}
\Gamma_{ik}^i = \frac{1}{2g}\frac{\partial g}{\partial \xi^k} = \frac{1}{\sqrt{g}}\frac{\partial\sqrt{g}}{\partial \xi^k}.
\label{A:G_ik^i}
\end{align}
Finally, by substituting for $\Gamma_{ik}^i$ in the expression for the
divergence operator
\begin{align*}
\nabla_k X^k &= X^k_{,k} + X^i\Gamma_{ki}^k \\
&= X^k_{,k} + X^k\Gamma_{ik}^i \\
&= X^k_{,k} + X^k\frac{1}{\sqrt{g}}(\sqrt{g})_{,k}
\end{align*}
we can deduce a formula for divergence of a contravariant vector as
\begin{align}
\nabla\cdot \bm{X} = \nabla_k X^k = \frac{\left(X^k\sqrt{g}\right)_{,k}}{\sqrt{g}}
\label{A:div}
\end{align}
\subsection{Laplacian operator}
The covariant derivative (gradient) of a scalar on the manifold is identical to
the partial derivative, $\nabla_k \phi = \phi_{,k}$.
To derive the Laplacian operator we need the contravariant form of the covariant
gradient above which can be found by raising the index using the metric tensor,
giving
\begin{align}
\nabla^k \phi = g^{kj}\phi_{,j},
\label{A:covar-div}
\end{align}
and substituting \eqref{A:covar-div} for $X^k$ in \eqref{A:div} to get the Laplacian operator
on the manifold as
\begin{align}
\Delta_M\phi = \frac{1}{\sqrt{g}}\left(\sqrt{g}g^{ij}\phi_{,j}\right)_{,i}.
\label{A:surf_lapl}
\end{align}
\subsection{Anisotropic diffusion}
We now extend the above operator to allow for anisotropic diffusion in the domain by deriving an expression for the surface conductivity from the ambient conductivity. The gradient of a surface function scaled by the ambient conductivity tensor $\tilde{\nabla}^p$ is given by
\begin{align}
\tilde{\nabla}^p f = g^{mp} J^l_m \sigma_{kl} J^k_j g^{ij} \frac{\partial f}{\partial x^i}.
\end{align}
The surface gradient is mapped to the ambient space through the Jacobian $J^k_j$, scaled by the ambient conductivity, and mapped back to the surface through $J^l_m$. The anisotropic Laplacian operator is given by
\begin{align}
\tilde{\nabla}^2 f = \nabla_k \tilde{\nabla}^k f = \nabla_k \tilde{\sigma}^{ij} \nabla_j f
\end{align}
Therefore the surface conductivity tensor can be computed using the Jacobian tensor and the inverse metric as
\begin{align}
\bm{\tilde{\sigma}} = \bm{g^{-1}J\sigma J^{\top} g^{-1}}.
\end{align}
\subsection{Anisotropic Laplacian operator}
\label{s:anisotropic}
Anisotropic diffusion is important in many applications. In the ambient
Euclidean space, this can be represented by a diffusivity tensor $\bm{\sigma}$
in the Laplacian operator as
\begin{align*}
\Delta_M = \nabla \cdot \bm{\sigma} \nabla.
\end{align*}
On our manifold, we seek the generalisation of \ref{A:surf_lapl}, in the form
\begin{align*}
\tilde{\Delta}_M \phi = \nabla_j \tilde{\sigma}_i^j \nabla^i \phi.
\end{align*}
where the $\tilde{\sigma}_i^j$ are entries in the surface diffusivity.
% %
For a contravariant surface vector $a^j$ we can find the associated
space vector $A^i$ as $A^i = J^i_j a^j$. Similarly if $A_i$ is a covariant space vector, then $a_j=J^i_j A_i$ is a covariant surface vector.
% %
Using these we can construct the anisotropic
diffusivity tensor $\tilde{\bm{\sigma}}$ on the manifold by constraining the ambient diffusivity tensor $\bm{\sigma}$ to the surface. The contravariant surface gradient $\nabla^i \phi$ is mapped to the corresponding space vector, which lies in the tangent plane to the surface. This is scaled by the ambient diffusivity and then projected back to a covariant surface vector. Finally, we use the conjugate metric to convert back to a contravariant form. The resulting surface Laplacian is
\begin{align*}
\tilde{\Delta}_M \phi = \nabla_m g^{lm}J^k_l\sigma_{jk}J^j_i \nabla^i \phi.
\end{align*}
Following on from this we deduce that
\begin{align*}
\tilde{\sigma}_i^j = g^{jm} J^l_m \sigma_{lk} J^k_i.
\end{align*}
It can be seen that in the case of isotropic diffusion that $\tilde{\sigma}_i^j = \delta^i_j \Leftrightarrow \bm{\sigma} = \bm{I}$,
\begin{align*}
\tilde{\sigma}_i^j = g^{im} J^k_m \sigma_{lk} J^l_j = g^{im} J^k_m J^k_j = g^{im} g_{mj} = \delta^i_j.
\end{align*}
%
\section{BasicConst}
\lstinputlisting[language=C++, firstline=47, lastline=59]{../../library/LibUtilities/BasicConst/NektarUnivConsts.hpp}
\ No newline at end of file
This directory contains two important files for all of {\nek}: NektarUnivConsts.hpp and NektarUnivTypeDefs.hpp.
The file NektarUnivConsts.hpp contains various default constants used within {\nek} as seen here:
\lstinputlisting[language=C++, firstline=47, lastline=59]{../../library/LibUtilities/BasicConst/NektarUnivConsts.hpp}
The file NektarUnivTypeDefs.hpp contains the low level typedefs such as: NekDouble, NekInt, OneD, TwoD, ThreeD, FourD, and
enumerations such as Direction (xDir, yDir and zDir) and OutputFormat.
%
\section{BasicUtils}
This directory contains some of the lowest level basic computer science routines within {\nek}.
The directory currently contains the following:
\begin{center}
\begin{tabular}{|c | c | c |} \hline
ArrayEqualityComparison.cpp & ArrayPolicies.hpp & CompressData.cpp \\ \hline
CompressData.h & ConsistentObjectAccess.hpp & CsvIO.cpp \\ \hline
CsvIO.h & Equation.cpp & Equation.h \\ \hline
ErrorUtil.hpp & FieldIO.cpp & FieldIO.h \\ \hline
FieldIOHdf5.cpp & FieldIOHdf5.h & FieldIOXml.cpp \\ \hline
FieldIOXml.h & FileSystem.cpp & FileSystem.h \\ \hline
H5.cpp & H5.h & HashUtils.hpp \\ \hline
Metis.hpp & {\bf NekFactory.hpp} & {\bf NekManager.hpp} \\ \hline
OperatorGenerators.hpp & ParseUtils.cpp & ParseUtils.h \\ \hline
Progressbar.hpp & PtsField.cpp & PtsField.h \\ \hline
PtsIO.cpp & PtsIO.h & RawType.hpp \\ \hline
Scotch.hpp & SessionReader.cpp & SessionReader.h \\ \hline
ShapeType.hpp & SharedArray.hpp & Tau.hpp \\ \hline
Thread.cpp & Thread.h & ThreadBoost.cpp \\ \hline
ThreadBoost.h & Timer.cpp & Timer.h \\ \hline
VDmath.hpp & VDmathArray.hpp & Vmath.cpp \\ \hline
{\bf Vmath.hpp} & VmathArray.hpp & VtkUtil.hpp \\ \hline
\end{tabular}
\end{center}
We have used {\bf bold} to denote (as examples) routines at our used throughout {\nek}. They are in this sense ``fundamental''.
Note that this list includes input/output routines (e.g. CompressData, FieldIo, H5), partitioning (e.g. Metis and Scotch) and Threading (e.g. Thread and ThreadBoost).
\ No newline at end of file
%
\section{Communication}
This directory contains files related to our distributed memory communication model. In particular, this directory contains files that help encapsulate MPI (Message Passing Interface) routines, as well
as the Gather-Scatter (GS) and Xxt routines of Paul Fisher (Argonne National Lab and UIUC).
\begin{center}
\begin{tabular}{|c | c | c |} \hline
Comm.cpp & CommMpi.cpp & GsLib.hpp \\ \hline
Comm.h & CommMpi.h & Transposition.cpp \\ \hline
CommDataType.cpp & CommSerial.cpp & Transposition.h \\ \hline
CommDataType.h & CommSerial.h & Xxt.hpp \\ \hline
\end{tabular}
\end{center}
\ No newline at end of file
%
\section{FFT}
This directory contains files related to the use of Fast Fourier Transforms within {\nek}. The two groups of files are as follows:
\begin{itemize}
\item NekFFTW.h/NekFFTW.cpp : Wrapper around FFTW library; and
%
\item NektarFFT.h/NektarFFT.cpp : Fast Fourier Transform base class in {\nek}.
\end{itemize}
\ No newline at end of file
This diff is collapsed.
%
\section{Interpreter}
This directory contains two files, AnalyticExpressionEvaluator.hpp and AnalyticExpressionEvaluator.cpp, both of which provide
parser and evaluator functionality of analytic expressions.
\ No newline at end of file
%
\section{Kernel}
This directory contains two files, kernel.h and kernel.cpp, both of which are related to the line-SIAC (L-SIAC) filtering \cite{sanchez2016multi,jallepalli2017treatment} of FEM solutions.
SIAC filtering takes the form:
$$
u^*(x) = \int_{-\infty}^{\infty} K_H\left(\frac{\xi - x}{H}\right) u_h(\xi) \, d\xi
$$
\noindent where $u_h$ denotes the FEM (continuous Galkerkin or discontinuous Galerkin) solution and $K_H$ represents a kernel function:
$$
K_H(x) = \frac{1}{H} \sum_{\gamma = 0}^M c_\gamma \psi\left(\frac{x}{H} - \zeta_\gamma \right).
$$
In this expression, the functions $\psi(x)$ are B-Splines. The two kernel files in this directory provide all the tools needed to construct the B-Spline functions and the kernel function described above.
\ No newline at end of file
%
\section{Linear Algebra}
\ No newline at end of file
\section{Linear Algebra}
This directory contains files related to linear algebra operations. Files such as NekMatrix, BlockMatrix and NekLinearSystem are fundamental to many of the operations we do within {\nek}.
These files represent our attempt to encapsulate linear algebra operations in a way that make sense from the programmer perspective but for which we do not loose efficiency. As can be seen in these
routines and throughout the code, we rely heavily on BLAS (Basic Linear Algebra Subroutines).
\begin{center}
\begin{tabular}{|c | c | c |} \hline
Arpack.hpp & Blas.hpp & BlasArray.hpp \\ \hline
BlockMatrix.cpp & BlockMatrix.hpp & CanGetRawPtr.hpp \\ \hline
ExplicitInstantiation.h & Lapack.hpp & MatrixBase.cpp \\ \hline
MatrixBase.hpp & MatrixFuncs.cpp & MatrixFuncs.h \\ \hline
MatrixOperations.cpp & MatrixOperations.hpp & MatrixStorageType.h \\ \hline
MatrixType.h & MatrixVectorMultiplication.cpp & NekLinAlgAlgorithms.hpp \\ \hline
NekLinSys.hpp & NekMatrix.hpp & NekMatrixFwd.hpp \\ \hline
NekPoint.hpp & NekTypeDefs.hpp & NekVector.cpp \\ \hline
NekVector.hpp & NekVectorFwd.hpp & NistSparseDescriptors.hpp \\ \hline
PointerWrapper.h & ScaledMatrix.cpp & ScaledMatrix.hpp \\ \hline
SparseDiagBlkMatrix.cpp & SparseDiagBlkMatrix.hpp & SparseMatrix.cpp \\ \hline
SparseMatrix.hpp & SparseMatrixFwd.hpp & SparseUtils.cpp \\ \hline
SparseUtils.hpp & StandardMatrix.cpp & StandardMatrix.hpp \\ \hline
StorageSmvBsr.cpp & StorageSmvBsr.hpp & TransF77.hpp \\ \hline
blas.cpp & & \\ \hline
\end{tabular}
\end{center}
\ No newline at end of file
%
\section{Memory}
This directory contains three files, NekMemoryManager.hpp, ThreadSpecificPools.hpp and ThreadSpecificPools.cpp.
The strategy used within {\nek} was to preallocate a pool of arrays that could be used for various operations and then
released back to the pool. This idea came about through profiling of the code early on -- noticing that the new/delete
operation of lots of small arrays used for temporary calculations was greatly slowing down the code. Like with our manager
idea, we decided to invest in having a memory pool object what preallocated blocks of memory that could be requested and
then returned back to the pool.
If {\nek} is compiled with \verb+NEKTAR_MEMORY_POOL_ENABLED+, the MemoryManager
allocates from thread specific memory pools for small objects. Large objects are managed with the
system supplied new/delete. These memory pools provide faster allocation and deallocation
of small objects (particularly useful for shared pointers which
allocate many 4 byte objects).
All memory allocated from the memory manager must be returned
to the memory manager. Calling delete on memory allocated from the
manager will likely cause undefined behavior. A particularly subtle
violation of this rule occurs when giving memory allocated from the
manager to a shared pointer.
%
\section{Polylib}
This directory contains polylib.h and polylib.cpp. These files contain foundational routines used for computing various operations related to Jacobi polynomials.
The following abbreviations are used throughout the file:
\begin{itemize}
\item z -- Set of collocation/quadrature points
%
\item w -- Set of quadrature weights
%
\item D -- Derivative matrix
%
\item h -- Lagrange Interpolant
%
\item I -- Interpolation matrix
%
\item g -- Gauss
%
\item k -- Kronrod
%
\item gr -- Gauss-Radau
%
\item gl -- Gauss-Lobatto
%
\item j -- Jacobi
%
\item m -- point at minus 1 in Radau rules
%
\item p -- point at plus 1 in Radau rules
\end{itemize}
\paragraph{Points and Weights: } The following routines are used to compute points and weights:
\begin{itemize}
\item zwgj -- Compute Gauss-Jacobi points and weights
%
\item zwgrjm -- Compute Gauss-Radau-Jacobi points and weights ($z=-1$)
%
\item zwgrjp -- Compute Gauss-Radau-Jacobi points and weights ($z=1$)
%
\item zwglj -- Compute Gauss-Lobatto-Jacobi points and weights
%
\item zwgk -- Compute Gauss-Kronrod-Jacobi points and weights
%
\item zwrk -- Compute Radau-Kronrod points and weights
%
\item zwlk -- Compute Lobatto-Kronrod points and weights
%
\item JacZeros -- Compute Gauss-Jacobi points and weights
\end{itemize}
\paragraph{Derivative Matrices: } The following routines are used to compute derivative matrices:
\begin{itemize}
\item Dgj -- Compute Gauss-Jacobi derivative matrix
%
\item Dgrjm -- Compute Gauss-Radau-Jacobi derivative matrix ($z=-1$)
%
\item Dgrjp -- Compute Gauss-Radau-Jacobi derivative matrix ($z=1$)
%
\item Dglj -- Compute Gauss-Lobatto-Jacobi derivative matrix
\end{itemize}
\paragraph{Lagrange Interpolants: } The following routines are used to compute Lagrange interpolation matrices:
\begin{itemize}
\item hgj -- Compute Gauss-Jacobi Lagrange interpolants
%
\item hgrjm -- Compute Gauss-Radau-Jacobi Lagrange interpolants ($z=-1$)
%
\item hgrjp -- Compute Gauss-Radau-Jacobi Lagrange interpolants ($z=1$)
%
\item hglj -- Compute Gauss-Lobatto-Jacobi Lagrange interpolants
\end{itemize}
\paragraph{Interpolation Operators: } The following routines are used to compute various interpolation operators:
\begin{itemize}
\item Imgj -- Compute interpolation operator gj->m
%
\item Imgrjm -- Compute interpolation operator grj->m ($z=-1$)
%
\item Imgrjp -- Compute interpolation operator grj->m ($z=1$)
%
\item Imglj -- Compute interpolation operator glj->m
\end{itemize}
\paragraph{Polynomial Evaluation: } The following routines are used to evaluate Jacobi polynomials.
\begin{itemize}
\item jacobfd -- Returns value and derivative of Jacobi polynomial at point z
%
\item jacobd -- Returns derivative of Jacobi polynomial at point z (valid at $z=-1,1$)
\end{itemize}
\ No newline at end of file
%
\section{Time Integration}
This directory consists of the following files:
\begin{center}
\begin{tabular}{|c | c | } \hline
TimeIntegrationScheme.h & TimeIntegrationScheme.cpp \\ \hline
TimeIntegrationWrapper.h & TimeIntegrationWrapper.cpp \\ \hline
\end{tabular}
\end{center}
The original time-stepping classes (found in TimeIntegrationScheme) where implemented by Vos et al. \cite{Vostime} and a detailed explanation of the mathematics and computer science concepts are provided there.
After the original implementation, Cantwell et al. extended Vos' original work by adding the time-stepping routines into a factory pattern (found in TimeIntegrationWrapper).
\ No newline at end of file
......@@ -39,10 +39,25 @@ The various private, protected and public data members contained within LocalReg
\paragraph{Private:}
There are private methods but no private data members within Expansion.
\paragraph{Protected:}
As discussed above, the primary data in LocalRegions that distinguishes it from StdExpansions is the {\em has-a} relationship with SpatialDomains, given by the following:
\begin{itemize}
\item SpatialDomains::GeometrySharedPtr \verb+m_geom+
%
\item SpatialDomains::GeomFactorsSharedPtr \verb+m_metricinfo+
%
\item MetricMap \verb+m_metrics+
\end{itemize}
\paragraph{Public:}
There are public methods but no public data members within Expansion.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Variables at the Level of Expansion\$D for various Dimensions}
......
%
\section{The Fundamentals Behind MultiRegions}
\ No newline at end of file
\section{The Fundamentals Behind MultiRegions}
Up to now in the library, the various data structures and methods associated with standard regions, spatial domains and local regions are not
specifically dictated by any particular numerical method. In fact, at this stage, they can all be viewed in light of approximation theory. With
local regions in place, we have a region in world space over which we can represent an expansion (i.e. linear combination of basis functions)
and form its derivatives and its integral. It is at the level of MultiRegions that we now combine two fundamental concepts: the idea of a collection
of elements together to form a ``global" expansion and the idea of how these (local) elements communicate (in the sense of how does one form
approximations of a PDE of these collections of elements). Hence MultiRegions is important because it gives us a way of dealing with general tessellation and
also because it is the first place at which we can connect to a specific numerical PDE approximation methods of choice (i.e. continuous Galerkin FEM methods,
discontinuous Galerkin finite volume methods, etc.).
Because MultiRegions is both about grouping of elements in space (to form a domain) and about solving PDEs over these domains, you will find two primary
collections of routines contained within the MultiRegions directory. You will find things related to collections of elements: ExpList (Expansion List), DisContField (discontinuous
field) and ConField (continuous field); and you will find objects related to the linear systems formed based upon the particular numerical method once selects (i.e. GlobalLinSys,
which stands for Global Linear System).
At present, the {\nek} framework supports three types of numerical PDE discretizations for conservation laws:
\begin{itemize}
\item {\bf Discontinuous Galerkin Methods:} These weak-form (variational) methods do not require element continuity, but do put restrictions on the flux of information between elements. In general, these methods can be thought of as being in the class of finite volume (FV) methods. One feature of these methods that is often exploited computationally is that
many operations can be considered as elemental. See \cite{CockburnKS,HesthavenW08} and references therein for a more complete summary.
%
\item {\bf Continuous Galkerin Methods:} These weak-form (variational) methods require at least $C^0$ continuity. Mathematically, there have been extensions to
higher levels of continuity, e.g. Isogeometric Analysis \cite{CottrellISO}, these are not implemented in {\nek} and would require further constraints on our SpatialDomain
representations than we currently accommodate. In general, these methods can be thought of as being in the class of finite element methods (FEM). Although
these methods are technically (mathematically) formulated as global methods, their elemental construction and compact basis types allow for many local operations.
Many (but not all) of the linear system routines that are contained with the MultiRegions directory are focussed on this discretization type.
See \cite{Schwab, DevilleFM02,KaSh05} and references therein for a more complete summary.
%
\item {\bf Flux Reconstruction Methods:} These strong-form methods do not require element continuity, but like dG methods they impose restrictions on the flux of information between elements. In general, these methods can be though of as being in the class of generalized finite difference (FD) or collocating methods.
See \cite{Kopriva,WitherdenVJ2016} and references therein for a more complete summary.
\end{itemize}
\paragraph{Assembly Map}
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/Assembly1.pdf}
\caption{Diagram to help explain assembly. UPDATE.}
\label{multiregions:assembly1}
\end{figure}
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/Assembly2.pdf}
\caption{Diagram to help explain assembly. UPDATE.}
\label{multiregions:assembly2}
\end{figure}
......@@ -89,38 +89,102 @@ geometric file formats assume the former -- that curve information is provided t
the modal values and store these values within SpatialDomain data structures.
Assuming we now have, for each element, a way of specifying the mapping function $\chi(\vec{\xi})$, we can now move to how we compute the geometric
factors for regular as well as for deformed mappings.
factors for regular as well as for deformed mappings.
We use the term ``regular mappings" to refer to mappings from reference space elements to world space elements with the same dimension. For instance, a
collection of triangles that lie in a plane can be represented by vertex coordinates that an only 2-tuples and the mappings between the reference space
triangle the and world space triangle does not need to consider a larger embedded dimension. This was a fundamental assumption of the original
Nektar code: segments lived on the 1D line, triangles and quadrilaterals lived on the 2D plane and that hexahedra, tetrahedra, etc., lived in the 3D
volume. When redesigning {\nek}, we purposefully enabled geometric entities to live in a high-dimensional embedding space, different from their
parameterized dimension. For instance, in {\nek}, it is possible to define segment expansions (functions that live over one dimensional parameterized
curves) that are embedded in 3D. The same is true for quadrilaterals and triangles -- although their parameterized dimension is two, both may live in
a higher dimensional embedding space and thus represent a {\em manifold} of co-dimension one in that space. For mappings that maintain the
co-dimension is the opposite of the dimension (i.e., quadrilateral in a plane represented by vertices with two coordinates mapped to a two parameter
reference quadrilateral), we keep to the mapping conventions originally outlined in \cite{KaSh05} and denote these mapping operations in the code by the enumerated
value {\em Regular}; for mappings in which the co-dimension is greater than zero, we following the modified convention outlined in \cite{CantwellYKPS14} and denote
these mapping operations in the code by the enumerated value {\em Deformed}.
\subsection{Regular Mappings: Geometric Factors}
Following \cite{KaSh05}, we assume that the vertex positions of an element in world space are given by $\vec{x} = x_i$ and that our reference space
coordinates are given by $\vec{\xi} = \xi_j$, there $i \text{ and } j$ run from zero to $dim-1$ where $dim$ is the parameter dimension of the element (e.g.
for a triangle, $dim = 2$).
The Jacobian (matrix) is correspondingly defined as:
\begin{equation} \label{eqn:jacobianmat}
{\bf J} = \frac{\partial x_i}{\partial \xi_j}.
\end{equation}
Note that this matrix is always square, but also note that it is not always constant across an element. Only in special cases such as the
linear mapping of triangles and tetrahedra does the Jacobian matrix reduce to a constant (matrix) over the entire element. In general,
this matrix can be evaluated at any point over the element for which it is constructed.
$$
{\bf J} = \frac{\partial x_i}{\partial \xi_j}
$$
There are two (high-level) times in which this information is needed: when computing derivatives and when computing
integrals. When computing derivatives, we employ the chain rule for differentiation, which in Einstein notation is given by the following expression:
$$
{\bf g} = {\bf J}^T{\bf J}
\frac{\partial}{\partial x_i} = \frac{\partial \xi_j}{\partial x_i} \frac{\partial}{\partial \xi_j}.
$$
$$
g = \det{\bf g}
$$
Note that this expression requires the reciprocal of the expression above -- that is, ${\bf J}^{-1}$. The polynomial mappings we use in {\nek}
are defined in terms of their forward mappings (reference to world). If the determinant of the mapping is non-zero, the inverse of the mapping
exists but is not available analytically (except is special cases). As a consequence, we in general limit the places at which we compute
the inverse of the Jacobian. Typically, the quadrature point positions are the places at which you need these values (since it as at these
points we take physical space derivates and then use integration rules to construct weak form operators). Thus, procedurally, we do the following:
\begin{enumerate}
\item For a given element, compute the Jacobian matrix using the expression given in Equation \ref{eqn:jacobianmat} for each quadrature point
position on the element (or for any points positions within an element at which it is needed).
\item Explicitly form the inverse of the matrix at each point position.
\end{enumerate}
Because we accomplish the inversion of the Jacobian matrix at particular positions, this introduces an approximation to this computation.
Although the inverse Jacobian matrix can be computed exactly at each point -- when we then correspondingly use this information
in the inner product over an element -- we are in effect assuming that we are using a polynomial interpolative projection of this operator.
The approximation error is introduced at the point of our quadrature approximation. Although the forward mapping is polynomial and hence
we could find a polynomial integration rule and number of points/weights to integrate our bilinear forms exactly, our use of the inverse
mapping in our bilinear forms means that we can only approximate our integrals. From our experiments, the impact of his is negligible
in most cases, and only becomes in a concern in highly curved geometries. In such cases, over-integration might be requires to minimize
the errors introduced due this approximation.
The other place at which we need the Jacobian matrix is to compute its determinant to be used in integration. The determinant of the Jacobian
matrix (sometimes also called ``the Jacobian" of the mapping) provides us the scaling of the metric terms used in integration. In all our
computations, we assume that the determinant of the Jacobian matrix is strictly positive. In the area of mesh generation, the value
of the determinant is used to estimate how good or bad the quality of the mapping is -- in effect, if you have reasonable elements in your mesh.
Negative Jacobian elements are inadmissible but even elements with small Jacobian determinants might cause issues. At
the level of the library and solvers, we assume that these issues have been addressed by the user prior to attempting to run {\nek}
solvers and interpret their results.
gmat and jac
\subsection{Deformed Mappings: Geometric Factors}
note that gmat is a tensor defined at each point, and jac is the determinant of the jacobian.
Following \cite{CantwellYKPS14}, we again assume that the vertex positions of an element in world space are given by $\vec{x} = x_i$ and that our reference space
coordinates are given by $\vec{\xi} = \xi_j$, there $i$ runs from zero to $dim-1$ where $dim$ is the embedding dimension and $j$ runs from zero to $M-1$ where $M$
is the parameter dimension of the element (e.g.for a triangle on a manifold embedded in 3D with vertex values in 3D, $dim = 3$ whilst $M=2$).
The Jacobian (matrix) is correspondingly defined as:
\begin{equation} \label{eqn:jacobianmat}
{\bf J} = J^i_j = \frac{\partial x_i}{\partial \xi_j}.
\end{equation}
In this case, we use the notational conventions of \cite{Ar89} which delineate covariant and contravariant forms. In general, this matrix is not square,
also also note that it is not always constant across an element. In general, this matrix can be evaluated at any point over the element for which it is constructed.
The metric tensor related to this transformation can be formed as:
\subsection{Deformed Mappings: Geometric Factors}
$$
{\bf g} = {\bf J}{\bf J}^T
$$
\noindent and the Jacobian factor associated with this mapping is then given by:
$$
g = \det{\bf g}.
$$
Because various mappings are necessary when dealing with covariant and contravariant vectors, we have encapsulated all these routines
into the directory GlobalMapping (see Chapter \ref{chapter:globalmapping}). At this stage, we do not implement general Piola transformations \cite{McRaeBMHC} that further respect $H(div)$ and $H(curl)$ constraints on these mappings
as would be needed in solid mechanics or electromagnetics; however, there is nothing inherent within the {\nek} framework that would preclude someone from
adding these additional features as necessary.
......@@ -91,19 +91,55 @@ The various private, protected and public data members contained within StdRegio
\paragraph{Private:}
There are private methods but no private data members within StdExpansion.
\paragraph{Protected:}
\begin{itemize}
\item Array of Basis Shared Pointers: \verb+m_base+
%
\item Integer element id: \verb+m_elmt_id+
%
\item Integer total number of coefficients in the expansion: \verb+m_ncoeffs+
%
\item Matrix Manager: \verb+m_stdMatrixManager+
%
\item Matrix Manager: \verb+m_stdStaticCondMatrixManager+
%
\item IndexKeyMap Matrix Manager: \verb+m_IndexMapManager+
\end{itemize}
\paragraph{Public:}
There are public methods but no public data members within StdExpansion.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Variables at the Level of StdExpansion\$D for various Dimensions}
\paragraph{Private:}
There are private methods but no private data members within StdExpansion\$D.
\paragraph{Protected:}
\begin{itemize}
\item 0D and 1D: std::map<int, NormalVector> \verb+m_vertexNormals+
%
\item 2D: Currently does not have any data structure. It should probably have \verb+m_edgeNormals+
%
\item 3D: std::map<int, NormalVector> \verb+m_faceNormals+
%
\item 3D: std::map<int, bool> \verb+m_negatedNormals+
\end{itemize}
\paragraph{Public:}
There are public methods but no public data members within StdExpansion\$D.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Variables at the Level of Shape-Specific StdExpansions}
......
......@@ -25,13 +25,13 @@ The standard tetrahedra (shorthanded 'tet') is built upon the standard triangle
triangles along the coordinate directions looking like the standard triangle. The standard prism consists of a standard
triangle along the $\xi_1--\xi_2$ plane extruded into the third direction (yielding three quadrilateral faces). The standard
pyramid consists of a standard quadrilateral at the base with four triangular faces reaching up to its top vertex We show this
pictorially in Figure \ref{stdregions:shapes}.
pictorially in Figure \ref{stdregions:3dshapes}.
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/refelement.pdf}
\caption{FIX THIS IMAGE WITH 3D: Example of the four three dimensional shapes: hexahedra, tetrahedra, prism and pyramid).}
\includegraphics[width=4in]{img/LocalCoords.pdf}
\caption{Hexahedron to tetrahedron transformation showing how to go from an element on $[-1,1]^3$ (i.e. a standard hexahedron) to the three other element types which are subsets on $[-1,1]^3$. Image taken from \cite{KaSh05}.}
\label{stdregions:3dshapes}
\end{figure}
......@@ -113,8 +113,8 @@ operations are shown in Figure \ref{stdregions:3Dduffy}.
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/afg002.pdf}
\caption{FIX THIS IMAGE WITH 3D: Duffy mapping application to generate all the 3D element types.}
\includegraphics[width=4in]{img/3dcoords.pdf}
\caption{Duffy mapping application to generate all the 3D element types. Image taken from \cite{KaSh05}.}
\label{stdregions:3Dduffy}
\end{figure}
......
......@@ -9,7 +9,6 @@ relevance to the code. Since all of these items are considered foundational to
should all be considered equally important and relevant. Along the same lines -- since all of
these areas of the code represent the deepest members of the code hierarchy, these
items should rarely be modified.
%
\input{library/LibUtilities/basicconst.tex}
%
......@@ -151,10 +150,12 @@ algorithms -- expressed as either object methods or functions -- employed over t
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Inside the Library: GlobalMapping}
\label{chapter:globalmapping}
In this chapter, we walk the reader through the different components of the GlobalMapping Directory.
We begin with a discussion of the mathematical fundamentals, for which we use the book
by Karniadakis and Sherwin \cite{KaSh05} as our principle reference. We then provide
We begin with a discussion of the mathematical fundamentals, for which we use research article by
Cantwell et al. \cite{CantwellYKPS14} and the book \cite{Ar89}
as our principle references. We then provide
the reader with an overview of the primary data structures introduced within the
GlobalMapping Directory (often done through C++ objects), and then present the major
algorithms -- expressed as either object methods or functions -- employed over these data structures.
......
\documentclass{standalone}
\usepackage{tikz}
% create a new adjust box
\usepackage{tikzscale}
\usepackage{lscape}
\usepackage{tikz}
% use to adjust the positionS
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\tikzset{abs1/.style={xshift=3cm,yshift=2cm}}
\usetikzlibrary{shapes.geometric,arrows,automata}
\tikzstyle{arrow}=
[thick,->,>=stealth]
\tikzstyle{arrow1}=
[thick,dashed,->,>=stealth]
\begin{document}
\begin{tikzpicture}[scale=0.2,node distance=1cm]
\node (A)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=black!15]
{CompressibleFlowSolverSystem};
\node (B1)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=black!20,
left = of A,
xshift=0cm,
yshift=2cm]
{EulerCFE};
\draw[arrow](B1)--($(B1.east)+(1,0)$)|-(A.west);
\node (B2)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=black!20,
left = of A]
{NavierStokesCFE};
\draw[arrow](B2)--(A);
\node (A1)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of A,
xshift=-2cm,
yshift=0cm]
{RiemannSolver};
\node (A2)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of A1,
xshift=0cm,
yshift=-4cm]
{CFSBndConditions};
\draw[arrow1]($(A.south)+(8cm,0)$)|-(A2.east);
\node(text9)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
right =of A2,
xshift=-1cm,
yshift=-0.5cm]
{m$\_$bndConds};
\node (A3)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=black!5,
below = of A1,
xshift=0cm,
yshift=0cm]
{DiffusionLDGNS};
\draw[arrow1](B2.south)|-(A3.west);
\node(text4)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
left =of A3,
xshift=1cm,
yshift=0.5cm]
{m$\_$diffusion};
\node (A4)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of A3,
xshift=0cm,
yshift=0cm]
{ArtificialDiffusion};
\draw[arrow1](B2.south)|-(A4.west);
\node(text5)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
left =of A4,
xshift=1cm,
yshift=0.5cm]
{m$\_$artificialdiffusion};
\node(text11)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
right =of A4,
xshift=-1.5cm,
yshift=1cm]
{m$\_$artificialdiffusion};
\node (C)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=black!10,
right = of A]
{AdvectionSystem};
\draw[arrow](A)--(C);
\node (C1)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of C]
{Advection};
\draw[arrow1]($(A.south)+(8cm,0)$)|-(C1.west);
\node(text6)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
left =of C1,
xshift=1cm,
yshift=0.5cm]
{m$\_$advObject};
\node(text7)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
left =of C1,
xshift=-1.5cm,
yshift=-0.5cm]
{m$\_$riemnn};
\draw[arrow1](A1)--(C1);
\node (C2)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of C1]
{Diffusion};
\draw[arrow](A3)--(C2);
\draw[arrow1](A4)--($(A4.east)+(5cm,0)$)|-(C2);
\node(text8)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
left =of C2,
xshift=1cm,
yshift=0.5cm]
{m$\_$diffusion};
\node (C3)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of C2]
{forcing};
\draw[arrow1]($(A.south)+(8cm,0)$)|-(C3.west);
\node(text9)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
left =of C3,
xshift=1cm,
yshift=0.5cm]
{m$\_$forcing};
\node (D1)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=black!5,
right = of C]
{UnsteadySystem};
\draw[arrow](C)--(D1);
\node (D2)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
below = of D1]
{EquationSystem};
\draw[arrow](D1)--(D2);
\node (D3)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
accepting,
fill=black!0,
above= of D1]
{TimeIntegrationScheme};
\draw[arrow1](D1)--(D3);
\node(text12)
[
minimum width=2cm,
minimum height=1cm,
text centered,
fill opacity=1,
above =of D1,
xshift=0cm,
yshift=-1cm]
{m$\_$intScheme};
%\node (D4)
%[rectangle,
%rounded corners,
%minimum width=3cm,
%minimum height=1cm,
%text centered,
%draw=black,
%fill=black!0,
%below = of D2]
%{Explist};
%%\draw[arrow](D4)--(D5);
%\node(text1)
%[
%minimum width=2cm,
%minimum height=1cm,
%text centered,
%fill opacity=1,
%right =of D1]
%{m$\_$explist};
\draw[line width=0.25mm, black](-40cm,-50cm)--(75cm,-50cm);
\draw[line width=0.25mm, black](-40cm,20cm)--(75cm,20cm);
\draw[line width=0.25mm, black](-40cm,-50cm)--(-40cm,20cm);
\draw[line width=0.25mm, black](75cm,-50cm)--(75cm,20cm);
\draw [arrow](55,-20)--(60,-20);
\node (text15) at (48,-20) {Inheritance};
\draw [arrow1](55,-25)--(60,-25);
\node (text14) at (48,-25) {Date
Footprint };
\node (text13) at (48,-30) {Factory};
\node (text14)
[rectangle,
rounded corners,
minimum width=1cm,
minimum height=0.5cm,
text centered,
draw=black,
accepting,
fill=black!0,
right= of text13,
xshift=-0.5cm,
yshift=0cm]
{};
\draw[line width=0.25mm, black,dotted](15cm,-50cm)--(15cm,20cm);
\node (text10) at (-15,-52) {\textbf{Solver}};
\node (text11) at (45,-52) {\textbf{Library}};
% \draw[line width=0.2mm, blue](-50cm,-50cm)--(80cm,-50cm);
% \draw[line width=0.2mm, blue](-50cm,-50cm)--(80cm,-50cm);
\end{tikzpicture}
\end{document}
\documentclass{standalone}
\usepackage{tikz}
% create a new adjust box
\usepackage{tikzscale}
\usepackage{lscape}
\usepackage{tikz}
% use to adjust the positionS
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\tikzset{abs1/.style={xshift=3cm,yshift=2cm}}
\usetikzlibrary{shapes.geometric,arrows}
\tikzstyle{arrow}=
[thick,->,>=stealth]
\begin{document}
\begin{tikzpicture}[scale=0.2,node distance=2cm]
\node (A)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=red!30]
{CompressibleFlowSolver::drv$->$GetDriverFactory};
\node (B)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=blue!20,
below of=A,
xshift=0cm,
yshift=0cm]
{Initialize the driver\\eg. DriverStandard::v$\_$InitObject};
\draw[arrow](A)--(B);
\node (C)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=yellow!20,
below of=B,
xshift=0cm,
yshift=0cm]
{eg. NavierStokesCFE::v$\_$InitObject};
\draw[arrow](B)--(C);
\node (D_1)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=green!20,
below of=C,
xshift=-5cm,
yshift=0.5cm]
{CompressibleFlowSystem::v$\_$InitObject};
\draw[arrow]($(C.south)+(15cm,0)$)|-(D_1);
\node (D_2)
[rectangle,
rounded corners,
minimum width=5cm,
minimum height=1cm,
text width=5cm,
text centered,
draw=black,
fill=green!20,
below of=C,
xshift=3cm,
yshift=-1cm]
{m$\_$diffusion$->$InitObject};
\draw[arrow]($(C.south)+(15cm,0)$)--(D_2);
\node (E_1)
[rectangle,
rounded corners,
minimum width=6cm,
minimum height=1cm,
text width=6cm,
text centered,
draw=black,
fill=teal!20,
below of=D_1,
xshift=-1cm,
yshift=0cm]
{AdvectionSystem::v$\_$InitObject};
\draw[arrow]($(D_1.south)+(-5cm,0)$)--(E_1);
\node (E_2)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=teal!20,
below of=D_2,
xshift=0cm,
yshift=0cm]
{Specific CFS advection-related object\\eg. RiemannSolver::v$\_$InitObject};
\draw[arrow]($(D_1.south)+(-5cm,-2cm)$)--($(D_1.south)+(15cm,-2cm)$)--++(0,-2cm)|-(E_2.west);
% \draw[arrow](D_1)--(E_2);
\node (E_3)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=teal!20,
below of=E_2,
xshift=0cm,
yshift=0cm]
{Specific CFS boundary-related object m$\_$bndConds};
\draw[arrow]($(D_1.south)+(-5cm,-2cm)$)--($(D_1.south)+(15cm,-2cm)$)--++(0,-2cm)|-(E_3.west);
% \draw[arrow](D_1)--(E_3);
\node (F)
[rectangle,
rounded corners,
minimum width=6cm,
minimum height=1cm,
text width=6cm,
text centered,
draw=black,
fill=orange!20,
below of=E_1,
xshift=0cm,
yshift=0cm]
{UnsteadySystem::v$\_$InitObject};
\draw[arrow](E_1)--(F);
\node (G_1)
[rectangle,
rounded corners,
minimum width=6cm,
minimum height=1cm,
text width=6cm,
text centered,
draw=black,
fill=purple!20,
below of=F,
xshift=0cm,
yshift=-2cm]
{EquationSystem::v$\_$InitObject};
\draw[arrow](F)--(G_1);
\node (G_2)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=purple!20,
below of=F,
xshift=8cm,
yshift=-1cm]
{TimeIntegrationSystem::v$\_$InitObject};
\draw[arrow](F)|-(G_2)node[midway,xshift=2cm,yshift=0.3cm]{If unsteady};
\node (H)
[rectangle,
rounded corners,
minimum width=7cm,
minimum height=1cm,
text width=7cm,
text centered,
draw=black,
fill=lime!20,
below of=G_1,
xshift=0cm,
yshift=0cm]
{BoundaryConditions::v$\_$InitObject};
\draw[arrow](G_1)--(H);
\end{tikzpicture}
\end{document}
\ No newline at end of file
\documentclass{standalone}
\usepackage{tikz}
% create a new adjust box
\usepackage{tikzscale}
\usepackage{lscape}
\usepackage{tikz}
% use to adjust the positionS
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\tikzset{abs1/.style={xshift=3cm,yshift=2cm}}
\usetikzlibrary{shapes.geometric,arrows}
\tikzstyle{arrow}=
[thick,->,>=stealth]
\begin{document}
\begin{tikzpicture}[scale=0.2,node distance=2cm]
\node (A)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,
fill=red!30]
{CompressibleFlowSolver::drv$->$Execute};
\node (B)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=blue!20,
below of=A,
xshift=0cm,
yshift=0cm]
{Do Initialization, eg. DriverStandard::v$\_$Execute: $m\_equ[0]->DoInitialise$};
\draw[arrow](A)--(B);
\node (C)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=yellow!20,
below of=B,
xshift=0cm,
yshift=0cm]
{UnsteadySystem::v$\_$DoInitialise};
\draw[arrow](B)--(C);
\node (D_1)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=green!20,
below of=C,
xshift=-5cm,
yshift=0cm]
{EquationSystem::SetBoundaryConditions};
\draw[arrow](C)|-(D_1);
\node (D_2)
[rectangle,
rounded corners,
minimum width=10cm,
minimum height=1cm,
text width=10cm,
text centered,
draw=black,
fill=green!20,
below of=C,
xshift=0cm,
yshift=-2cm]
{CompressibleFlowSystem::v$\_$SetInitialConditions};
\draw[arrow](C)--(D_2);
\node (E_1)
[rectangle,
rounded corners,
minimum width=8cm,
minimum height=1cm,
text width=8cm,
text centered,
draw=black,
fill=teal!20,
below of=D_2,
xshift=0cm,
yshift=0cm]
{EquationSystem::v$\_$SetInitialConditions};
\draw[arrow](D_2)--(E_1);
\end{tikzpicture}
\end{document}
\ No newline at end of file
\documentclass{standalone}
\usepackage{tikz}
% create a new adjust box
\usepackage{tikzscale}
\usepackage{lscape}
\usepackage{tikz}
% use to adjust the positionS
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\tikzset{abs1/.style={xshift=3cm,yshift=2cm}}
\usetikzlibrary{shapes.geometric,arrows}
\tikzstyle{arrow}=
[thick,->,>=stealth]
\begin{document}
\begin{tikzpicture}[scale=0.2,node distance=2cm]
\node (A)
[rectangle,
rounded corners,
minimum width=3cm,
minimum height=1cm,
text centered,
draw=black,