CMakeLists.txt

+SET(DEVGUIDESRC ${CMAKE_CURRENT_SOURCE_DIR})
+SET(DEVGUIDE ${CMAKE_BINARY_DIR}/docs/developer-guide)
+
+FILE(MAKE_DIRECTORY ${DEVGUIDE}/html)
+
+FIND_PROGRAM(HTLATEX htlatex)
+MARK_AS_ADVANCED(HTLATEX)
+ADD_CUSTOM_TARGET(developer-guide-html
+    export TEXINPUTS=${CMAKE_SOURCE_DIR}//:${DEVGUIDESRC}//: &&
+    ${HTLATEX} ${DEVGUIDESRC}/developers-guide.tex 
+    "${DEVGUIDESRC}/styling.cfg,html,3,next,NoFonts"
+    WORKING_DIRECTORY ${DEVGUIDE}/html
+)
+
+# If tex4ht successful, create img dir and copy images across
+FILE(GLOB_RECURSE imgfiles "img/*.png" "img/*.jpg" "*/img/*.png" "*/img/*.jpg")
+ADD_CUSTOM_COMMAND(TARGET developer-guide-html
+    POST_BUILD COMMAND ${CMAKE_COMMAND} -E make_directory ${DEVGUIDE}/html/img)
+FOREACH(img ${imgfiles})
+    ADD_CUSTOM_COMMAND(TARGET developer-guide-html
+        POST_BUILD COMMAND 
+            ${CMAKE_COMMAND} -E copy ${img} ${DEVGUIDE}/html/img)
+ENDFOREACH()
+
+FILE(GLOB_RECURSE pdffiles "*/img/*.pdf")
+FIND_PROGRAM(CONVERT convert)
+FOREACH(pdf ${pdffiles})
+    GET_FILENAME_COMPONENT(BASENAME ${pdf} NAME_WE)
+    ADD_CUSTOM_COMMAND(TARGET developer-guide-html
+        POST_BUILD COMMAND
+        ${CONVERT} ${pdf} ${DEVGUIDE}/html/img/${BASENAME}.png)
+ENDFOREACH()
+
+
+FIND_PROGRAM(PDFLATEX pdflatex)
+MARK_AS_ADVANCED(PDFLATEX)
+FIND_PROGRAM(BIBTEX bibtex)
+MARK_AS_ADVANCED(BIBTEX)
+FIND_PROGRAM(MAKEINDEX makeindex)
+MARK_AS_ADVANCED(MAKEINDEX)
+
+ADD_CUSTOM_TARGET(developer-guide-pdf
+    export TEXINPUTS=${CMAKE_SOURCE_DIR}//: && 
+    ${PDFLATEX} --output-directory ${DEVGUIDE} ${DEVGUIDESRC}/developers-guide.tex
+    COMMAND TEXMFOUTPUT=${DEVGUIDE} ${BIBTEX} ${DEVGUIDE}/developers-guide.aux
+    COMMAND TEXMFOUTPUT=${DEVGUIDE} ${MAKEINDEX} ${DEVGUIDE}/developers-guide.idx
+    COMMAND TEXINPUTS=${CMAKE_SOURCE_DIR}//:  
+    ${PDFLATEX} --output-directory ${DEVGUIDE} ${DEVGUIDESRC}/developers-guide.tex
+    COMMAND TEXINPUTS=${CMAKE_SOURCE_DIR}//:  
+    ${PDFLATEX} --output-directory ${DEVGUIDE} ${DEVGUIDESRC}/developers-guide.tex
+    WORKING_DIRECTORY ${DEVGUIDESRC}
+)

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,
+author = "Peter E. J. Vos and Spencer J. Sherwin and Robert M. Kirby",
+title = "h-to-p Efficiently: Implementing Finite and Spectral/hp Element Methods to Achieve Optimal Performance for Low- and High-Order Discretisations",
+journal = "Journal of Computational Physics",
+volume = "229", 
+issue = "13",
+pages = "5161-5181",
+year = "2010"
+}
+ 
+@article{CantwellSKK2011a,
+author = "C.D. Cantwell and S.J. Sherwin and R.M. Kirby and P.H.J. Kelly",
+title = "From h-to-p Efficiently: Strategy Selection for Operator Evaluation on Hexahedral and Tetrahedral Elements",
+journal = "Computers and Fluids",
+volume = "43", 
+issue = "1",
+pages = "23-28",
+year = "2011"
+}
+
+
+@article{CantwellSKK2011b,
+author = "C.D. Cantwell and S.J. Sherwin and R.M. Kirby and P.H. Kelly",
+title = "From h-to-p Efficiently: Selecting the Optimal Spectral/hp Discretisation in Three Dimensions",
+journal = "Math. Model. Nat. Phenom.",
+volume = "6", 
+number = "3",
+pages = "84-96",
+year = "2011"
+}
+
+@article{BolisCKS2014,
+author = "A. Bolis and C.D. Cantwell and R.M. Kirby and S.J. Sherwin",
+title = "h-to-p efficiently: Optimal implementation strategies for explicit time-dependent problems using the spectral/hp element method",
+journal = "International Journal for Numerical Methods in Fluids",
+volume = "75", 
+issue = "8",
+pages = "591-607",
+year = "2014"
+}
+
+@article{CantwellMCBRMGYLEJXMENVBKS2015,
+author = "C.D. Cantwell and D. Moxey and A. Comerford and A. Bolis and G. Rocco and G. Mengaldo and D. de Grazia and S. Yakovlev and J-E Lombard and D. Ekelschot and B. Jordi and H. Xu and Y. Mohamied and C. Eskilsson and B. Nelson and P. Vos and C. Biotto and R.M. Kirby and S.J. Sherwin",
+title = "Nektar++: An open-source spectral/hp element framework",
+journal = "Computer Physics Communications",
+volume = "192",
+pages = "205-219",
+year = "2015"
+}
+
+@article{roberts_camellia:_2014,
+	title = {Camellia: {A} software framework for discontinuous {Petrov-Galerkin} methods},
+	volume = {68},
+	shorttitle = {Camellia},
+	abstract = {The discontinuous Petrov-Galerkin (DPG) methodology of Demkowicz and Gopalakrishnan minimizes the solution residual in a user-determinable energy norm and offers a built-in mechanism for evaluating error in the energy norm, among other desirable features. However, the methodology also brings with it some additional complexity for researchers who wish to experiment with DPG in their computations. In this paper, we introduce Camellia, a software framework whose central design goal is to enable developers to create efficient hp-adaptive DPG solvers with minimal effort.},
+	number = {11},
+	journal = {Computers \& Mathematics with Applications},
+	author = {Roberts, Nathan V.},
+	year = {2014},
+	pages = {1581--1604}
+}
+
+@article{nelson_elvis:_2012,
+	title = {Elvis: {A} system for the accurate and interactive visualization of high-order finite element solutions},
+	volume = {18},
+	shorttitle = {Elvis},
+	abstract = {This paper presents the Element Visualizer (ElVis), a new, open-source scientific visualization system for use with high-order finite element solutions to PDEs in three dimensions. This system is designed to minimize visualization errors of these types of fields by querying the underlying finite element basis functions (e.g., high-order polynomials) directly, leading to pixel-exact representations of solutions and geometry. The system interacts with simulation data through runtime plugins, which only require users to implement a handful of operations fundamental to finite element solvers. The data in turn can be visualized through the use of cut surfaces, contours, isosurfaces, and volume rendering. These visualization algorithms are implemented using NVIDIA's OptiX GPU-based ray-tracing engine, which provides accelerated ray traversal of the high-order geometry, and CUDA, which allows for effective parallel evaluation of the visualization algorithms. The direct interface between ElVis and the underlying data differentiates it from existing visualization tools. Current tools assume the underlying data is composed of linear primitives; high-order data must be interpolated with linear functions as a result. In this work, examples drawn from aerodynamic simulations-high-order discontinuous Galerkin finite element solutions of aerodynamic flows in particular-will demonstrate the superiority of ElVis' pixel-exact approach when compared with traditional linear-interpolation methods. Such methods can introduce a number of inaccuracies in the resulting visualization, making it unclear if visual artifacts are genuine to the solution data or if these artifacts are the result of interpolation errors. Linear methods additionally cannot properly visualize curved geometries (elements or boundaries) which can greatly inhibit developers' debugging efforts. As we will show, pixel-exact visualization exhibits none of these issues, removing the visualization scheme as a source of - ncertainty for engineers using ElVis.},
+	number = {12},
+	journal = {Visualization and Computer Graphics, IEEE Transactions on},
+	author = {Nelson, Blake and Liu, Eric and Kirby, Robert M. and Haimes, Robert},
+	year = {2012},
+	pages = {2325--2334}
+}
+
+@article{geuzaine_gmsh:_2009,
+	title = {Gmsh: {A} 3-{D} finite element mesh generator with built-in pre-and post-processing facilities},
+	volume = {79},
+	shorttitle = {Gmsh},
+	abstract = {Gmsh is an open-source 3-D finite element grid generator with a build-in CAD 
+engine and post-processor. Its design goal is to provide a fast, light and user-friendly 
+meshing tool with parametric input and advanced visualization capabilities. This paper presents the overall philosophy, the main design choices and some of the original algorithms implemented in Gmsh. Copyright© 2009 John Wiley \& Sons, Ltd.},
+	number = {11},
+	journal = {International Journal for Numerical Methods in Engineering},
+	author = {Geuzaine, Christophe and Remacle, Jean-François},
+	year = {2009},
+	pages = {1309--1331},
+	file = {[PDF] from geuz.org:/Users/aashok/Library/Application Support/Zotero/Profiles/7xumqoyz.default/zotero/storage/IASXUV6Z/Geuzaine and Remacle - 2009 - Gmsh A 3-D finite element mesh generator with bui.pdf:application/pdf}
+}
+
+
+@book{Nek5000,
+title = "Nek5000 User Manual",
+author = "Paul Fischer and James Lottes and Stefan Kerkemeier and Oana Marin and Katherine Heisey and Aleks Obabko and Elia Merzari and Yulia Peet",
+publisher = "ANL/MCS-TM-351",
+year = "2014"
+}
+
+@book{DevilleFM02,
+title = "High-Order Methods for Incompressible Fluid Flow",
+author = "M.O. Deville and P.F. Fisher and E.H. Mund",
+publisher = "Cambridge University Press",
+year = "2002"
+}
+
+@book{HesthavenW08,
+author = "J.S. Hesthaven and T.C. Warburton",
+title = "Nodal Discontinuous {G}alerkin Methods: Algorithms, Analysis, and Applications",
+publisher = "Springer Texts in Applied Mathematics 54. Springer Verlag: New York", 
+year = "2008"
+}
+
+@article{GiraldoKC13,
+author = "F.X. Giraldo and J.F. Kelly and E.M. Constantinescu",
+title = "Implicit explicit formulations of a three dimensional non-hydrostatic unified model of the atmosphere {(NUMA)}",
+journal = "SIAM Journal of Scientific Computing",
+volume = "35",
+pages = "1162-1194",
+year = "2013"
+}
+
+@book{FEniCS,
+title = "Automated Solution of Differential Equations by the Finite Element Method",
+author = "Anders Logg and Kent-Andre Mardal and Garth Wells (editors)",
+publisher = "Springer Lecture Notes in Computational Science and Engineering, Volume 84",
+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$}
+
+\title{A Programmer's Guide to Nektar++}
+
+\begin{document}
+
+%\frontmatter
+
+% Render pretty title page if not building HTML
+\ifdefined\HCode
+\begin{center}
+    \includegraphics[width=0.1\textwidth]{shared/img/icon-blue.png}
+\end{center}
+\maketitle
+\begin{center}
+       \huge{Nektar++ Developer's Guide}
+\end{center}
+\else
+\titlepage
+\fi
+
+\clearpage
+
+%\ifx\HCode\undefined
+%\tableofcontents*
+%\fi
+%
+%\clearpage
+
+%\input{test.tex}
+
+\input{preface/preface.tex}
+%
+\input{introduction/introduction.tex}
+%
+%\input{prelims/prelims.tex}
+%
+\input{library/library-master.tex}
+
+\bibliographystyle{plain}
+\bibliography{developers-guide} 
+
+
+\end{document}

img/afg002.pdf

+../library/StdRegions/img/afg002.pdf
\ No newline at end of file

img/basismemory.pdf

+../library/LibUtilities/img/basismemory.pdf
\ No newline at end of file

img/expansiontree.pdf

+../library/LocalRegions/img/expansiontree.pdf
\ No newline at end of file

img/geomtree.pdf

+../library/SpatialDomains/img/geomtree.pdf
\ No newline at end of file

img/multiregiontree.pdf

+../library/MultiRegions/img/multiregiontree.pdf
\ No newline at end of file

img/stdexpansiontree.pdf

+../library/StdRegions/img/stdexpansiontree.pdf
\ No newline at end of file

img/stdtolocal.pdf

+../introduction/img/stdtolocal.pdf
\ No newline at end of file

img/structure1.png

+../introduction/img/structure1.png
\ No newline at end of file

img/structure2.png

+../introduction/img/structure2.png
\ No newline at end of file

introduction/introduction.tex

+% Introduction
+\chapter{Introduction}
+
+
+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:}  Nektar++ was to be ... 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}
+\caption{Figure 1}
+\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}
+\caption{Figure 2}
+\label{intro:fig2}
+\end{figure}
+
+
+\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
+spectral/{\em hp\/} elements and high-order methods, in general, is the complexity (in terms of algorithmic design) they
+encounter. In this section, we give an incomplete but
+representative summary of several of these attempts to overcome this challenge.
+
+FEniCS \cite{FEniCS} is a collaborative project for the development of scientific computing tools, with a particular focus 
+on the automated solution of differential equations by finite element methods (FEM).  Through the use of concepts such as meta-programming,
+FEniCS tries to keep the solving of PDEs with FEM, from the application programmers' perspective, as close to the mathematical expressions
+as possible without sacrificing computational efficiency.
+
+The current effort, Nektar++ \cite{CantwellMCBRMGYLEJXMENVBKS2015}, is an open-source software framework designed to support the development of 
+high-performance scalable solvers for partial differential equations using the spectral/{\em hp\/} element method.   Nektar++ is an outgrowth of the original {\nektar} effort; its design and principal implementation
+being by two former {\nektar} developers.  The two software suites are similar in terms of the basis choices available, etc.  However, what makes Nektar++ unique is that it is  
+an initiative to overcome this limitation by encapsulating the mathematical complexities of the underlying method within an efficient C++ framework, making the techniques more accessible to the broader scientific and industrial communities. The software supports a variety of discretization techniques and 
+implementation strategies \cite{VosSK2010,CantwellSKK2011a,CantwellSKK2011b,BolisCKS2014},
+supporting methods research as well as application-focused computation, and the multi-layered structure of the framework allows the user to embrace as much or as little of the complexity as they need. The libraries capture the mathematical constructs of spectral/{\em hp\/} element methods, while the associated collection of pre-written PDE solvers provides out-of-the-box application-level functionality and a template for users who wish to develop solutions for addressing questions in their own scientific domains.
+
+With respect to software infrastructures that tackle specific domain problems, 
+the nodal hexahedral spectral element code Nek5000 \cite{Nek5000,DevilleFM02}, 
+which is an outgrowth of the original code NEKTON, provides the application
+developer with a framework for solving the incompressible Navier-Stokes equations and its extensions in a scalable parallel way.
+Similarly the Non-hydrostatic Unified Model of the Atmosphere (NUMA) \cite{GiraldoKC13} is a spectral element framework that employs continuous 
+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]{../../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}
+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}
+

library/LibUtilities/kernel.tex

+%
+\section{Kernel}
+

library/LibUtilities/linearalgebra.tex

+%
+\section{Linear Algebra}
\ No newline at end of file

library/LibUtilities/memory.tex

+%
+\section{Memory}

library/LibUtilities/polylib.tex

+%
+\section{Polylib}

library/LibUtilities/timeintegration.tex

+%
+\section{Time Integration}

library/LocalRegions/localreg-algorithms.tex

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

library/LocalRegions/localreg-datastructures.tex

+%
+\section{The Fundamental Data Structures within LocalRegions}
+
+
+\begin{figure}[htb]
+\centering
+\includegraphics[width=6in]{img/expansiontree.pdf}
+\caption{Figure local regions tree}
+\label{localregions:localclasstree}
+\end{figure}
\ No newline at end of file

library/LocalRegions/localreg-fundamentals.tex

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

library/MultiRegions/multireg-algorithms.tex

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

library/MultiRegions/multireg-datastructures.tex

+%
+\section{The Fundamental Data Structures within MultiRegions}
+
+
+\begin{figure}[htb]
+\centering
+\includegraphics[width=6in]{img/multiregiontree.pdf}
+\caption{Figure 1}
+\label{multiregions:multiregionstree}
+\end{figure}

library/MultiRegions/multireg-fundamentals.tex

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

library/SolverUtils/solverutils-algorithms.tex

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

library/SolverUtils/solverutils-datastructures.tex

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

library/SolverUtils/solverutils-fundamentals.tex

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

library/SpatialDomains/spdomains-algorithms.tex

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

library/SpatialDomains/spdomains-datastructures.tex

+%
+\section{The Fundamental Data Structures within SpatialDomains}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Reference to World-Space Mapping}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{Geometry}
+
+\begin{figure}[htb]
+\centering
+\includegraphics[width=6in]{img/geomtree.pdf}
+\caption{Figure geometry tree}
+\label{spatialdomains:geomtree}
+\end{figure}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{GeomFactors}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{MeshGraph}
\ No newline at end of file

library/SpatialDomains/spdomains-fundamentals.tex

+%
+\section{The Fundamentals Behind SpatialDomains}
+
+
+
+\subsection{Regular}
+$$
+\vec{x} = (x_j)^T,\, j=1,\ldots,D
+$$
+
+$$
+\vec{\xi} = (\xi_j)^T,\, j=1,\ldots,D
+$$
+
+$$
+\vec{x} = \chi(\vec{xi}) 
+$$
+
+$$
+{\bf J} = \frac{\partial x_i}{\partial \xi_j}
+$$
+
+$$
+{\bf g} = {\bf J}^T{\bf J}
+$$
+
+$$
+g = \det{\bf g}
+$$
+
+
+gmat and jac
+
+note that gmat is a tensor defined at each point, and jac is the determinant of the jacobian.
+
+
+\cite{CantwellYKPS14}
+
+
+\subsection{Deformed}
+
+
+

library/StdRegions/stdreg-algorithms.tex

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

library/StdRegions/stdreg-datastructures.tex

+%
+\section{The Fundamental Data Structures within StdRegions}
+
+\begin{figure}[htb]
+\centering
+\includegraphics[width=6in]{img/stdexpansiontree.pdf}
+\caption{Figure 1}
+\label{stdregions:stdexpansiontree}
+\end{figure}

library/StdRegions/stdreg-fundamentals.tex

+%
+\section{The Fundamentals Behind StdRegions}
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Reference Element Transformations That Facilitate Separability}
+
+
+
+\begin{figure}[htb]
+\centering
+\includegraphics[width=4in]{img/afg002.pdf}
+\caption{Duffy mapping between a right-sided triangle and a square domain.}
+\label{stdregions:duffy}
+\end{figure}
+
+Duffy \cite{Duffy82}
+
+Dubiner \cite{Dubiner91}
+
+Ainsworth \cite{AinsworthAD11,Ainsworth14}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Reference Elements On Primative Geometric Types}
+
+Hesthaven \cite{Hesthaven98}
+
+Taylor \cite{TaylorWV00}

library/library-master.tex

+% Library Master File
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: LibUtilities}
+
+In this chapter, we walk the reader through the different components of the LibUtilities Directory.
+We have ordered them in alphabetical order by directory name, not by level of importance or
+relevance to the code.  Since all of these items are considered foundational to Nektar++, they
+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}
+%
+\input{library/LibUtilities/basicutils.tex}
+%
+\input{library/LibUtilities/communication.tex}
+%
+\input{library/LibUtilities/fft.tex}
+%
+\input{library/LibUtilities/foundations.tex}
+%
+\input{library/LibUtilities/interpreter.tex}
+%
+\input{library/LibUtilities/kernel.tex}
+%
+\input{library/LibUtilities/linearalgebra.tex}
+%
+\input{library/LibUtilities/memory.tex}
+%
+\input{library/LibUtilities/polylib.tex}
+%
+\input{library/LibUtilities/timeintegration.tex}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: StdRegions}
+
+In this chapter, we walk the reader through the different components of the StdRegions 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
+the reader with an overview of the primary data structures introduced within the
+StdRegions Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+\input{library/StdRegions/stdreg-fundamentals.tex}
+%
+\input{library/StdRegions/stdreg-datastructures.tex}
+%
+\input{library/StdRegions/stdreg-algorithms.tex}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: SpatialDomains}
+
+In this chapter, we walk the reader through the different components of the SpatialDomains 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
+the reader with an overview of the primary data structures introduced within the
+SpatialDomains Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+
+The SpatialDomains Directory and its corresponding class definitions serve two principal purposes:
+\begin{enumerate}
+\item To hold the elemental geometric information (i.e. vertex information, curve information and reference-to-world mapping information); and
+\item To facility reading in and writing out geometry-related information.
+\end{enumerate}
+
+When designing Nektar++, developing a class hierarchy for StdRegions (those fundamental domains over which we define
+integration and differentiation) and LocalRegions (i.e. elements in world-space) was fairly straightforward following \cite{KaSh05}.
+For instance, a triangle in world-space {\em is-a} standard triangle.  The first question that arose was where to store geometric 
+information, as information within the LocalRegions element or as information encapsulated from the element so that multiple Expansions could
+all point to the same geometric information.  The decision we made was to store geometric information -- that is, the vertex information
+in world-space that defines an element and the edge and face curvature information -- in its own data structure that could be shared by
+multiple Expansions (functions) over the same domain (element) in world-space.  Hence SpatialDomains started as the directory
+containing Geometry and GeomFactors class definitions to meet the first item listed above.   A LocalRegion {\em is-a} StdRegion and {\em has-a}
+SpatialDomain (i.e. Geometry and GeomFactors).
+
+We then realized that in order to jump-start the process of constructing elements and combining them together into MultiRegions (collections of 
+elements that represent a (sub)-domain of interest), we needed devise a light-weight data structure into which we could load geometric information
+from our geometry file and from which we could then construct Expansions (with their mappings, etc.).  The light-weight data structure we
+devised was MeshGraph, and it was meant to meet the second item listed above.
+
+
+\input{library/SpatialDomains/spdomains-fundamentals.tex}
+%
+\input{library/SpatialDomains/spdomains-datastructures.tex}
+%
+\input{library/SpatialDomains/spdomains-algorithms.tex}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: LocalRegions}
+
+In this chapter, we walk the reader through the different components of the LocalRegions 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
+the reader with an overview of the primary data structures introduced within the
+LocalRegions Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+\input{library/LocalRegions/localreg-fundamentals.tex}
+%
+\input{library/LocalRegions/localreg-datastructures.tex}
+%
+\input{library/LocalRegions/localreg-algorithms.tex}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: MultiRegions}
+
+In this chapter, we walk the reader through the different components of the MultiRegions 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
+the reader with an overview of the primary data structures introduced within the
+MultiRegions Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+\input{library/MultiRegions/multireg-fundamentals.tex}
+%
+\input{library/MultiRegions/multireg-datastructures.tex}
+%
+\input{library/MultiRegions/multireg-algorithms.tex}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: Collections}
+
+In this chapter, we walk the reader through the different components of the Collections 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
+the reader with an overview of the primary data structures introduced within the
+Collections Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+\input{library/Collections/collections-fundamentals.tex}
+%
+\input{library/Collections/collections-datastructures.tex}
+%
+\input{library/Collections/collections-algorithms.tex}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: 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
+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.  
+
+\input{library/GlobalMapping/globalmapping-fundamentals.tex}
+%
+\input{library/GlobalMapping/globalmapping-datastructures.tex}
+%
+\input{library/GlobalMapping/globalmapping-algorithms.tex}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: FieldUtils}
+
+In this chapter, we walk the reader through the different components of the FieldUtils 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
+the reader with an overview of the primary data structures introduced within the
+FieldUtils Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+\input{library/FieldUtils/fieldutils-fundamentals.tex}
+%
+\input{library/FieldUtils/fieldutils-datastructures.tex}
+%
+\input{library/FieldUtils/fieldutils-algorithms.tex}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Inside the Library: SolverUtils}
+
+In this chapter, we walk the reader through the different components of the SolverUtils 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
+the reader with an overview of the primary data structures introduced within the
+SolverUtils Directory (often done through C++ objects), and then present the major 
+algorithms -- expressed as either object methods or functions -- employed over these data structures.  
+
+\input{library/SolverUtils/solverutils-fundamentals.tex}
+%
+\input{library/SolverUtils/solverutils-datastructures.tex}
+%
+\input{library/SolverUtils/solverutils-algorithms.tex}
+
+

preface/preface.tex

+% Preface
+\chapter{Preface}
+ 
+Like with any software project, people want to know it origins:  what motivated it, what and who drove it, and what
+constrained it.  \nek{} officially started as a project idea in 2004 in Salt Lake City, UT, USA and we registered
+the first commit to SVN in 2006.  The basic backstory is as follows:  Mike Kirby (University of Utah) and Spencer
+Sherwin (Imperial College London) had both studied under George Karniadakis.  Though Mike and Spencer did
+not overlap in terms of their studies (Spencer was a Princeton graduate while Mike was a Brown graduate), they
+both worked on \emph{Nektar}, a \shp{} element code supervised by George.  George's research group has
+had a long history of involvement in various software projects, e.g. PRISM (which has continued its existence
+under Hugh Blackburn) and \emph{Nektar}.  Spencer and George initiated the \emph{Nektar} code with triangular (2D) and
+tetrahedral (3D) \shp{} elements in the early 1990s, and the code grew and evolved with additions
+by Igor Lomtev, Tim Warburton, Mike Kirby, etc., all under the PhD advisor direction of George.  Spencer
+graduated from Princeton under George's supervision in 1995 and went on to Imperial College London 
+as a faculty member; Mike graduated from Brown under George's supervision in 2002 and went on to the
+University of Utah in 2002.  In 2004, Mike and Spencer teamed up to re-write \emph{Nektar} in light of modern
+C++ programming practices and in light of what had been learned in the decade or so since its foundation.
+
+What were the observations that motivated \nek{}?  The first observation was that \emph{Nektar}'s origin
+was triangular and tetrahedral \shp{} elements as applied to incompressible fluid mechanics 
+problems (i.e. the incompressible Navier-Stokes equations).  These ideas were extended to 
+the compressible Navier-Stokes by Lomtev and the two parallel paths joined and extended into
+what is often called Hybrid \emph{Nektar} by Tim Warburton. Hybrid \emph{Nektar} (referred to as \emph{Nektar} from
+here on out) used the C++ programming paradigm to facilitate hybrid elements:  triangles and
+quadrilaterals in 2D and tetrahedra, hexahedra, prisms and pyramids in 3D.   In addition, Warburton
+structured the code in a way to allow extensions to the Arbitrary Lagrangian Eulerian (ALE) formulation
+within \emph{Nektar}, as well as various other features such as the \emph{Nektar} Magneto-Hydrodynamics (MHD) solver.
+Mike was mentored (as a student) by Warburton and continued to expansion of \emph{Nektar} (e.g. compressible
+ALE solver, fluid-structure interaction capabilities, etc.).  The upside of this expansion was that \emph{Nektar} could
+be used for solver more and more engineering problems; the downside was that continually expanding and extending
+\emph{Nektar} without re-evaluating its fundamental design meant that some components became quite 
+cumbersome from the programming perspective.  
+
+The second observation was occurred was that \shp{} elements as used within the incompressible
+fluid mechanics world could be viewed as a special case of the broader set of high-order finite element methods
+as applied to various fluid and solid mechanics systems.  In fact, in a much wider context, these methods
+represent ways of discretizing various partial differential equations (PDEs) using their weak (variational) form.
+During the 1990s, it became more and more apparent that there was a broader context and a broader
+community for discussing and disseminating the ideas surrounding high-order finite elements, and 
+correspondingly a fruitful environment for cross-pollination of ideas and programming practices.
+
+With all this in mind, Mike and Spencer set out to re-architect \emph{Nektar} from the ground up, and in homage
+to its C++ core, this new software suite was called \shp{}.  \shp{} 
+is an open-source software framework designed to support the development
+of high-performance scalable solvers for partial differential equations using
+the \shp{} element method. High-order methods are gaining prominence in
+several engineering and biomedical applications due to their improved accuracy
+over low-order techniques at reduced computational cost for a given number of degrees of freedom. However,
+their proliferation is often limited by their complexity, which makes
+these methods challenging to implement and use. \nek{} is an initiative to
+overcome this limitation by encapsulating the mathematical complexities of the underlying method within an
+efficient C++ framework, making the techniques more accessible to the broader 
+scientific and industrial communities.
+% %
+The software supports a variety of discretization techniques and implementation
+strategies, supporting methods research as well as application-focused
+computation, and the multi-layered structure of the framework allows the user to
+embrace as much or as little of the complexity as they need. The
+libraries capture the mathematical constructs of \shp{} element methods,
+while the associated collection of pre-written PDE solvers provides
+out-of-the-box application-level functionality and a template for users who wish to develop
+solutions for addressing questions in their own scientific domains.
+
+
+  
\ No newline at end of file

shared/devguide-preamble.tex

+%%% DOCUMENTCLASS 
+%%%-------------------------------------------------------------------------------
+
+\documentclass[
+a4paper, % Stock and paper size.
+11pt, % Type size.
+