Commit e3faa013 authored by Yann Pouillon's avatar Yann Pouillon

Imported basic ESL documentation elements

This diff is collapsed.
ESL Demonstrator - Basic Plane-Wave Code
.. image::
:alt: Build status
``esl-demo-pw`` demonstrates how to use Electronic Structure Library
components to build and run a basic plane-wave Density Functional Theory code.
Minimum requirements
The following software elements are required to play with this project:
- A C compiler (e.g. gcc, icc, pgcc, xlc, ...)
- A Fortran compiler (e.g. gfortran, ifort, pgif90, xlf, ...)
- A recent Python interpreter (Python 2 >= 2.7.13 or Python 3 >= 3.5.1)
- GNU Make >= 2.80 (other versions may work but have not been tested)
To build the documentation, you will need a recent version of `Sphinx`_.
Developer requirements
If you clone the Git repository of ``esl-demo-pw``, you will need the following
packages to build the demonstrator:
- Autoconf >= 2.69
- Automake >= 1.15
- Libtool >= 2.4.2
- M4 >= 1.4.17
ESL Components
This ESL Demonstrator makes use of the following ESL components:
- LibXC
- OMM Bundle
- Pspio
- ESLW_Drivers
They will be downloaded and built automatically the first time you try to build
# Makefile for Sphinx documentation
# You can set these variables from the command line.
SPHINXBUILD = sphinx-build
BUILDDIR = _build
# User-friendly check for sphinx-build
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
# the i18n builder cannot share the environment and doctrees with the others
.PHONY: help
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " applehelp to make an Apple Help Book"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " texinfo to make Texinfo files"
@echo " info to make Texinfo files and run them through makeinfo"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " xml to make Docutils-native XML files"
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
@echo " coverage to run coverage check of the documentation (if enabled)"
.PHONY: clean
rm -rf $(BUILDDIR)/*
.PHONY: html
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
.PHONY: dirhtml
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
.PHONY: singlehtml
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
.PHONY: pickle
@echo "Build finished; now you can process the pickle files."
.PHONY: json
@echo "Build finished; now you can process the JSON files."
.PHONY: htmlhelp
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
.PHONY: qthelp
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/ESLPlane-WaveDemonstrator.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ESLPlane-WaveDemonstrator.qhc"
.PHONY: applehelp
$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
@echo "N.B. You won't be able to view it unless you put it in" \
"~/Library/Documentation/Help or install it in your application" \
.PHONY: devhelp
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/ESLPlane-WaveDemonstrator"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ESLPlane-WaveDemonstrator"
@echo "# devhelp"
.PHONY: epub
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
.PHONY: latex
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
.PHONY: latexpdf
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
.PHONY: latexpdfja
@echo "Running LaTeX files through platex and dvipdfmx..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
.PHONY: text
@echo "Build finished. The text files are in $(BUILDDIR)/text."
.PHONY: man
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
.PHONY: texinfo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
.PHONY: info
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
.PHONY: gettext
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
.PHONY: changes
@echo "The overview file is in $(BUILDDIR)/changes."
.PHONY: linkcheck
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
.PHONY: doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
.PHONY: coverage
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
@echo "Testing of coverage in the sources finished, look at the " \
"results in $(BUILDDIR)/coverage/python.txt."
.PHONY: xml
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
.PHONY: pseudoxml
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
This diff is collapsed.
This diff is collapsed.
Requirements, Coding Standards, and Best Practices
The ESL aims at providing general, standardised and efficient modules and
libraries for the development of electronic structure codes. To do so, the
modules and libraries included in the ESL must follow a minimum set of
requirements, coding standards, and best practices to ensure that they are
maintainable, useful, and easy to use. Therefore, there was a great deal of
discussions among the community about this issue and a consensus was reached
about such a minimum set that all ESL modules and libraries should follow.
There was however the concern that a very strict set of rules would alienate or
hinder the contributions from volunteers. It was thus decided that this set
should act only as guidelines for volunteer contributions. The situation is,
however, quite different for new modules and libraries to be developed directly
by personnel hired by CECAM or other institutions, as well as for EU-funded
projects like E-CAM, and we believe this set should be mandatory for such
modules and libraries.
This document defines the requirements, coding standards, and best practices of
the new modules developed by the computer scientists hired by CECAM in the
framework of the E-CAM project. They are mandatory to them, while they are only
guidelines for the modules contributed to the ESL by volunteer developers. The
main objective of this document is to guarantee that all newly developed code
will be both attractive to the industry AND usable by researchers.
Within this document, we use the verbs “must” and “should” in the following
- must: if not fulfilled, the corresponding specification will compromise the
future of the ESL;
- should: the corresponding specification is necessary to maintain
compatibility between E-CAM and volunteer contributions, and can be
Programming languages
It is critical that ESL modules be easy to incorporate in codes written within
the electronic structure community. The most widespread language in this
community is Fortran, followed by C and C++. Therefore, all libraries developed
within E-CAM must provide a full C implementation of the API, along with
Fortran 2003 interfaces. Providing Python bindings is highly recommended but
should be implemented only once the C and Fortran implementations are complete.
Exception to this are allowed if the library is meant to be only used from a
specific language. The full language recommendations for ESL contributors can
be found here:
Source code documentation must be managed with Doxygen, in order to support
integration into the ESL automatic documentation system and provide a unified
style with respect to volunteer contributions. Other kinds of documentation are
free-style but must provide a wiki version on and include at
least one tutorial for beginners.
All ESL libraries and modules must be released under an open source license
that allows them to be usable by non open source software. The two most popular
choices for this are BSD and LGPL. There are advantages and disadvantages to
both, which can be quite subtle yet important; in general, BSD is more
permissive, while LGPL ensures that contributions to the library remain open.
We encourage software authors to research and consider which option is most
suitable for them.
The full licensing recommendations for ESL contributors can be found here:
Source-code management
The development of the ESL modules and libraries should be done using Git and
the repository should be set either on or under the
Electronic Structure Library organization, or on a server provided by CECAM
(e.g. Access control and permissions are managed
by the ESL Curators and the E-CAM Infrastructure Managers.
The API of each ESL library must include routines providing information about
both the current version of the library and the version of the API.
Error handling
Libraries must provide informative error handling and always return control to
the parent code. The library should only be allowed to stop the execution in
case there is a clear programming error (e.g., the parent code passed a null
pointer to a function that expects a non-null pointer).
Libraries should, as much as possible, be silent, i.e., not perform I/O
operations at all, except when I/O is precisely the purpose of the library
(e.g. Libescdf, Pspio). All data should therefore be passed in from and out to
the parent code through the API. However, for the larger libraries performing
complex and multi-step tasks this might prove to be extremely impractical, and
a better solution should be sought (and, if necessary, developed within E-CAM).
This must respect the goals set out in the Programming Languages section for
full Fortran and C interoperability.
ESL developers should be aware that the libraries are very likely to be called
from massively parallel codes that often rely on hybrid MPI/OpenMP parallelism.
This fact must be taken into account in the library design and all the ESL
libraries must be thread-safe.
Build systems
In order for the ESL libraries and modules to be easy to compile, portable, and
well integrated with each other, a standard build system type, based on e.g.
the Autotools or CMake, must be used. We recommend the Autotools because the
volunteer developers are more familiar with this framework, but any build
system supporting Fortran is suitable.
.. ESL Plane-Wave Demonstrator documentation master file, created by
sphinx-quickstart on Mon Jul 31 17:35:58 2017.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Welcome to ESL Plane-Wave Demonstrator's documentation!
.. toctree::
:maxdepth: 2
Indices and tables
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`
Markdown is supported
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