...
 
Commits (27)
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}
)
@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"
}
\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}
../library/StdRegions/img/afg002.pdf
\ No newline at end of file
../library/LibUtilities/img/basismemory.pdf
\ No newline at end of file
../library/LocalRegions/img/expansiontree.pdf
\ No newline at end of file
../library/SpatialDomains/img/geomtree.pdf
\ No newline at end of file
../library/MultiRegions/img/multiregiontree.pdf
\ No newline at end of file
../library/StdRegions/img/stdexpansiontree.pdf
\ No newline at end of file
../introduction/img/stdtolocal.pdf
\ No newline at end of file
../introduction/img/structure1.png
\ No newline at end of file
../introduction/img/structure2.png
\ No newline at end of file
% 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.
%
\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]{../../library/LibUtilities/BasicConst/NektarUnivConsts.hpp}
\ 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}
%
\section{Linear Algebra}
\ No newline at end of file
%
\section{Time Integration}
%
\section{The Fundamental Algorithms within LocalRegions}
\ No newline at end of file
%
\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
%
\section{The Fundamentals Behind LocalRegions}
\ No newline at end of file
%
\section{The Fundamental Algorithms within MultiRegions}
\ No newline at end of file
%
\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}
%
\section{The Fundamentals Behind MultiRegions}
\ No newline at end of file
%
\section{The Fundamental Algorithms within SolverUtils}
\ No newline at end of file
%
\section{The Fundamental Data Structures within SolverUtils}
\ No newline at end of file
%
\section{The Fundamentals Behind SolverUtils}
\ No newline at end of file
%
\section{The Fundamental Algorithms within SpatialDomains}
\ No newline at end of file
%
\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
%
\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}
%
\section{The Fundamental Algorithms within StdRegions}
\ No newline at end of file
%
\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}
%
\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 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
\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
This diff is collapsed.
%%% DOCUMENTCLASS
%%%-------------------------------------------------------------------------------
\documentclass[
a4paper, % Stock and paper size.
11pt, % Type size.