Commit 59539be4 authored by Spencer Sherwin's avatar Spencer Sherwin
Browse files

Merge branch 'master' into 'feature_YuPan_developerguide'

# Conflicts:
#   developers-guide.bib
parents d17bd1d7 60190aa8
......@@ -518,6 +518,98 @@ year = "2011"
%% NekPy references
author = "de Guzman J., Abrahams D.",
title = "Boost.Python Tutorial - 1.67.0",
year = "2018",
url = "",
note = "[Accessed 1st May 2018]"
title = "boost.python/HowTo - Python Wiki",
year = "2015",
url = "",
note = "[Accessed 1st May 2018]"
title = "GitHub - TNG/boost-python-examples: Some examples for the use of boost::python",
year = "2016",
url = "",
note = "[Accessed 7th May 2018]"
title = "osgboostpython/ at wiki · Skylark13/osgboostpython · GitHub",
year = "2015",
url = "",
note = "[Accessed 7th May 2018]"
title = "osgboostpython/ at wiki · Skylark13/osgboostpython · GitHub",
year = "2015",
url = "",
note = "[Accessed 7th May 2018]"
title = "PEP 257 -- Docstring Conventions",
author = "Goodger D., van Rossum G.",
year = "2001",
url = "",
note = "[Accessed 16th May 2018]"
title = "Piotr Jaroszyński's blog: Boost.Python: docstrings in enums",
author = "Jaroszyński P.",
year = "2007",
url = "",
note = "[Accessed 16th May 2018]"
title = "Google Python Style Guide",
author = "Patel A., Picard A., Jhong E. et al.",
url = "",
note = "[Accessed 16th May 2018]"
title = "API Design for C++",
author = "Reddy M.",
year = "2011",
publisher = "Burlington: Elsevier"
author = "Daconta M.",
title = "C++ pointers and dynamic memory management",
publisher = "New York: Wiley",
year = "1995"
title =" std::shared\_ptr -",
url = "\_ptr",
note = "[Accessed 21 March 2018]"
author = "Python Software Foundation",
title = "Memory Management - Python 2.7.14 documentation",
url = "",
note = "[Accessed 21 March 2018]"
author = "Python Software Foundation",
title = "Reference Counting - Python 2.7.14 documentation",
url = "",
note = "[Accessed 21 March 2018]"
......@@ -98,6 +98,10 @@
\part{NekPy: Python interface to \nek{}} \label{part:nekpy}
The NekPy package certainly had to be documented in order to provide an easily accessible
information about the wrapped classes to both users and developers. Ideally, the documentation should be:
\item easily readable by humans,
\item accessible using Python's inbuilt \texttt{help} method,
\item compatible with the existing Nektar++ doxygen-based documentation.
Traditionally, Python classes and functions are documented using a docstring -- a string occurring
as the very first statement after the function or class is defined. This string is then accessible
as the \texttt{\_\_doc\_\_} attribute of the function or class. The conventions associated with
Python docstrings are described in PEP 257 document \cite{PEP257}.
Boost.Python provides an easy way to include docstrings in the wrapped methods and classes as
shown in Listing \ref{lst:doc_example}. The included docstrings will appear when Python
\texttt{help} method is used.
\begin{lstlisting}[caption={Example of class and method documentation in Boost.Python}, label={lst:doc_example}, language=C++]
void export_Points()
"Create a PointsKey which uniquely defines quadrature points.\n"
"\tnQuadPoints (integer): The number of quadrature points.\n"
"\tpointsType (PointsType object): The type of quadrature points.",
py::init<const int, const PointsType&>())
.def("GetNumPoints", &PointsKey::GetNumPoints,
"Get the number of quadrature points in PointsKey.\n"
"\tInteger defining the number of quadrature points in PointsKey.")
In order to fully document the existing bindings a number of enumeration type classes such
as \texttt{PointsType} had to have docstrings included which proved to be a challenge
since Boost.Python does not provide a way to do this. Instead a direct call to Python C API
has to be made and the method adapted from \cite{PythonEnumDocstring} was used, as shown in
Listing \ref{lst:enum_doc}. A downside of this solution is that it does requires the developer
to manually update the Python documentation if the enumeration type is ever changed (e.g.
adding a new type of point) as the code does not automatically gather information from the
C++ class. In theory it could be possible to create a Python script which would generate Python
docstrings based on the existing C++ documentation using regular expressions; however it would
be difficult to integrate this solution into the existing framework.
\begin{lstlisting}[caption={Code used to include dosctings in enumetation type classes - part of \texttt{NekPyConfig.hpp}}, label={lst:enum_doc}, language=C++]
{ \
py::enum_<ENUMNAME> tmp(#ENUMNAME); \
for (int a = 0; a < (int)SIZENAME(ENUMNAME); ++a) \
{ \
tmp.value(MAPNAME[a].c_str(), (ENUMNAME)a); \
} \
tmp.export_values(); \
PyTypeObject * pto = \
reinterpret_cast<PyTypeObject*>(tmp.ptr()); \
PyDict_SetItemString(pto->tp_dict, "__doc__", \
PyString_FromString(DOCSTRING)); \
There are many docstrings conventions that are popular in Python such as Epytext, reST and
Google therefore a choice had to be made as to which docstring style to use. After considering
the criteria which the documentation had to fulfill it was decided to use Google Python Style
\cite{PythonGoogle} as it is highly readable by humans (and hence an excellent choice for
documentation which will be primarily accessible by Python \texttt{help} method) and can be
used to generate automated documentation pages with Sphinx (a tool for creating Python documentation).
Unfortunately, it proved to be difficult to include the documentation of NumPy package in the
existing doxygen-based documentation due to the fact that the docstrings are generated by Boost.Python.
It was decided that if the time constraints of the project permit this problem could be resolved
at a later date and the possibility of accessing the documentation though inbuilt \texttt{help}
method was deemed sufficient.
\chapter{FieldConvert in NekPy}
This chapter will describe the idea behind the \texttt{FieldConvert} utility in
NekPy and discuss how the process is implemented through a Python
\texttt{FieldConverter} class. As this part of the project has not been fully
completed yet, this chapter also outlines the tasks that need to be done in order
to show the proof-of-concept, as well as some ideas for further improving the tool.
\section{Idea and motivation}
The idea behind porting \texttt{FieldConvert} utility to Python is to allow the
user to execute a seamless workflow, from converting the mesh and running
calculations to preparing data visualisations. This solution is a potential
improvement over the original \texttt{FieldConvert} tool, as the Python-based
workflow can potentially be executed from a single Python script.
Another advantage of the Python version of the tool is the possibility of
interacting with other software featuring Python interface, e.g. Paraview.
This could make the process of visualising the results of computations done
with \nek{} even easier.
\section{Design and implementation}
\texttt{FieldConvert} utility in Python was designed to provide the user with
an easy workflow. Hence, a minimum effort is required to set up the conversion
and the majority of work is done behind the scenes.
This section will discuss the design of the utility, including the description
of work yet to be done, as well as the user workflow required to execute the
basic conversions.
\subsection{\texttt{FieldConverter} class}
The entire procedure outlined in the original \texttt{FieldConvert} utility is
managed by the \texttt{FieldConverter} class located in
\path{utilities/FieldConvert/Python/}. The class has the following
\item \texttt{fieldSharedPtr}: a shared pointer to the field, necessary to
initialise a module;
\item \emph{TO-DO}: \texttt{FieldSharedPtr} type remains to be wrapped.
\item \emph{TO-DO}: Whether a separate \texttt{FieldSharedPtr} is
needed for each module initialisation needs to be discussed.
\item \texttt{moduleFactory}: would be equivalent to \texttt{GetModuleFactory()}
in the original utility;
\item \emph{TO-DO}: Whether this is possible needs to be discussed.
\item \emph{TO-DO}: It would be best to wrap the general template
\texttt{NekFactory} and initialise a module factory this way.
\item \texttt{availableModuleList}: holds a list of available modules in
order to assert that the modules requested by the user are available;
\item \emph{TO-DO}: \texttt{PrintAvailableClasses} method needs to
be wrapped.
\item \emph{TO-DO}: It would definitely be neater if the available modules
existed as an enum rather than just strings containing names.
\item \texttt{sessionFile}, \texttt{inputFile}, \texttt{outputFile}:
hold the necessary filenames;
\item \texttt{moduleList}: holds a list of \texttt{Module} objects, created as
requested by the user;
\item \texttt{variableMap}: equivalent of \texttt{vm} variable from the original
\item \emph{TO-DO}: This variable map needs to be constructed from user
input as it needs to be passed into \texttt{Process} method of
\texttt{Module} class.
\subsection{User workflow}
The currently suggested user workflow is as follows:
\item Initialise an instance of \texttt{FieldConverter} class.
\item Add a session file as well as an input and an output file.
\item The converter will assert that the session file and the input file
exist, assert that the file extensions are supported and create appropriate
\item Add any modules, e.g. \texttt{vorticity}.
\item Currently the argument passed into \texttt{addProcessModule} is a
string containing the module name.
\item \emph{TO-DO}: As mentioned before, it would be neater if said
argument was an enum.
\item \emph{TO-DO}: Some more thought is required about how to support
modules requiring or permitting parameters. One solution would be to pass
a tuple containing module name and parameters. Care needs to be taking in
asserting the validity of parameters.
\item As before, the converter will assert that the module exists and create
an appropriate \texttt{Module} class object.
\item Run the conversion.
The code showcasing the suggested workflow can be found in the main function of the
\texttt{} file.
\subsection{Conversion process}
\section{Further development and improvement}
\ No newline at end of file
\chapter{Installing NekPy}
NekPy has the following list of requirements:
\item Boost with Python support
\item Nektar++ \texttt{master} branch compiled from source (i.e. not from packages)
\item Python 2.7+ (note that examples rely on Python 2.7)
\item NumPy
Most of these can be installed using package managers on various operating
systems, as we describe below. We also have a requirement on the \texttt{Boost.NumPy}
package, which is available in Boost 1.63 or later. If this isn't found on your
system, it will be automatically downloaded and compiled.
\section{Compiling and installing Nektar++}
Nektar++ should be compiled as per the user guide instructions and installed
into a directory which we will refer to as \texttt{\$NEKDIR}. By default this is the
\texttt{dist} directory inside the Nektar++ build directory.
Note that Nektar++ must, at a minimum, be compiled with \texttt{NEKTAR\_BUILD\_LIBRARY},
This will automatically download and install \texttt{Boost.NumPy} if required. Note
that all solvers may be disabled as long as the \texttt{NEKTAR\_BUILD\_SOLVERS} option is set.
Users of Homebrew should make sure their installation is up-to-date with
\texttt{brew upgrade}. Then run
brew install python boost-python
To install the NumPy package, use the \texttt{pip} package manager:
pip install numpy
Users of MacPorts should sure their installation is up-to-date with
\texttt{sudo port selfupdate \&\& sudo port upgrade outdated}. Then run
sudo port install python27 py27-numpy
sudo port select --set python python27
\subsection{Linux: Ubuntu/Debian}
Users of Debian and Ubuntu Linux systems should sure their installation is
up-to-date with \texttt{sudo apt-get update \&\& sudo apt-get upgrade}
sudo apt-get install libboost-python-dev python-numpy
\subsection{Compiling the wrappers}
Run the following command in \path{$NEKDIR/build} directory to install the Python package
for the current user:
make nekpy-install-user
Alternatively, the following command can be used to install the package for all users:
make nekpy-install-system
\section{Using the bindings}
By default, the bindings will install into the \texttt{dist} directory, along with a
number of examples that are stored in the
\path{$NEKDIR/library/Demos/Python} directory. To
test your installation, you can for example run one of these (e.g. \texttt{python}) or
launch an interactive session:
$ cd builds
$ python
Python 2.7.13 (default, Apr 4 2017, 08:47:57)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from NekPy.LibUtilities import PointsKey, PointsType
>>> PointsKey(10, PointsType.GaussLobattoLegendre)
<NekPy.LibUtilities._LibUtilities.PointsKey object at 0x11005c310>
A number of examples of the wrappers can be found in the
directory, along with a sample mesh \texttt{newsquare\_2x2.xml}:
\item \texttt{} is the simplest example and shows how to construct a
session reader object. Run it as \texttt{python mesh.xml}.
\item \texttt{} shows functionality of basic \texttt{LibUtilities} points and basis
classes. Run this as \texttt{python}.
\item \texttt{} shows how to use some of the \texttt{StdRegions} wrappers and
duplicates the functionality of \texttt{} using the \texttt{StdExpansion} class. Run
this as \texttt{python}.
\item \texttt{} loads a mesh and prints out some basic properties of its
quadrilateral elements. Run it as \texttt{python newsquare\_2x2.xml}.
If you want to modify the source files, it's advisable to edit them in the
\path{$NEKDIR/library/Demos/Python} directory and
re-run \texttt{make install}, otherwise local changes will be overwritten by the next \texttt{make install}.
This part of the guide contains the information on using and developing \texttt{NekPy}
Python wrappers for the \nek{} spectral/\textit{hp} element framework.
\emph{As a disclaimer, these wrappings are experimental and incomplete.}
You should not rely on their current structure and API remaining unchanged.
Currently, representative classes from the \texttt{LibUtilities}, \texttt{StdRegions},
\texttt{SpatialDomains}, \texttt{LocalRegions} and \texttt{MultiRegions} libraries
have been wrapped in order to show the proof-of-concept.
\section{Features and functionality}
\texttt{NekPy} uses the \texttt{Boost.Python} library to provide a set of high-quality,
hand-written Python bindings for selected functions and classes in Nektar++.
It is worth noting that Python (CPython, the standard Python implementation written in C,
in particular) includes C API and that everything in Python is strictly speaking a C
structure called \texttt{PyObject}. Hence, defining a new class, method etc. in Python
is in reality creating a new \texttt{PyObject} structure.
Boost.Python is essentially a wrapper for Python C API which conveniently exports C++
classes and methods into \texttt{PyObjects}. At compilation time a dynamic library
is created which is then imported to Python, as shown in Figure \ref{fig:boost_python}.
\caption{A schematic diagram of how C++ code is converted into Python with Boost.Python \cite{C++Api}}
A typical snippet could look something like:
\begin{lstlisting}[caption={NekPy sample snippet}, label={lst:nekpy_sample}, language=Python]
from NekPy.LibUtilities import PointsKey, PointsType, BasisKey, BasisType
from NekPy.StdRegions import StdQuadExp
import numpy as np
numModes = 8
numPts = 9
ptsKey = PointsKey(numPts, PointsType.GaussLobattoLegendre)
basisKey = BasisKey(BasisType.Modified_A, numModes, ptsKey)
quadExp = StdQuadExp(basisKey, basisKey)
x, y = quadExp.GetCoords()
fx = np.sin(x) * np.cos(y)
proj = quadExp.FwdTrans(fx)
\texttt{NekPy} uses the \texttt{Boost.NumPy} library, contained in Boost 1.63+, to
automatically convert C++ \texttt{Array<OneD, >} objects to and from the commonly-used
\texttt{numpy.ndarray} object, which makes the integration more seamless between Python
and C++.
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment