CODE_UFL_TEX_FILES=${patsubst %.ufl,%.tex,$(wildcard $(CODE_FOLDER)/*.ufl)}
CODE_TEX_FILES=$(CODE_F90_TEX_FILES) $(CODE_UFL_TEX_FILES)
+DOT_FOLDER=images-dot
+DOT_TEX_FILES=${patsubst %.dot,%.tex,$(wildcard $(DOT_FOLDER)/*.dot)}
+
PDFLATEX_OUTPUT_LOG=pdflatex_output.log
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) pygments.sty
+presentation.pdf: $(IMAGE_FILES) $(SVG_OUTPUTS) $(CODE_TEX_FILES) $(DOT_TEX_FILES) $(wildcard *.tex *.sty) pygments.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)
$(BASIS_FUNCTIONS_FOLDER)/*.pdf \
$(BASIS_FUNCTIONS_BUILD_STAMP) \
$(CODE_TEX_FILES) \
+ $(DOT_FOLDER)/*.tex \
pygments.sty
upload: presentation.pdf
%.tex: %.ufl
pygmentize -f latex -l python -o $@ $<
+%.tex: %.dot
+ dot2tex --codeonly --usepdflatex -f tikz $< -o $@
+
.PHONY: all display clean upload 4up display-4up
--- /dev/null
+digraph discrete_expression_dag
+{
+ size="6x9";
+ ratio="compress";
+
+ // Expression DAG
+ node[shape=box, style=filled, texmode="raw", height=0.3,
+ style="thick,draw=blue!75,fill=blue!20,rounded corners=1pt"
+ ];
+
+ "multiply" [label="$\times$"];
+ "dot" [label="$\\begin{matrix} \\cdot \\\\ \\{x_b=x''_k, y_b=y''_k, z_b=z''_k\\} \\end{matrix}$", height=1.0];
+
+ edge[texmode="raw"];
+ "dot" -> "bra[alpha]" [label="$\\{func_b,x_b,y_b,z_b\\}$"];
+ "fft" -> "ket[beta]" [label="$\\{func_k,x_k,y_k,z_k\\}$"];
+ "laplacian" -> "fft" [label="$\\{func_k,x'_k,y'_k,z'_k\\}$"];
+ "ifft" -> "laplacian" [label="$\\{func_k,x'_k,y'_k,z'_k\\}$"];
+ "dot" -> "ifft" [label="$\\{func_k,x''_k,y''_k,z''_k\\}$"];
+ "multiply" -> "dot" [label="$\\{func_b,func_k\\}$"];
+ "multiply" -> "-0.5" [label="$\\emptyset$"];
+}
\usepackage{graphicx}
\usepackage{verbatim}
\usepackage{fancyvrb}
+\usepackage{tikz}
\usepackage{ucs}
\usepackage{alltt}
\usepackage[utf8x]{inputenc}
}
-\frame{
+\frame[containsverbatim]{
\frametitle{The Domain of Variability in ONETEP}
+Our initial approach consisted of designing a DSL similar in style to
+UFL since the operations and notation were similar.
+
+\vspace{1em}
+
+As an example, the kinetic energy integral in mathematical notation:
+
+\vspace{1em}
+
+\begin{equation*}
+T_{\alpha\beta} = - \frac{1}{2}
+\phi_{\alpha}^{*}(\mathbf{r})\nabla^2\phi_{\beta}(\mathbf{r})\;d\mathbf{r}
+\end{equation*}
+
+\vspace{1em}
+
+and written as an expression in the DSL (omitting declarations and other
+additional details):
+
+\vspace{1em}
+
+\begin{verbatim}
+kinet[alpha, beta] =
+ inner(bra[alpha], laplacian(ket[beta])*-0.5)
+\end{verbatim}
+
+}
+
+\frame{
+
+\frametitle{Our initial design}
+
+\begin{itemize}
+
+\item The fields used by ONETEP are stored in a blocked space format
+called \emph{PPD representation}.
+
+\item PPD representation involves storing a field using fixed-size blocks
+of co-efficients only for locations in the cell where data is not
+zero-valued.
+
+\item This representation is not dissimilar to that used by some formats
+of sparse matrix storage.
+
+\item In addition, the presence of indices into sparse matrices,
+multi-dimensional arrays and reduction operators suggests a system that
+generates code that implements tensor contractions between large, distributed,
+possibly sparse multi-dimensional objects.
+
+\end{itemize}
+
+}
+
+
+\frame{
+
+\frametitle{Relational algebra to the rescue?}
+
+\begin{itemize}
+
+\item Efficiently implementing contractions between
+ multi-dimensional arrays stored in representations is similar to
+ the problem faced by databases implementing joins.
+
+\item We looked at work by Kotlyar on generating efficient code that handles
+ accessing multi-dimensional data stored using user-defined data structures.
+
+\item The system uses a ``hierarchy of indices'' that describe
+ properties such as dependencies between indices, whether random access is
+ possible, the nature of overlaps between data.
+
+\end{itemize}
+
\centering
-\scalebox{15.0}{
-$\emptyset$
+{
+\footnotesize
+\begin{tabular}{rl}
+\hline
+\textbf{Name} & \textbf{Type} \\
+\hline
+CRS & $T_{CRS} = I \succ J \succ V $ \\
+CCS & $T_{CCS} = J \succ I \succ V $ \\
+Co-ordinate & $T_{coord} = (I, J) \succ V $ \\
+Dense & $T_{dense} = I \times J \succ V $ \\
+inode & $T_{inode} = INODE \succ_{\not \cap} (I \times J) \succ V $ \\
+Finite element & $T_{FE} = E \succ_{+} (I \times J) \succ V $ \\
+Permutation & $T_{perm} = (I \succ I') \cup (I' \succ I)$ \\
+\hline
+\end{tabular}
+}
+
}
+\frame{
+
+\frametitle{Our initial implementation}
+
+We developed an code generator in Scala that attempted to reason
+abstractly about the indices involved in the computation.
+
+\centering
+\resizebox{!}{0.5\textheight}{
+\begin{tikzpicture}[scale=0.5, minimum size=2em, thick]
+\input{images-dot/index_propagation_dag}
+\end{tikzpicture}
}
+}
\end{document}
+
+