--- /dev/null
+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
--- /dev/null
+% vim:tw=80
+
+\documentclass{beamer}
+\usetheme{Madrid}
+\usepackage{graphicx}
+\usepackage{verbatim}
+\usepackage{ucs}
+\usepackage{alltt}
+\usepackage[utf8x]{inputenc}
+
+%\input{pygments.sty}
+
+\title[ONETEP Masterclass]{ONETEP Masterclass Presentation}
+\subtitle{Domain Specific Languages for Quantum Chemistry}
+
+\author[F. Russell]{Francis Russell \\ Joint work with Chris-Kriton Skylaris \& Karl Wilkinson}
+\date{28/08/2012}
+\institute[ICL \& Soton]{Imperial College London \& Southampton University}
+
+\begin{document}
+
+\frame{\titlepage}
+
+\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[containsverbatim]
+{
+\frametitle{UFL: A Domain Specific Language for Finite Element Variational Forms}
+
+\begin{itemize}
+
+\item The Unified Form Language (UFL) is a DSL for specifying finite element
+variational forms developed by the FEniCS project.
+
+\item Mathematically, we might write the finite element variational form for the
+Laplacian as follows:
+
+\begin{equation*}
+a(u,v) = \int_\Omega \nabla u(x) \cdot \nabla v(x)\,dx
+\end{equation*}
+
+\item In UFL (specifying physical discretisation) we would write:
+
+\begin{verbatim}
+element = FiniteElement("Lagrange", triangle, 2)
+
+u = TrialFunction(V)
+v = TestFunction(V)
+a = dot(grad(u), grad(v))*dx
+\end{verbatim}
+\end{itemize}
+
+}
+
+\frame{
+
+\frametitle{Previous Work}
+
+\begin{itemize}
+
+\item I looked at domain specific languages for specifying aspects of finite
+element problems.
+
+\item Developed a compiler that performed symbolic analysis of finite element
+integrals and searched for exploitable redundancies.
+
+\item For many integrals, the resulting code had a reduced operation count over
+alternative optimised implementations.
+
+\item The generated code couldn't possibly have been correctly written or
+maintained by hand.
+
+\end{itemize}
+
+}
+
+\frame[containsverbatim]{
+
+\frametitle{Current Work}
+
+What can domain specific languages do for ONETEP?
+
+\begin{itemize}
+
+\item For new quantities we want to evaluate, we can generate ONETEP
+implementations directly from an expression in a DSL.
+\begin{verbatim}
+Array[FunctionIndex, FunctionIndex] kinet
+FunctionSet bra, ket
+FunctionIndex alpha, beta
+
+kinet[alpha, beta] = inner(bra[alpha],
+ laplacian(ket[beta])*-0.5)
+\end{verbatim}
+
+\item Use the DSL compiler as a means to exploring optimisations that can be
+performed in the ONETEP code.
+
+\end{itemize}
+
+Code involving conversions from real space and reciprocal space look like ideal
+candidates for exploring these optimisations.
+
+}
+
+\frame{
+
+\frametitle{Sparsity in the FFT-box}
+
+\resizebox{\linewidth}{!}{\includegraphics{images/fftbox}}
+
+}
+
+\frame{
+
+\frametitle{Reducing the cost of reciprocal space transformations}
+
+Looking at FFTs:
+
+\begin{itemize}
+
+\item There are may cases where FFTs are padded with zeros.
+
+\item In other cases, only a restricted subset of the result data is used.
+
+\item Is it possible to exploit this to reduce to cost?
+
+\end{itemize}
+
+Alternatively, we can look at intermediate approach between FFTs and finite
+difference:
+
+\begin{itemize}
+
+\item Perhaps finite difference can produce an acceptible result for some
+quantities.
+
+\item Unclear what an intermediate approach might look like.
+
+\end{itemize}
+
+
+}
+
+\end{document}
projects / francis / onetep_masterclass_presentation_20120828.git / commitdiff
