Commit c82aaa95 authored by Mike Kirby's avatar Mike Kirby
Browse files

mike first load

parent 149eca45
@book{KaSh05,
title={Spectral/hp element methods for Computational Fluid Dynamics (Second Edition)},
author={George Em Karniadakis and Spencer J. Sherwin},
year={2005},
publisher={Oxford University Press}
}
@book{Schwab,
title={p-- and hp-- Finite Element Methods: Theory and Applications in Solid and Fluid Mechanics},
author={Ch. Schwab},
year={1999},
publisher={Oxford University Press}
}
@book{KFN-testing,
title = {Testing Computer Software},
author = {Cem Kaner and Jack Falk and Hung Quoc Nguyen},
year = {2010},
publisher={John Wiley \& Sons}
}
@book{CanutoHQZ87,
author="C. Canuto and M.Y. Hussaini and A. Quarteroni and T.A. Zang",
title="{Spectral Methods in Fluid Mechanics}",
publisher="{Springer-Verlag, New York}",
year="1987" }
@book{Funaro92,
author="D. Funaro",
title="{Polynomial Approximations of Differential Equations: Lecture Notes in Physics, Volume 8}",
publisher="{Springer-Verlag, New York}",
year="1992" }
@book{KarniadakisK03,
author = "George Em Karniadakis and Robert M. Kirby",
title = "Parallel Scientific Computing in C++ and MPI",
publisher = "Cambridge University Press",
address = "New-York, NY, USA",
year = 2003
}
@Book{Hughes87,
author = "T. J. R. Hughes",
title = "The Finite Element Method",
publisher = "Prentice-Hall, Inc.",
year = "1987",
address = "Englewood Cliffs, New Jersey"
}
@book{SzBa91,
author = "B.A. Szab\'{o} and I. Babu\v{s}ka",
title = "Finite Element Analysis",
publisher = "John Wiley \& Sons",
address = "New York",
year = 1991
}
@book{TrefethenB97,
author = "Lloyd N. Trefethen and David Bau, III",
title = "Numerical Linear Algebra",
publisher = "SIAM",
address = "Philadelphia, PA, USA",
year = 1997
}
@book{Demmel97,
author = "James W. Demmel",
title = "Applied Numerical Linear Algebra",
publisher = "SIAM",
address = "Philadelphia, PA, USA",
year = 1997
}
@article{Pa84,
title={A spectral element method for fluid dynamics: laminar flow in a channel expansion},
author={Patera, Anthony T},
journal={Journal of computational Physics},
volume={54},
number={3},
pages={468--488},
year={1984},
publisher={Elsevier}
}
@article{BaSzKa81,
title={The p-version of the finite element method},
author={Babuska, Ivo and Szabo, Barna A and Katz, I Norman},
journal={SIAM journal on numerical analysis},
volume={18},
number={3},
pages={515--545},
year={1981},
publisher={SIAM}
}
@article{BlSh04,
title={Formulation of a Galerkin spectral element--Fourier method for three-dimensional incompressible flows in cylindrical geometries},
author={Blackburn, Hugh M and Sherwin, SJ},
journal={Journal of Computational Physics},
volume={197},
number={2},
pages={759--778},
year={2004},
publisher={Elsevier}
}
@article{VeSoZi07,
title={Modular $hp$-{FEM} system {HERMES} and its application to {M}axwell’s equations},
author={Vejchodsk{\`y}, Tom{\'a}{\v{s}} and {\v{S}}ol{\'\i}n, Pavel and Z{\'\i}tka, Martin},
journal={Mathematics and Computers in Simulation},
volume={76},
number={1},
pages={223--228},
year={2007},
publisher={Elsevier}
}
@article{DeKlNoOh11,
title={A generic interface for parallel and adaptive discretization schemes: abstraction principles and the {DUNE-FEM} module},
author={Dedner, Andreas and Kl{\"o}fkorn, Robert and Nolte, Martin and Ohlberger, Mario},
journal={Computing},
volume={90},
number={3-4},
pages={165--196},
year={2010},
publisher={Springer}
}
@article{BaHaKa07,
title={deal.{II}--a general-purpose object-oriented finite element library},
author={Bangerth, Wolfgang and Hartmann, Ralf and Kanschat, Guido},
journal={ACM Transactions on Mathematical Software (TOMS)},
volume={33},
number={4},
pages={24},
year={2007},
publisher={ACM}
}
@book{HeWa07,
title={Nodal discontinuous Galerkin methods: algorithms, analysis, and applications},
author={Hesthaven, Jan S and Warburton, Tim},
volume={54},
year={2007},
publisher={Springer}
}
@inproceedings{MeDePeFaWi14,
title = {A Guide to the Implementation of Boundary Conditions in Compact High-Order Methods for Compressible Aerodynamics},
author = {Mengaldo, G. and De Grazia, D. and Peiro, J. and Farrington, A. and Witherden, F. and Vincent, P. E. and Sherwin, S. J.},
year = {2014},
booktitle = {7th AIAA Theoretical Fluid Mechanics Conference},
series = {AIAA Aviation},
publisher = {American Institute of Aeronautics and Astronautics},
}
@article{WiFaVi14,
title={{PyFR}: An open source framework for solving advection–diffusion type problems on streaming architectures using the flux reconstruction approach},
author={Witherden, FR and Farrington, AM and Vincent, PE},
journal={Computer Physics Communications},
year={2014},
volume={185},
issue={11},
pages={3028–3040},
doi={10.1016/j.cpc.2014.07.011}
}
%%% Software
@article{VosSK2010,
......@@ -127,3 +296,83 @@ publisher = "Springer Lecture Notes in Computational Science and Engineering, Vo
year = "2012"
}
@article{AinsworthAD11,
author = "Mark Ainsworth and Gaelle Andriamaro and Oleg Davydov",
title = "Bernstein-B{\'e}zier Finite Elements of Arbitrary Order and Optimal Assembly Procedures",
journal = "SIAM Journal of Scientific Computing",
volume = "33",
issue = "6",
pages = "3087-3109",
year = "2011"
}
@article{Ainsworth14,
author = "Mark Ainsworth",
title = "Pyramid Algorithms for Bernstein-B{\'e}zier Finite Elements of High, Nonuniform Order in Any Dimension",
journal = "SIAM Journal of Scientific Computing",
volume = "36",
issue = "2",
pages = "A543-A569",
year = "2014"
}
@article{WarburtonPH00,
author = "T. Warburton and L.F. Pavarino and J.S. Hesthaven",
title = "A Pseudo-spectral scheme for the incompressible {N}avier-{S}tokes equations using unstructured nodal elements",
journal = "J. Comp. Phys.",
volume = "164",
pages = "1-21",
year = "2000"
}
@article{Dubiner91,
author = "M. Dubiner",
title = "Spectral Methods on Triangles and Other Domains",
journal = "J. Sci. Comp.",
volume = "6",
pages = "345",
year = "1991"
}
@Article{Hesthaven98,
author = {Hesthaven, J.S. },
title = {From electrostatics to almost optimal nodal sets for
polynomial interpolation in a simplex},
journal = {SIAM J. Numer. Anal.},
year = {1998},
volume = {35},
number = {2},
pages = {655-676},
}
@Article{TaylorWV00,
author = {Taylor, M. and Wingate, B.A. and Vincent, R.E.},
title = {An Algorithm for computing {F}ekete points in the triangle},
journal = {SIAM J. Num. Anal.},
year = {2000},
volume = {38},
pages = {1707-1720},
}
@article{Duffy82,
author = "Duffy, M.G.",
title = "Quadrature over a pyramid or cube of integrands
with a singularity at a vertex",
journal ="SIAM J. Numer. Anal.",
volume = "19",
pages = "1260",
year = "1982"
}
@article{CantwellYKPS14,
author = "C.D. Cantwell and S. Yakovlev and R.M. Kirby and N.S. Peters and S.J. Sherwin",
title = "High-order continuous spectral/hp element discretisation for reaction-diffusion problems on a surface",
journal = "Journal of Computational Physics",
volume = "257",
issue = "A",
pages = "813-829",
year = "2014"
}
\input{shared/devguide-preamble.tex}
\DeclareOldFontCommand{\bf}{\normalfont\bfseries}{\mathbf}
\newcommand\nek{\emph{Nektar++}}
\newcommand\shp{spectral/$hp$}
\newcommand\Shp{Spectral/$hp$}
......@@ -31,11 +33,14 @@
%
%\clearpage
%\input{test.tex}
\input{preface/preface.tex}
%
\input{introduction/introduction.tex}
%
\input{prelims/prelims.tex}
%
\input{library/library-master.tex}
\bibliographystyle{plain}
......
% Introduction
\chapter{Introduction}
\section{Structure}
Finite element methods (FEM) are commonplace among a wide range of engineering
and biomedical disciplines for the solution of partial differential equations
(PDEs) on complex geometries. However, low-order formulations often struggle to
capture certain complex solution characteristics without the use of excessive
mesh refinement due to numerical dissipation. In contrast, spectral techniques
offer improved numerical characteristics, but are typically restricted to
relatively simple regular domains.
High-order finite element methods, such as the traditional spectral element
method \cite{Pa84}, the p-type method \cite{BaSzKa81} and the more recent \shp{}
element method \cite{KaSh05}, exhibit the convergence properties of spectral methods while retaining the geometric
flexibility of traditional linear FEM.
%and transient flow simulation,
%where the higher accuracy enables improved prediction of downstream dynamics.
% %
They potentially offer greater efficiency on modern CPU architectures
as well as more exotic platforms such as many-core general-purpose graphics
processing units (GPGPUs).
The data structures which arise from using high-order methods are more compact
and localised than their linear finite element counterparts, for a fixed number
of degrees of freedom, providing increased cache coherency and reduced memory
accesses, which is increasingly the primary bottleneck of modern computer systems.
The methods have had greatest
prominence in the structural mechanics community and subsequently the academic
fluid dynamics community. They are also showing promise
in other areas of engineering, biomedical and environmental research. The most
common concern cited with respect to using high-order finite element techniques
outside of academia is the implementational complexity, stemming from the
complex data structures, necessary to produce a computationally efficient
implementation. This is a considerable hurdle which has limited their widespread
uptake in many application domains and industries.
% Overview of Nektar++ and its goals/features
\nek{} is a cross-platform \shp{} element framework which aims to make
high-order finite element methods accessible to the broader community. This is
achieved by providing a structured hierarchy of C++ components, encapsulating
the complexities of these methods, which can be readily applied to a range of
application areas. These components are distributed in the form of
cross-platform software libraries, enabling rapid development of solvers for use
in a wide variety of computing environments. The code accommodates both
small research problems, suitable for desktop computers, and large-scale
industrial simulations, requiring modern HPC infrastructure, where
there is a need to maintain efficiency and scalability up to many thousands of
processor cores.
% % Previous software - Nektar (does not do anything more than IncNS)
A number of software packages already exist for fluid dynamics which implement
high-order finite element methods, although these packages are typically targeted at a specific
domain or provide limited high-order capabilities as an extension.
% %
The \emph{Nektar flow solver} is the predecessor to Nektar++ and
implements the \shp{} element method for solving the incompressible
and compressible Navier-Stokes equations in both 2D and 3D. While it is widely
used and the implementation is computationally efficient on small parallel problems,
achieving scaling on large HPC clusters is challenging. Semtex \cite{BlSh04}
implements the 2D spectral element method coupled with a Fourier expansion in
the third direction. The implementation is highly efficient, but can only be
parallelised through Fourier-mode decomposition.
Nek5000 \cite{Nek5000} is a 3D spectral element code, based on hexahedral
elements, which has been used for massively parallel simulations up to 300,000
cores. Hermes \cite{VeSoZi07} implements hp-FEM for two-dimensional problems and
has been used in a number of application areas. Limited high-order finite
element capabilities are also included in a number of general purpose PDE
frameworks including the DUNE project \cite{DeKlNoOh11} and deal.II
\cite{BaHaKa07}.
% %
A number of codes also implement high-order finite element methods on
GPGPUs including nudg++, which
implments a nodal discontinuous Galerkin scheme \cite{HeWa07}, and PyFR
\cite{WiFaVi14}, which supports a range of flux reconstruction techniques.
% % However, the present software is instead a collection of libraries which
% implement the underlying discretisation technique, providing the ability to
% solve a range of PDE problems across a broad range of application areas. The
% included incompressible Navier-Stokes solver supports all the existing
% functionality of the Nektar flow solver, including improvements in many areas.
% %
\nek{} provides a single codebase with the following key features:
\begin{itemize}
\item Arbitrary-order \shp{} element discretisations in one, two and three
dimensions;
\item Support for variable polynomial order in space and heterogeneous
polynomial order within two- and three-dimensional elements;
\item High-order representation of the geometry;
\item Continuous Galerkin, discontinuous Galerkin and hybridised discontinuous
Galerkin projections;
\item Support for a Fourier extension of the spectral element mesh;
\item Support for a range of linear solvers and preconditioners;
\item Multiple implementation strategies for achieving linear algebra
performance on a range of platforms;
\item Efficient parallel communication using MPI showing strong scaling up to
2048-cores on Archer, the UK national HPC system;
\item A range of time integration schemes implemented using generalised linear
methods; and
\item Cross-platform support for Linux, OS X and Windows operating
systems.
\end{itemize}
In addition to the core functionality listed above, Nektar++ includes a
number of solvers covering a range of application areas. A range
of pre-processing and post-processing utilities are also included with support
for popular mesh and visualization formats, and an extensive test suite ensures
the robustness of the core functionality.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{The {\em Ethos} of Nektar++}
As with any research effort, one is required to decide on a set of guiding principles that will
drive the investigation. Similarly with a software development effort of this form, we early on
spent a lot of time considering what things we wanted to be distictive about Nektar++ and also
what guiding principles would we use to help set both the goals and the boundaries of what
we wanted to do. We did this for at least two reasons: (1) We acknowledged then and now that
there are various software packages and open-source efforts that deal with finite element frameworks,
and so we wanted to be able to understand and express to people those things we thought were
distinctive to us -- that is, our ``selling points". (2) We also acknowledged, from our own experience
on software projects, that if we did not set up some collection of guiding principles for our work, that
we would gravitate towards trying to be ``all things to all men", and in doing so be at odds with the
first item. Below are a list of the guiding principles, the ``ethos", of the Nektar++ software development
effort. The first three boldface items denote the three major themes of our work (i.e. respecting reason (1) above) and the
subsequent items denotes the guardrails (i.e. respecting reason (2) above) that
we put in place to help guide our efforts.
\begin{itemize}
\item \textbf{Efficiently:} Nektar++ was to be a ``true" high-order code. ``True" is put in quotations because we acknowledge
that high-order means different things to different communities. Based upon a review of the literature, we
came to the conclusion that part of our {\em h-to-p} philosophy should be that we accommodate polynomial
degrees ranging from zero (finite volumes) or one (traditional linear finite elements) up to what is considered
``spectral" (pseodspectral) orders of 16 degree. As part of our early work \cite{vos}, we established that in
order to span this range of polynomial degrees and attempt to maintain some level of computational
efficiency, we would need to develop {\em order-aware} algorithms: that is, we would need to utilize
different (equivalent) algorithms appropriate for a particular order. This principle was the starting point
of our {\em h-to-p efficiently} branding and continues to be a driving principle of our work.
\item \textbf{Transparently:} Nektar++ was to be agnostic as to what the ``right" way to discretize a partial differential equation (PDE).
``Right" is put in quotations to acknowledge that like the issue of polynomial order, there appear to be different
``camps" who hold very strong views as to which discretization method should be used. Some might concede that
continuous Galerkin methods are very natural for elliptic and parabolic PDEs and then work very laboriously to
was to be a high-order finite element framework that allowed users to experiment with
continuous Galerkin (cG) and discontinuous Galerkin (dG) methods.
\item \textbf{Seamlessly:} Desktop to Supercomputer seamlessly
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{The Structure of Nektar++}
\noindent{\textbf{LibUtilities:}} This part of the library contains all the basic mathematical and computer science building blocks of the Nektar++ code.
\noindent{\textbf{StdRegions:}} This part of the library contains the objects that express ``standard region'' data and operations. In one dimension, this is the StdSegment. In two
dimensions, this is the StdTri (Triangle) and StdQuad (Quadrilateral). In three dimensions, this is the StdTet (Tetrahedra), StdHex (Hexahedra), StdPrism (Prism) and StdPyr (Pyramid). These represent
the seven different standarized regions over which we support differentiation and integration.
\noindent{\textbf{SpatialDomains:}}
\noindent{\textbf{LocalRegions:}}
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/structure1.png}
......@@ -9,6 +178,16 @@
\label{intro:fig1}
\end{figure}
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/stdtolocal.pdf}
\caption{Figure stdtolocal}
\label{intro:stdtolocal}
\end{figure}
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/structure2.png}
......@@ -17,7 +196,27 @@
\end{figure}
\section{Software Implementations and Frameworks}
\section{Assumed Proficiencies}
The developer guide is designed for the experienced \shp{}
spectral element \cite{DevilleFM02,KaSh05}
discontinuous Galerkin \cite{HesthavenW08}
CanutoHQZ87
Hughes87
SzBa91
TrefethenB97
Demmel97
\section{Other Software Implementations and Frameworks}
In the last ten years a collection of software frameworks has been put forward to try to bridge the gap between the
mathematics of high-order methods and their implementation. A major challenge many practitioners have with
......@@ -46,3 +245,7 @@ and discontinuous Galerkin
strategies for solving a particular problem of interest, but in a way on which others could adopt and build. The discontinuous Galerkin
of Hesthaven and Warburton \cite{HesthavenW08} and a software framework for the discontinuous Petrov-Galerkin method \cite{roberts_camellia:_2014}
provide a similar flexibility to the user-community trying to jump-start their high-order software experience.
%
\section{The Fundamental Algorithms within Collections}
\ No newline at end of file
%
\section{The Fundamental Data Structures within Collections}
\ No newline at end of file
%
\section{The Fundamentals Behind Collections}
\ No newline at end of file
%
\section{The Fundamental Algorithms within FieldUtils}
\ No newline at end of file
%
\section{The Fundamental Data Structures within FieldUtils}
\ No newline at end of file
%
\section{The Fundamentals Behind FieldUtils}
\ No newline at end of file
%
\section{The Fundamental Algorithms within GlobalMapping}
\ No newline at end of file
%
\section{The Fundamental Data Structures within GlobalMapping}
\ No newline at end of file
%
\section{The Fundamentals Behind GlobalMapping}
\ No newline at end of file
%
\section{BasicConst}
\lstinputlisting[language=C++, firstline=47, lastline=59]{../nektar/library/LibUtilities/BasicConst/NektarUnivConsts.hpp}
\ No newline at end of file
%
\section{Foundations}
\ No newline at end of file
\section{Foundations}
The two basic building blocks of all that is done in Nektar++ are the concepts of Points and of a Basis. The Point objects denote positions
in space, either on compact domains (normally $[-1,1]^d$ where $d$ is the dimension in a reference domain mapped to world-space)
or periodic domains (i.e. in the case of points used in Fourier expansions). The Basis objects denote functions (e.g. polynomials) evaluated
at a given set of points.
\subsection{Points}
\begin{itemize}
\item PointsKey
\item Points
\end{itemize}
\subsection{Basis}
\begin{itemize}
\item BasisKey
\item Basis
\end{itemize}
\begin{figure}[htb]
\centering
\includegraphics[width=4in]{img/basismemory.pdf}
\caption{Figure 1}
\label{foundations:basismemory}
\end{figure}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment