mike first load

developers-guide.bib

+@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"
+ }
+
+
+

developers-guide.tex

 \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/introduction.tex

 % 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.
+
+
+
+

library/Collections/collections-algorithms.tex

+%
+\section{The Fundamental Algorithms within Collections}
\ No newline at end of file

library/Collections/collections-datastructures.tex

+%
+\section{The Fundamental Data Structures within Collections}
\ No newline at end of file

library/Collections/collections-fundamentals.tex

+%
+\section{The Fundamentals Behind Collections}
\ No newline at end of file

library/FieldUtils/fieldutils-algorithms.tex

+%
+\section{The Fundamental Algorithms within FieldUtils}
\ No newline at end of file

library/FieldUtils/fieldutils-datastructures.tex

+%
+\section{The Fundamental Data Structures within FieldUtils}
\ No newline at end of file

library/FieldUtils/fieldutils-fundamentals.tex

+%
+\section{The Fundamentals Behind FieldUtils}
\ No newline at end of file

library/GlobalMapping/globalmapping-algorithms.tex

+%
+\section{The Fundamental Algorithms within GlobalMapping}
\ No newline at end of file

library/GlobalMapping/globalmapping-datastructures.tex

+%
+\section{The Fundamental Data Structures within GlobalMapping}
\ No newline at end of file

library/GlobalMapping/globalmapping-fundamentals.tex

+%
+\section{The Fundamentals Behind GlobalMapping}
\ No newline at end of file

library/LibUtilities/basicconst.tex

+%
+\section{BasicConst}
+
+\lstinputlisting[language=C++, firstline=47, lastline=59]{../nektar/library/LibUtilities/BasicConst/NektarUnivConsts.hpp}
\ No newline at end of file

library/LibUtilities/basicutils.tex

+%
+\section{BasicUtils}
+

library/LibUtilities/communication.tex

+%
+\section{Communication}
+

library/LibUtilities/fft.tex

+%
+\section{FFT}
+

library/LibUtilities/foundations.tex

 %
-\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}

library/LibUtilities/interpreter.tex

+%
+\section{Interpreter}
+