From 5992c5bf254c1521a607d4698c86b7f0e3eb26ba Mon Sep 17 00:00:00 2001
From: Francis Russell <francis@unchartedbackwaters.co.uk>
Date: Fri, 24 Feb 2012 19:14:19 +0000
Subject: [PATCH] Add report on implementation issues.

---
 docs/implentation_issues.tex | 95 ++++++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 docs/implentation_issues.tex

diff --git a/docs/implentation_issues.tex b/docs/implentation_issues.tex
new file mode 100644
index 0000000..e175baa
--- /dev/null
+++ b/docs/implentation_issues.tex
@@ -0,0 +1,95 @@
+% vim:tw=80
+\documentclass[a4paper, twoside, pdflatex]{article}
+\usepackage[utf8x]{inputenc}
+
+\title{Observations on Compiling a Quantum Chemistry DSL to a ONETEP Fortran
+Implementation}
+\author{Francis Russell}
+\date{}
+
+\begin{document}
+\maketitle
+
+\section{The Task}
+
+Compile a domain specific language describing a quantity computed in the
+quantum chemistry code ONETEP to a Fortran implementation capable of interacting
+with ONTEP.
+
+Some points to note:
+
+\begin{itemize}
+
+\item We posses hand-optimised implementations of the code corresponding to DSL
+expressions we wish to be able to compile in ONETEP already.
+
+\item The code generated needs to interact with ONETEP data structures either
+directly, or via ONETEP supplied methods. The interface to these operands are
+highly performance-oriented and are intended to satisfy a number of requirements
+specific to ONETEP. However, we do not wish to over-specialise the code
+generator to these data structures in case they change, or we decide to target
+other applications other than ONETEP.
+
+\end{itemize}
+
+\section{The Domain Specific Language}
+
+As an example, we consider a fragment of our DSL that specifies the computation
+of a matrix as performed the {\tt integrals\_kinetic} function on ONETEP.
+
+\begin{verbatim}
+kinet[alpha, beta] = 
+  inner(bra[alpha], reciprocal(laplacian(reciprocal(fftbox(ket[beta])))*-0.5))
+\end{verbatim}
+
+Here, {\tt alpha} and {\tt beta} represent indices that are correspond to a
+quantification of the indices over all valid values. Indices are defined to have
+the same value at all points of use in the expression.
+
+In the above expression, the indices have been used to specify the rows and
+columns of matrix {\tt kinet} and specific functions in the function sets {\tt
+bra} and {\tt ket}.
+
+We have currently chosen not to expose the indices that correspond to the
+spatial co-ordinates of the basis function data itself.
+
+\subsection{Validation}
+
+Given that indices can be bound in the expressions we can write in our DSL
+arbitrarily, it is unclear whether or not it is possible to construct
+expressions which are invalid due to a particular choice of index bindings. In
+this case we take \emph{invalid} to mean that it is impossible to evaluate an
+assignment. Ignoring mathematical concerns, we require that for an expression to
+be valid:
+
+\begin{itemize}
+
+\item It it should be possible to synthesize a loop nest that
+evaluates the specified assignment.
+
+\item The interpretation of value of the LHS of the assignment is unique.
+
+\end{itemize}
+
+We consider the following expression:
+
+\begin{verbatim}
+a[i,j] = c[i][k] * d[j][k]
+\end{verbatim}
+
+We consider this malformed since dimension {\tt k} exists on the RHS but not on
+the LHS. We do not adopt \emph{Einstein notation} in that a repeated index
+implies a summation over that index.
+
+\section{Implementation Issues}
+
+In this section I discuss the various issues encountered in the initial creation
+of the code generator.
+
+\section{The Naïve Implementation}
+
+The most naïve implementation is to attempt to evaluate the RHS of the
+assignment using the same strategy one would use for a simple scalar expression
+tree.
+
+\end{document}
-- 
2.47.3