Initial commit of slides.

diff --git a/Makefile b/Makefile
new file mode 100644 (file)
index 0000000..c73bd27
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,52 @@
+IMAGE_FILES=$(wildcard images/*)
+
+SVG_FOLDER=images-svg
+SVG_SOURCES=$(wildcard $(SVG_FOLDER)/*.svg)
+SVG_OUTPUTS=${patsubst %.svg,%.pdf,$(SVG_SOURCES)}
+
+CODE_FOLDER=code
+CODE_F90_TEX_FILES=${patsubst %.F90,%.tex,$(wildcard $(CODE_FOLDER)/*.F90)}
+CODE_TEX_FILES=$(CODE_F90_TEX_FILES)
+
+
+PDFLATEX_OUTPUT_LOG=pdflatex_output.log
+
+all: presentation.pdf
+
+display: presentation.pdf
+       xpdf presentation.pdf
+
+display-4up: presentation-4up.pdf
+       xpdf presentation-4up.pdf
+
+4up: presentation-4up.pdf
+
+presentation-4up.pdf: presentation.pdf
+       pdfnup --nup 2x2 --a4paper --scale 0.95 --frame true presentation.pdf -o presentation-4up.pdf
+
+presentation.pdf: $(IMAGE_FILES) $(SVG_OUTPUTS) $(CODE_TEX_FILES) $(wildcard *.tex *.sty)
+       pdflatex -draftmode presentation &&\
+       while(pdflatex presentation | tee $(PDFLATEX_OUTPUT_LOG) && grep "Rerun to get cross-references right" $(PDFLATEX_OUTPUT_LOG)); do true; done &&\
+       rm -f $(PDFLATEX_OUTPUT_LOG)
+
+clean:
+       rm -f *.aux *.log *.out *.pdf *.bbl *.blg *.toc *.lot *.lof *.nav *.snm \
+        $(SVG_FOLDER)/*.pdf \
+        $(BASIS_FUNCTIONS_FOLDER)/*.pdf \
+        $(BASIS_FUNCTIONS_BUILD_STAMP) \
+        $(CODE_TEX_FILES) \
+        pygments.sty
+
+upload: presentation.pdf
+       rsync -C --progress presentation.pdf shell3.doc.ic.ac.uk:~/public_html/psl_onetep_presentation.pdf
+
+%.pdf: %.svg
+       inkscape -D -A $@ $<
+
+pygments.sty:
+       pygmentize -S bw -f latex > $@
+
+%.tex: %.F90
+       pygmentize -f latex -l fortran -o $@ $<
+
+.PHONY: all display clean upload 4up display-4up

diff --git a/presentation.tex b/presentation.tex
new file mode 100644 (file)
index 0000000..a1beb4c
--- /dev/null
+++ b/presentation.tex
@@ -0,0 +1,259 @@
+% vim:tw=80
+
+\documentclass{beamer}
+\usetheme{Madrid}
+\usepackage{graphicx}
+\usepackage{verbatim}
+\usepackage{ucs}
+\usepackage{alltt}
+\usepackage[utf8x]{inputenc}
+
+%\input{pygments.sty}
+
+\title[ONETEP - DSLs and GPUs]{ONETEP - Code generation from a Quantum Chemistry
+DSL / GPU Parallelisation}
+
+\subtitle{PSL Presentation}
+\author[K. Wilkinson \& F. Russell]{Karl Wilkinson \& Francis Russell \\ Joint work with Chris-Kriton Skylaris \& Paul Kelly}
+\date{18/04/2012}
+\institute[ICL \& Soton]{Imperial College London \& Southampton University}
+
+\begin{document}
+
+\frame{\titlepage}
+
+\frame{
+
+\frametitle{Background}
+
+\begin{itemize}
+
+\item ONETEP is a parallel, linear scaling Fortran code for performing
+quantum chemistry calculations based on density functional theory.
+
+\item Users of ONETEP for research want to be able to modify it to compute
+new quantities with the mimimal time and effort.
+
+\item Developers of ONETEP want to be able to modify it to make efficient use of
+new architecures (in particular GPUs) with reduced time and effort.
+
+\item Domain specific languages (DSLs) are a mechanism which enable both requirements
+to be satisfied.
+
+\end{itemize}
+
+}
+
+\frame{
+
+\frametitle{DSLs for Computational Science}
+
+\itemize{
+
+\item A formal, machine-interpretable notation for specifying a problem
+using a domain-oriented syntax.
+
+\item Allow scientists to concentrate on the problems they're solving rather
+than the implementation.
+
+\item Reduce time and effort taken to go from decision to compute some value to
+having efficient code that implements it.
+
+\item Allow computer scientists to work on optimised implementations without
+having to understand the subtleties mathematics.
+
+\item Target code to multiple platforms/architectures/instruction sets via
+changes to the code generator rather than the high-level description.
+
+}
+
+}
+
+
+\frame {
+
+\frametitle{A Domain Specific Language for Quantum Chemistry}
+
+\begin{itemize}
+
+\item Quantum chemistry papers already describe the calculations they
+use with mathematical notation.
+
+\item Natural candidate for modelling a domain specific language around.
+
+\item Current work involves construction of a compiler (the ONETEP Form
+Compiler) to compile a DSL describing a quantum chemistry computation
+(provisionally called the ONETEP Form Language) to a Fortran method that
+compiles within the existig ONETEP code base.
+
+\end{itemize}
+
+}
+
+\frame{
+
+\frametitle{Example: ONETEP Kinetic Energy Integral}
+
+To calculate the kinetic energy matrix entry $T^\text{box}_{\alpha\beta}$ at
+$(\alpha, \beta)$ (in bra-ket notation):
+
+\begin{align}
+T^\text{box}_{\alpha\beta} &=
+\langle\phi_\alpha|
+\hat{P}^\dagger(\alpha\beta)\hat{T}\hat{P}(\alpha\beta)
+|\phi_\beta\rangle
+\end{align}
+
+where:
+
+\begin{itemize}
+
+\item $\hat{T} = -\frac{1}{2}\nabla^2$ is the kinetic energy operator (similar to a
+Laplacian).
+
+\item $\phi_\alpha$ and $\phi_\beta$ are atomic functions.
+\item $\hat{P}$ and $\hat{P}^\dagger$ are operators to transform to and from
+reciprocal space in a periodic region.
+
+\end{itemize}
+}
+
+\frame[containsverbatim]{
+
+\frametitle{Example: ONETEP Kinetic Energy Integral} 
+
+We propose a syntax for writing:
+
+\begin{align}
+T^\text{box}_{\alpha\beta} &=
+\langle\phi_\alpha|
+\hat{P}^\dagger(\alpha\beta)\hat{T}\hat{P}(\alpha\beta)
+|\phi_\beta\rangle
+\end{align}
+
+similar to this:
+
+\begin{verbatim}
+kinet[alpha, beta] = inner(bra[alpha],
+  reciprocal(laplacian(reciprocal(fftbox(ket[beta])))*-0.5))
+\end{verbatim}
+
+}
+
+\frame[containsverbatim]{
+
+\frametitle{Example: ONETEP Kinetic Energy Integral}
+
+The full syntax includes type declarations:
+
+\begin{verbatim}
+Matrix kinet
+FunctionSet bra, ket
+Index alpha, beta
+\end{verbatim}
+
+and glue for interfacing with ONETEP
+
+\begin{verbatim}
+target ONETEP
+kinet is SPAM3("kinet")
+bra is PPDFunctionSet("bra_basis", "bras_on_grid")
+ket is PPDFunctionSet("ket_basis", "kets_on_grid")
+output is FortranFunction("integrals_kinetic", ["kinet", 
+  "bras_on_grid", "bra_basis", "kets_on_grid", "ket_basis"])
+\end{verbatim}
+
+}
+
+\frame{
+
+\frametitle{Implementation Challenges: Interfacing with ONETEP}
+
+We do not have a well-defined abstract interface to interact with ONETEP. We
+have to work with existing ONETEP data structures and method definitions.
+
+\begin{itemize}
+
+\item The ONETEP data structures have been designed for performance and with
+concerns specific to the ONETEP implementation.
+
+\item Some of the data structures used are sparse and can only be accessed
+efficiently in certain ways.
+
+\item We need to allow for the possibility of data structures changing and/or
+new data structures in future.
+
+\end{itemize}
+
+}
+
+\frame{
+
+\frametitle{Implementation Challenges: Mapping the DSL to Code}
+
+The mapping of DSL expressions to code is particularly problematic for ONETEP.
+
+\begin{itemize}
+
+\item Typically we would generate a topological sort of an expression DAG, then
+generate code for computing operands and evaluating operators corresponding to
+that order.
+
+\item Due to the data structures involved, we cannot be certain we can store
+arbitrary intermediate expressions. Even if we could, due to sparsity, this
+would be problematic.
+
+\item The complexity in code generation for ONETEP lies in the fact that the
+control flow of the generated code is inherently dependent on both the DSL
+expression being evaluated, and the way we can access the data structures
+involved.
+
+\item \emph{We need a compositional model for control flow.}
+
+\end{itemize}
+
+}
+
+
+\frame{
+
+\frametitle{Solution Strategy: Data-Structure Descriptors}
+
+We provide the code generator with an abstract description of how to iterate
+efficiently over a data structure along with functions that describe how the
+abstract indices we work with (spatial positions) are calculated from the data
+(loop indices and other data).
+\newline\newline
+This allows the code generator to use the natural way to iterate over data
+structures when possible, but also generate random access operations or
+filtering operations when required.
+\newline\newline
+We adopt the idea of a producer-consumer model of expression evaluation. The
+DSL compiler's task is to orchestrate the movement and indexing of data
+according to the indexing constraints and granularity requirements.
+
+}
+
+\frame{
+
+\frametitle{Implementation Challenges: DSL Semantics and Flexibility}
+
+\begin{itemize}
+
+\item We need well-defined semantics for every operation we might use in the
+DSL. In particular, we need a type system for the expressions that can be
+produced that incorporates properties such as function space.
+
+\item The "side-channel" information of each operand needs to be well-defined.
+For example, whether subsets of some larger space possess knowledge of how they
+map to the underlying space.
+
+\item We need a description of what types of indexing operations we need to be
+able to perform. Do we want to support direct manipulation of spatial indices,
+support reduction operations etc.
+
+\end{itemize}
+
+}
+
+\end{document}