From 9d0c7136c9c1b7b045cbede6ba42999e6cf6cb45 Mon Sep 17 00:00:00 2001
From: PRUVOST Florent <florent.pruvost@inria.fr>
Date: Wed, 17 Oct 2018 15:49:04 +0200
Subject: [PATCH] Fix pages and improve the users doc
---
.gitlab-ci.yml | 4 +-
doc/orgmode/CMakeLists.txt | 9 +
doc/orgmode/chapters/installing.org | 168 ++--
doc/orgmode/chapters/introduction.org | 228 ++---
doc/orgmode/chapters/using.org | 5 +-
doc/orgmode/css/VisuGen.css | 208 +++++
doc/orgmode/css/VisuRubriqueEncadre.css | 70 ++
doc/orgmode/css/worg.css | 1038 +++++++++++++++++++++++
doc/orgmode/morse.css | 72 --
doc/orgmode/users_guide.org.in | 6 +-
doc/orgmode/version.org.in | 5 +-
11 files changed, 1541 insertions(+), 272 deletions(-)
create mode 100644 doc/orgmode/css/VisuGen.css
create mode 100644 doc/orgmode/css/VisuRubriqueEncadre.css
create mode 100644 doc/orgmode/css/worg.css
delete mode 100644 doc/orgmode/morse.css
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 954140227..b1dfbfe87 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -312,7 +312,7 @@ pages:
- cd build
- cmake .. -DCHAMELEON_ENABLE_DOC=ON
- make doc -j5
- - mv doc/doxygen ../public/
- - mv doc/orgmode ../public/
+ - mv doc/doxygen/out-dev/html/ ../public/
+ - cp -r doc/orgmode/* ../public/
only:
- master@solverstack/chameleon
diff --git a/doc/orgmode/CMakeLists.txt b/doc/orgmode/CMakeLists.txt
index 0d92f218a..aad5ddff9 100644
--- a/doc/orgmode/CMakeLists.txt
+++ b/doc/orgmode/CMakeLists.txt
@@ -61,6 +61,14 @@ FIND_PROGRAM(EMACS_COMPILER emacs)
FIND_PROGRAM(TEX_COMPILER tex)
if(EMACS_COMPILER)
+
+ # css direcory is required for the html output
+ add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/css
+ COMMAND ${CMAKE_COMMAND} -E copy_directory
+ ${CMAKE_CURRENT_SOURCE_DIR}/css
+ ${CMAKE_CURRENT_BINARY_DIR}/css
+ DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/css)
+
# Add target
# ----------
add_custom_command(OUTPUT users_guide.html
@@ -72,6 +80,7 @@ if(EMACS_COMPILER)
--kill
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/users_guide.org
${CMAKE_CURRENT_BINARY_DIR}/version.org
+ ${CMAKE_CURRENT_BINARY_DIR}/css
)
add_custom_command(OUTPUT users_guide.pdf
COMMAND ${EMACS_COMPILER}
diff --git a/doc/orgmode/chapters/installing.org b/doc/orgmode/chapters/installing.org
index 92e55e8ec..8df8a55cc 100644
--- a/doc/orgmode/chapters/installing.org
+++ b/doc/orgmode/chapters/installing.org
@@ -6,12 +6,12 @@ Chameleon is written in C and depends on a couple of external
libraries that must be installed on the system.
# , it provides an interface to be called from Fortran
-Chameleon can be built and installed by the standard means of [[http://www.cmake.org/][CMake]].
-General information about CMake, as well as installation binaries and
-CMake source code are available from [[http://www.cmake.org/cmake/resources/software.html][here]].
+Chameleon can be built and installed on UNIX systems (Linux) by the standard
+means of [[http://www.cmake.org/][CMake]]. General information about CMake, as well as
+installation binaries and CMake source code are available from [[http://www.cmake.org/cmake/resources/software.html][here]].
To get support to install a full distribution Chameleon + dependencies
-we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
+we encourage users to use [[sec:spack][Spack]].
** Getting Chameleon
@@ -34,26 +34,19 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
- python: to generate files in the different precisions
- external libraries: this depends on the configuration, by default
the required libraries are
- - [[http://runtime.bordeaux.inria.fr/StarPU/][StarPU]]
- - CBLAS, LAPACKE: these are interfaces and there exist several
- providers that can be used with Chameleon
- - Intel MKL, Netlib, OpenBlas
- - BLAS, LAPACK, TMGLIB: there exist several providers that can be
- used with Chameleon
- - Eigen, Intel MKL, Netlib, OpenBlas
- - pthread (libpthread)
- - math (libm)
+ - runtimes: [[http://runtime.bordeaux.inria.fr/StarPU/][StarPU]] or [[http://icl.utk.edu/parsec/][PaRSEC]] or [[http://icl.cs.utk.edu/quark/][QUARK]]
+ - kernels : CBLAS, LAPACKE. These are C interfaces to Fortran
+ kernels BLAS and LAPACK. There exist several providers that can
+ be used with Chameleon (Intel MKL, Netlib, OpenBlas)
Optional libraries:
- - [[http://icl.cs.utk.edu/quark/][quark]]
- - [[https://developer.nvidia.com/cuda-downloads][cuda]]
- - [[http://docs.nvidia.com/cuda/cublas/][cublas]]: comes with cuda
- - mpi: [[http://www.open-mpi.org/][openmpi]]
+ - cuda: [[https://developer.nvidia.com/cuda-downloads][cuda]], [[http://docs.nvidia.com/cuda/cublas/][cublas]] (comes with cuda)
+ - mpi: [[http://www.open-mpi.org/][openmpi]], [[https://www.mpich.org/][mpich]], [[https://software.intel.com/en-us/mpi-library][intelmpi]]
These packages must be installed on the system before trying to
configure/build chameleon. Please look at the distrib/ directory
- which gives some hints for the installation of dependencies for Unix
- systems.
+ which gives some hints for the installation of dependencies for
+ Unix systems.
We give here some examples for a Debian system:
#+begin_src
@@ -76,27 +69,35 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
# Install StarPU (with MPI and FxT enabled)
mkdir -p $HOME/install
cd $HOME/install
- wget http://starpu.gforge.inria.fr/files/starpu-1.2.2/starpu-1.2.2.tar.gz
- tar xvzf starpu-1.2.2.tar.gz
- cd starpu-1.2.2/
- ./configure --prefix=$HOME/install/starpu --disable-opencl --disable-cuda --with-fxt=/usr/lib/x86_64-linux-gnu/
- make
- make install
+ wget http://starpu.gforge.inria.fr/files/starpu-1.2.6/starpu-1.2.6.tar.gz
+ tar xvzf starpu-1.2.6.tar.gz
+ cd starpu-1.2.6/
+ ./configure --prefix=/usr/local --with-fxt=/usr/lib/x86_64-linux-gnu/
+ make -j5
+ sudo make install
+
+ # Install PaRSEC: to be used in place of StarPU
+ mkdir -p $HOME/install
cd $HOME/install
- rm starpu-1.2.2/ starpu-1.2.2.tar.gz -rf
+ git clone https://bitbucket.org/mfaverge/parsec.git
+ cd parsec
+ git checkout mymaster
+ git submodule update
+ mkdir -p build
+ cd build
+ cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local -DBUILD_SHARED_LIBS=ON
+ make -j5
+ sudo make install
# Install QUARK: to be used in place of StarPU
mkdir -p $HOME/install
cd $HOME/install
- wget http://icl.cs.utk.edu/projectsfiles/quark/pubs/quark-0.9.0.tgz
- tar xvzf quark-0.9.0.tgz
- cd quark-0.9.0/
- sed -i -e "s#prefix=\.\/install#prefix=$HOME/install/quark#g" make.inc
- sed -i -e "s#CFLAGS=-O2#CFLAGS=-O2 -fPIC#g" make.inc
+ git clone https://github.com/ecrc/quark
+ cd quark/
+ sed -i -e "s#prefix=.*#prefix=/usr/local#g" make.inc
+ sed -i -e "s#CFLAGS=.*#CFLAGS= -O2 -DADD_ -fPIC#g" make.inc
make
- make install
- cd $HOME/install
- rm quark-0.9.0/ quark-0.9.0.tgz -rf
+ sudo make install
#+end_src
@@ -161,20 +162,6 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
*Caution about the compatibility:* Chameleon has been mainly tested
with the reference TMGLIB from NETLIB, OpenBLAS and Intel MKL.
-**** QUARK
- [[http://icl.cs.utk.edu/quark/][QUARK]] (QUeuing And Runtime for Kernels) provides a library that
- enables the dynamic execution of tasks with data dependencies in
- a multi-core, multi-socket, shared-memory environment. One of
- QUARK or StarPU Runtime systems has to be enabled in order to
- schedule tasks on the architecture. If QUARK is enabled then
- StarPU is disabled and conversely. Note StarPU is enabled by
- default. When Chameleon is linked with QUARK, it is not possible
- to exploit neither CUDA (for GPUs) nor MPI (distributed-memory
- environment). You can use StarPU to do so.
-
- *Caution about the compatibility:* Chameleon has been mainly tested
- with the QUARK library 0.9.
-
**** StarPU
[[http://runtime.bordeaux.inria.fr/StarPU/][StarPU]] is a task programming library for hybrid architectures.
StarPU handles run-time concerns such as:
@@ -185,14 +172,31 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
* Optimized cluster communications
StarPU can be used to benefit from GPUs and distributed-memory
- environment. One of QUARK or StarPU runtime system has to be
- enabled in order to schedule tasks on the architecture. If
- StarPU is enabled then QUARK is disabled and conversely. Note
- StarPU is enabled by default.
+ environment. Note StarPU is enabled by default.
*Caution about the compatibility:* Chameleon has been mainly tested
with StarPU-1.1 and 1.2 releases.
+**** PaRSEC
+ [[http://icl.utk.edu/parsec/][PaRSEC]] is a generic framework for architecture aware scheduling
+ and management of micro-tasks on distributed many-core
+ heterogeneous architectures. It can be used with MPI and Cuda.
+
+ *Caution about the compatibility:* Chameleon is compatible with
+ this version
+ https://bitbucket.org/mfaverge/parsec/branch/mymaster.
+
+**** QUARK
+ [[http://icl.cs.utk.edu/quark/][QUARK]] (QUeuing And Runtime for Kernels) provides a library that
+ enables the dynamic execution of tasks with data dependencies in
+ a multi-core, multi-socket, shared-memory environment. When
+ Chameleon is linked with QUARK, it is not possible to exploit
+ neither CUDA (for GPUs) nor MPI (distributed-memory environment).
+ You can use PaRSEC or StarPU to do so.
+
+ *Caution about the compatibility:* Chameleon has been mainly tested
+ with the QUARK library coming from https://github.com/ecrc/quark.
+
**** FxT
[[http://download.savannah.gnu.org/releases/fkt/][FxT]] stands for both FKT (Fast Kernel Tracing) and FUT (Fast User
Tracing). This library provides efficient support for recording
@@ -209,16 +213,14 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
[[http://www.open-mpi.org/projects/hwloc/][hwloc]] (Portable Hardware Locality) is a software package for
accessing the topology of a multicore system including components
like: cores, sockets, caches and NUMA nodes. The topology
- discovery library, ~hwloc~, is not mandatory to use StarPU but
- strongly recommended. It allows to increase performance, and to
- perform some topology aware scheduling. ~hwloc~ is available in
- major distributions and for most OSes and can be downloaded from
- http://www.open-mpi.org/software/hwloc.
-
-**** pthread
- POSIX threads library is required to run Chameleon on Unix-like systems.
- It is a standard component of any such system.
-
+ discovery library, ~hwloc~, is strongly recommended to be used
+ through the runtime system. It allows to increase performance,
+ and to perform some topology aware scheduling. ~hwloc~ is available
+ in major distributions and for most OSes and can be downloaded
+ from http://www.open-mpi.org/software/hwloc.
+
+ *Caution about the compatibility:* hwlov should be compatible with
+ the runtime system used.
**** OpenMPI
[[http://www.open-mpi.org/][OpenMPI]] is an open source Message Passing Interface
implementation for execution on multiple nodes with
@@ -249,16 +251,16 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
<<sec:spack>>
To get support to install a full distribution (Chameleon +
- dependencies) we encourage users to use the morse branch of *Spack*.
-
- Please read these documentations:
- * [[http://morse.gforge.inria.fr/spack/spack.html][Spack Cham]]
- * [[http://morse.gforge.inria.fr/spack/spack.html#orgd5b1afe][Section Chameleon]]
+ dependencies) we encourage users to use *Spack*. Please refer to our
+ [[https://gitlab.inria.fr/solverstack/spack-repo/blob/master/README.org][Spack Repository]].
*** Usage example for a simple distribution of Chameleon
#+begin_src sh
- git clone https://github.com/solverstack/spack.git
- . ./spack/share/spack/setup-env.sh
+ git clone https://github.com/llnl/spack.git
+ export SPACK_ROOT=$PWD/spack
+ . $SPACK_ROOT/share/spack/setup-env.sh
+ git clone https://gitlab.inria.fr/solverstack/spack-repo.git
+ spack repo add spack-repo
spack install -v chameleon
# chameleon is installed here:
`spack location -i chameleon`
@@ -267,7 +269,7 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
** Build and install Chameleon with CMake
Compilation of Chameleon libraries and executables are done with
CMake (http://www.cmake.org/). This version has been tested with
- CMake 3.5.1 but any version superior to 2.8 should be fine.
+ CMake 3.10.2 but any version superior to 2.8 should be fine.
Here the steps to configure, build, test and install
1. configure:
@@ -343,8 +345,8 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
[[sec:depdet][Dependencies detection]]
* *STARPU_LIBDIR=path/to/root/starpu/install/libs*, see
[[sec:depdet][Dependencies detection]]
- * List of packages that can searched just like STARPU (with _DIR,
- _INCDIR and _LIBDIR):
+ * List of packages that can be searched just like STARPU (with
+ _DIR, _INCDIR and _LIBDIR):
* *BLAS*, *CBLAS*, *EZTRACE*, *FXT*, *HWLOC*, *LAPACK*, *LAPACKE*, *QUARK*,
*SIMGRID*, *TMG*
@@ -359,15 +361,18 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
**** Chameleon specific options
* *CHAMELEON_SCHED_STARPU=ON|OFF* (default ON): to link with
StarPU library (runtime system)
+ * *CHAMELEON_SCHED_PARSEC=ON|OFF* (default OFF): to link with
+ PARSEC library (runtime system)
* *CHAMELEON_SCHED_QUARK=ON|OFF* (default OFF): to link with QUARK
library (runtime system)
* *CHAMELEON_USE_MPI=ON|OFF* (default OFF): to link with MPI
library (message passing implementation for use of multiple
nodes with distributed memory), can only be used with StarPU
+ and PaRSEC
* *CHAMELEON_USE_CUDA=ON|OFF* (default OFF): to link with CUDA
runtime (implementation paradigm for accelerated codes on GPUs)
and cuBLAS library (optimized BLAS kernels on GPUs), can only
- be used with StarPU
+ be used with StarPU and PaRSEC
* *CHAMELEON_ENABLE_DOC=ON|OFF* (default OFF): to control build of
the documentation contained in doc/ sub-directory
* *CHAMELEON_ENABLE_EXAMPLE=ON|OFF* (default ON): to control build
@@ -403,8 +408,8 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
configure. Different cases:
1) detection of dependencies through environment variables:
- - LD_LIBRARY_PATH should contain the list of paths where to find
- the libraries:
+ - LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on Mac OSX) should contain
+ the list of paths where to find the libraries:
#+begin_src
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:install/path/to/your/lib
#+end_src
@@ -414,9 +419,11 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
export INCLUDE=$INCLUDE:install/path/to/your/headers
#+end_src
2) detection with user's given paths:
- - you can specify the path at cmake configure by invoking ~cmake
- path/to/your/CMakeLists.txt -DLIB_DIR=path/to/your/lib~ where
- LIB stands for the name of the lib to look for
+ - you can specify the path at cmake configure by invoking
+ #+begin_example
+ cmake path/to/your/CMakeLists.txt -DLIB_DIR=path/to/your/lib
+ #+end_example
+ where LIB stands for the name of the lib to look for, /e.g./
#+begin_src
cmake path/to/your/CMakeLists.txt -DSTARPU_DIR=path/to/starpudir \
-DCBLAS_DIR= ...
@@ -424,8 +431,9 @@ we encourage users to use the /morse/ branch of [[sec:spack][Spack]].
it is also possible to specify headers and library directories
separately
#+begin_src
- cmake path/to/your/CMakeLists.txt -DSTARPU_INCDIR=path/to/libstarpu/include/starpu/1.1 \
- -DSTARPU_LIBDIR=path/to/libstarpu/lib
+ cmake path/to/your/CMakeLists.txt \
+ -DSTARPU_INCDIR=path/to/libstarpu/include/starpu/1.1 \
+ -DSTARPU_LIBDIR=path/to/libstarpu/lib
#+end_src
- note: BLAS and LAPACK detection can be tedious so that we
provide a verbose mode you can set *-DBLAS_VERBOSE=ON* or
diff --git a/doc/orgmode/chapters/introduction.org b/doc/orgmode/chapters/introduction.org
index 0341d5f23..ba95de2cd 100644
--- a/doc/orgmode/chapters/introduction.org
+++ b/doc/orgmode/chapters/introduction.org
@@ -1,16 +1,16 @@
# This file is part of the Chameleon User's Guide.
-# Copyright (C) 2017 Inria
+# Copyright (C) 2018 Inria
# See the file ../users_guide.org for copying conditions.
-** CHAMELEON project
+** MORSE project
#+NAME: fig:chameleon_header
#+ATTR_HTML: :align center
[[file:chameleon_header.png]]
Chameleon is a linear algebra software created jointly by several
- research teams as part of the CHAMELEON associate team: [[http://www.icl.utk.edu/][ICL]], [[https://www.inria.fr/en/][Inria]],
+ research teams as part of the MORSE associate team: [[http://www.icl.utk.edu/][ICL]], [[https://www.inria.fr/en/][Inria]],
[[https://www.kaust.edu.sa/en][KAUST]], [[http://www.ucdenver.edu/pages/ucdwelcomepage.aspx][The University of Colorado Denver]].
-*** CHAMELEON Objectives
+*** MORSE Objectives
When processor clock speeds flatlined in 2004, after more than
fifteen years of exponential increases, the era of near automatic
performance improvements that the HPC application community had
@@ -30,19 +30,19 @@
5) new levels of self-adaptivity will be required to enable
software to modulate process speed in order to satisfy limited
energy budgets.
- The CHAMELEON associate team will tackle the first three challenges in
+ The MORSE associate team will tackle the first three challenges in
a orchestrating work between research groups respectively
specialized in sparse linear algebra, dense linear algebra and
- runtime systems. The overall objective is to develop robust linear
- algebra libraries relying on innovative runtime systems that can
- fully benefit from the potential of those future large-scale
- complex machines. Challenges 4) and 5) will also be investigated
- by the different teams in the context of other partnerships, but
- they will not be the main focus of the associate team as they are
- much more prospective.
+ runtime systems. The overall objective is to develop robust
+ linear algebra libraries relying on innovative runtime systems
+ that can fully benefit from the potential of those future
+ large-scale complex machines. Challenges 4) and 5) will also be
+ investigated by the different teams in the context of other
+ partnerships, but they will not be the main focus of the associate
+ team as they are much more prospective.
*** Research fields
- The overall goal of the CHAMELEON associate team is to enable advanced
+ The overall goal of the MORSE associate team is to enable advanced
numerical algorithms to be executed on a scalable unified runtime
system for exploiting the full potential of future exascale
machines. We expect advances in three directions based first on
@@ -62,14 +62,15 @@
productivity and expressivity. As mentioned in the next section,
a widely used approach consists in abstracting the application as
a DAG that the runtime system is in charge of scheduling.
- Scheduling such a DAG over a set of heterogeneous processing units
- introduces a lot of new challenges, such as predicting accurately
- the execution time of each type of task over each kind of unit,
- minimizing data transfers between memory banks, performing data
- prefetching, etc. Expected advances: In a nutshell, a new runtime
- system API will be designed to allow applications to provide
- scheduling hints to the runtime system and to get real-time
- feedback about the consequences of scheduling decisions.
+ Scheduling such a DAG over a set of heterogeneous processing
+ units introduces a lot of new challenges, such as predicting
+ accurately the execution time of each type of task over each kind
+ of unit, minimizing data transfers between memory banks,
+ performing data prefetching, etc. Expected advances: In a
+ nutshell, a new runtime system API will be designed to allow
+ applications to provide scheduling hints to the runtime system
+ and to get real-time feedback about the consequences of
+ scheduling decisions.
**** Runtime systems
A runtime environment is an intermediate layer between the system
@@ -80,14 +81,14 @@
the scalability of runtime environment. To achieve scalability it
is required to avoid all centralization. Here, the main problem
is the scheduling of the tasks. In many task-based runtime
- environments the scheduler is centralized and becomes a bottleneck
- as soon as too many cores are involved. It is therefore required
- to distribute the scheduling decision or to compute a data
- distribution that impose the mapping of task using, for instance
- the so-called ``owner-compute'' rule. Expected advances: We will
- design runtime systems that enable an efficient and scalable use
- of thousands of distributed multicore nodes enhanced with
- accelerators.
+ environments the scheduler is centralized and becomes a
+ bottleneck as soon as too many cores are involved. It is
+ therefore required to distribute the scheduling decision or to
+ compute a data distribution that impose the mapping of task
+ using, for instance the so-called ``owner-compute'' rule.
+ Expected advances: We will design runtime systems that enable an
+ efficient and scalable use of thousands of distributed multicore
+ nodes enhanced with accelerators.
**** Linear algebra
Because of its central position in HPC and of the well understood
@@ -111,36 +112,38 @@
promising approach.
*** Research papers
- Research papers about CHAMELEON can be found [[http://icl.cs.utk.edu/projectsdev/morse/pubs/index.html][here]].
+ Research papers about MORSE can be found [[http://icl.cs.utk.edu/projectsdev/morse/pubs/index.html][here]].
** Chameleon
*** Chameleon software
The main purpose is to address the performance shortcomings of the
[[http://www.netlib.org/lapack/][LAPACK]] and [[http://www.netlib.org/scalapack/][ScaLAPACK]] libraries on multicore processors and
- multi-socket systems of multicore processors and their inability to
- efficiently utilize accelerators such as Graphics Processing Units
- (GPUs).
+ multi-socket systems of multicore processors and their inability
+ to efficiently utilize accelerators such as Graphics Processing
+ Units (GPUs).
Chameleon is a framework written in C which provides routines to
- solve dense general systems of linear equations, symmetric positive
- definite systems of linear equations and linear least squares
- problems, using LU, Cholesky, QR and LQ factorizations. Real
- arithmetic and complex arithmetic are supported in both single
- precision and double precision. It supports Linux and Mac OS/X
- machines (only tested on Intel x86-64 architecture).
+ solve dense general systems of linear equations, symmetric
+ positive definite systems of linear equations and linear least
+ squares problems, using LU, Cholesky, QR and LQ factorizations.
+ Real arithmetic and complex arithmetic are supported in both
+ single precision and double precision. It supports Linux and Mac
+ OS/X machines (mainly tested on Intel x86-64 and IBM Power
+ architectures).
- Chameleon is based on [[http://icl.cs.utk.edu/plasma/][PLASMA]] source code but is not limited to
- shared-memory environment and can exploit multiple GPUs. Chameleon
- is interfaced in a generic way with both [[http://icl.cs.utk.edu/quark/][QUARK]] and [[http://runtime.bordeaux.inria.fr/StarPU/][StarPU]] runtime
- systems. This feature allows to analyze in a unified framework how
- sequential task-based algorithms behave regarding different runtime
- systems implementations. Using Chameleon with [[http://runtime.bordeaux.inria.fr/StarPU/][StarPU]] runtime
- system allows to exploit GPUs through kernels provided by [[https://developer.nvidia.com/cublas][cuBLAS]]
- and clusters of interconnected nodes with distributed memory (using
- [[http://www.open-mpi.org/][MPI]]). Computation of very large systems with dense matrices on a
- cluster of nodes is still being experimented and stabilized. It is
- not expected to get stable performances with the current version
- using MPI.
+ Chameleon is based on the [[http://icl.cs.utk.edu/plasma/][PLASMA]] source code but is not limited to
+ shared-memory environment and can exploit multiple GPUs.
+ Chameleon is interfaced in a generic way with [[http://runtime.bordeaux.inria.fr/StarPU/][StarPU]], [[http://icl.utk.edu/parsec/][PaRSEC]],
+ [[http://icl.cs.utk.edu/quark/][QUARK]] runtime systems. This feature allows to analyze in a
+ unified framework how sequential task-based algorithms behave
+ regarding different runtime systems implementations. Using
+ Chameleon with *StarPU* or *PaRSEC* runtime systems allows to exploit
+ GPUs through kernels provided by [[https://developer.nvidia.com/cublas][cuBLAS]] and clusters of
+ interconnected nodes with distributed memory (using [[http://www.open-mpi.org/][MPI]]).
+ Computation of very large systems with dense matrices on a cluster
+ of nodes is still being experimented and stabilized. It is not
+ expected to get stable performances with the current version using
+ MPI.
*** PLASMA's design principles
Chameleon is originally based on [[http://icl.cs.utk.edu/plasma/][PLASMA]] so that design principles
@@ -163,18 +166,18 @@
factorization, translating the classic algorithm to the tile
algorithm is trivial. In the case of matrix multiplication, the
tile algorithm is simply a product of applying the technique of
- *loop tiling* to the canonical definition of three nested loops. It
- is very similar for the Cholesky factorization. The *left-looking*
- definition of Cholesky factorization from LAPACK is a loop with a
- sequence of calls to four routines: xSYRK (symmetric *rank-k*
- update), xPOTRF (Cholesky factorization of a small block on the
- diagonal), xGEMM (matrix multiplication) and xTRSM (triangular
- solve). If the xSYRK, xGEMM and xTRSM operations are expressed
- with the canonical definition of three nested loops and the
- technique of loop tiling is applied, the tile algorithm results.
- Since the algorithm is produced by simple reordering of
- operations, neither the number of operations nor numerical
- stability of the algorithm are affected.
+ *loop tiling* to the canonical definition of three nested loops.
+ It is very similar for the Cholesky factorization. The
+ *left-looking* definition of Cholesky factorization from LAPACK is
+ a loop with a sequence of calls to four routines: xSYRK
+ (symmetric *rank-k* update), xPOTRF (Cholesky factorization of a
+ small block on the diagonal), xGEMM (matrix multiplication) and
+ xTRSM (triangular solve). If the xSYRK, xGEMM and xTRSM
+ operations are expressed with the canonical definition of three
+ nested loops and the technique of loop tiling is applied, the
+ tile algorithm results. Since the algorithm is produced by
+ simple reordering of operations, neither the number of operations
+ nor numerical stability of the algorithm are affected.
The situation becomes slightly more complicated for LU and QR
factorizations, where the classic algorithms factorize an entire
@@ -184,17 +187,17 @@
places and a tile algorithm can be fought of as one that zeroes
one tile of the matrix at a time. This process is referred to as
updating of a factorization or *incremental factorization*. The
- process is equivalent to factorizing the top tile of a panel, then
- placing the upper triangle of the result on top of the tile blow
- and factorizing again, then moving to the next tile and so on.
- Here, the tile LU and QR algorithms perform slightly more floating
- point operations and require slightly more memory for auxiliary
- data. Also, the tile LU factorization applies a different
- pivoting pattern and, as a result, is less numerically stable than
- classic LU with full pivoting. Numerical stability is not an
- issue in case of the tile QR, which relies on orthogonal
- transformations (Householder reflections), which are numerically
- stable.
+ process is equivalent to factorizing the top tile of a panel,
+ then placing the upper triangle of the result on top of the tile
+ blow and factorizing again, then moving to the next tile and so
+ on. Here, the tile LU and QR algorithms perform slightly more
+ floating point operations and require slightly more memory for
+ auxiliary data. Also, the tile LU factorization applies a
+ different pivoting pattern and, as a result, is less numerically
+ stable than classic LU with full pivoting. Numerical stability
+ is not an issue in case of the tile QR, which relies on
+ orthogonal transformations (Householder reflections), which are
+ numerically stable.
#+CAPTION: Schematic illustration of the tile LU factorization (kernel names for real arithmetics in double precision), courtesey of the [[http://icl.cs.utk.edu/plasma/][PLASMA]] team.
#+NAME: fig:tile_lu
@@ -212,11 +215,11 @@
the three types of cache misses, *compulsory*, *capacity* and
*conflict*, the use of tile layout minimizes the number of conflict
misses, since a continuous region of memory will completely fill
- out a /set-associative/ cache memory before an eviction can
- happen. Also, from the standpoint of multithreaded execution, the
- probability of *false sharing* is minimized. It can only
- affect the cache lines containing the beginning and the ending of
- a tile.
+ out a /set-associative/ cache memory before an eviction can happen.
+ Also, from the standpoint of multithreaded execution, the
+ probability of *false sharing* is minimized. It can only affect
+ the cache lines containing the beginning and the ending of a
+ tile.
In standard *cache-based* architecture, tiles continously laid out
in memory maximize the profit from automatic prefetching. Tile
@@ -236,17 +239,16 @@
Another property of the layout utilized in PLASMA is that it is
``flat'', meaning that it does not involve a level of
- indirection. Each tile stores a small square submatrix of the main
- matrix in a *column-major* layout. In turn, the main matrix is an
- arrangement of tiles immediately following one another in a
+ indirection. Each tile stores a small square submatrix of the
+ main matrix in a *column-major* layout. In turn, the main matrix is
+ an arrangement of tiles immediately following one another in a
*column-major* layout. The offset of each tile can be calculated
through address arithmetics and does not involve pointer
indirection. Alternatively, a matrix could be represented as an
array of pointers to tiles, located anywhere in memory. Such
layout would be a radical and unjustifiable departure from LAPACK
and ScaLAPACK. Flat tile layout is a natural progression from
- LAPACK's *column-major* layout and ScaLAPACK's
- /block-cyclic/ layout.
+ LAPACK's *column-major* layout and ScaLAPACK's /block-cyclic/ layout.
Another related property of PLASMA's tile layout is that it
includes provisions for padding of tiles, i.e., the actual region
@@ -256,9 +258,9 @@
described in the previous paragraph. The motivation is that, at
the price of small memory overhead, alignment of tile boundaries
may prove benefivial in multiple scenarios involving memory
- systems of standard multicore processors, as well as accelerators.
- The issues that come into play are, again, the use of TLBs and
- memory banks or partitions.
+ systems of standard multicore processors, as well as
+ accelerators. The issues that come into play are, again, the use
+ of TLBs and memory banks or partitions.
#+CAPTION: Schematic illustration of the tile layout with *column-major* order of tiles, *column-major* order of elements within tiles and (optional) padding for enforcing a certain alighment of tile bondaries, courtesey of the [[http://icl.cs.utk.edu/plasma/][PLASMA]] team.
#+NAME: fig:tile_layout
@@ -267,26 +269,26 @@
**** Dynamic Task Scheduling
- Dynamic scheduling is the idea of assigning work to cores based on
- the availability of data for processing at any given point in time
- and is also referred to as *data-driven* scheduling. The concept is
- related closely to the idea of expressing computation through a
- task graph, often referred to as the DAG (*Direct Acyclic Graph*),
- and the flexibility exploring the DAG at runtime. Thus, to a
- large extent, dynamic scheduling is synonymous with *runtime
- scheduling*. An important concept here is the one of the *critical
- path*, which defines the upper bound on the achievable parallelism,
- and needs to be pursued at the maximum speed. This is in direct
- opposition to the *fork-and-join* or *data-parallel* programming
- models, where artificial synchronization points expose serial
- sections of the code, where multiple cores are idle, while
- sequential processing takes place. The use of dynamic scheduling
- introduces a *trade-off*, though. The more dynamic (flexible)
- scheduling is, the more centralized (and less scalable) the
- scheduling mechanism is. For that reason, currently PLASMA uses
- two scheduling mechanisms, one which is fully dynamic and one
- where work is assigned statically and dependency checks are done
- at runtime.
+ Dynamic scheduling is the idea of assigning work to cores based
+ on the availability of data for processing at any given point in
+ time and is also referred to as *data-driven* scheduling. The
+ concept is related closely to the idea of expressing computation
+ through a task graph, often referred to as the DAG (*Direct
+ Acyclic Graph*), and the flexibility exploring the DAG at runtime.
+ Thus, to a large extent, dynamic scheduling is synonymous with
+ *runtime scheduling*. An important concept here is the one of
+ the *critical path*, which defines the upper bound on the
+ achievable parallelism, and needs to be pursued at the maximum
+ speed. This is in direct opposition to the *fork-and-join* or
+ *data-parallel* programming models, where artificial
+ synchronization points expose serial sections of the code, where
+ multiple cores are idle, while sequential processing takes place.
+ The use of dynamic scheduling introduces a *trade-off*, though.
+ The more dynamic (flexible) scheduling is, the more centralized
+ (and less scalable) the scheduling mechanism is. For that
+ reason, currently PLASMA uses two scheduling mechanisms, one
+ which is fully dynamic and one where work is assigned statically
+ and dependency checks are done at runtime.
The first scheduling mechanism relies on unfolding a *sliding
window* of the task graph at runtime and scheduling work by
@@ -294,13 +296,13 @@
(WAR)* and *Write After Write (WAW)*, a technique analogous to
instruction scheduling in superscalar processors. It also relies
on *work-stealing* for balanding the load among all multiple cores.
- The second scheduling mechanism relies on statically designating a
- path through the execution space of the algorithm to each core and
- following a cycle: transition to a task, wait for its
+ The second scheduling mechanism relies on statically designating
+ a path through the execution space of the algorithm to each core
+ and following a cycle: transition to a task, wait for its
dependencies, execute it, update the overall progress. Task are
- identified by tuples and task transitions are done through locally
- evaluated formulas. Progress information can be centralized,
- replicated or distributed (currently centralized).
+ identified by tuples and task transitions are done through
+ locally evaluated formulas. Progress information can be
+ centralized, replicated or distributed (currently centralized).
#+CAPTION: A trace of the tile QR factorization executing on eight cores without any global synchronization points (kernel names for real arithmetics in single precision), courtesey of the [[http://icl.cs.utk.edu/plasma/][PLASMA]] team.
#+NAME: fig:trace_qr
diff --git a/doc/orgmode/chapters/using.org b/doc/orgmode/chapters/using.org
index a65fd0597..eb4c9cdc6 100644
--- a/doc/orgmode/chapters/using.org
+++ b/doc/orgmode/chapters/using.org
@@ -362,7 +362,7 @@
exist default values for options.
For all steps, the program solves a linear system $Ax=B$ The
- matrix values are randomly generated but ensure that matrix \$A\$ is
+ matrix values are randomly generated but ensure that matrix $A$ is
symmetric positive definite so that $A$ can be factorized in a
$LL^T$ form using the Cholesky factorization.
@@ -746,7 +746,8 @@
The new function to understand is *CHAMELEON_dbuild_Tile*, e.g.
#+begin_example
struct data_pl data_A={(double)N, 51, N};
- CHAMELEON_dbuild_Tile(ChamUpperLower, descA, (void*)&data_A, Cham_build_callback_plgsy);
+ CHAMELEON_dbuild_Tile(ChamUpperLower, descA, (void*)&data_A,
+ Cham_build_callback_plgsy);
#+end_example
The idea here is to let Chameleon fill the matrix data in a
diff --git a/doc/orgmode/css/VisuGen.css b/doc/orgmode/css/VisuGen.css
new file mode 100644
index 000000000..e446f1f54
--- /dev/null
+++ b/doc/orgmode/css/VisuGen.css
@@ -0,0 +1,208 @@
+HTML, BODY, A, TABLE, TR, TD, FORM, INPUT, SELECT, TEXTAREA, DIV, P, SPAN, H1, H2, H3, H4, H5, B, UL, LI, DD, DL, DT {
+
+ font-family: sans-serif, Times, "Times New Roman";
+
+}
+
+BODY {
+ margin: auto;
+ border: 0px;
+ padding: 0px;
+ background-color: rgb(250, 250, 250);
+ color: black;
+ font-size: 14px;
+}
+
+/* classe css de la page*/
+#res_script{
+ border:0px solid black;
+ width:99%;
+ font-size:1.2em;
+ text-align:left;
+ color:black;
+ background-color:white;
+}
+
+/* Titre avec le résumé de la requete, le nb de publis, ...*/
+div.ZoneTitreResultat
+{
+ padding-left:10px;
+ width:95%;
+}
+.TitreResultats{
+ color:#363842;
+ font-size: 1.4em;
+ font-weight: bold;
+}
+.SousTitreResultats {
+ margin: 0px 0px 40px;
+ font-size: 1.1em;
+ color:#363842;
+ }
+/* Zone pour afficher un message d'erreur*/
+div.ZoneTitreErreur
+{
+ padding-left:10px;
+ width:95%;
+}
+ /*Libelle du nombre de publications affichées*/
+.LibelleNbPubli {
+ margin: 0px 0px 40px;
+ font-size: 1.1em;
+ color:#363842;
+ font-weight: bold;
+}
+ /*valeur du nombre de publications affichées*/
+.ValeurNbPubli {
+ margin: 0px 0px 40px;
+ font-size: 1.1em;
+ color:#363842;
+ }
+
+/* classes pour les rubriques pour certains type de classement (type de publi, année de publi) */
+.Rubrique{
+ border: 0;
+ color:#58529f;
+ margin-left:0.2em;
+ margin-bottom:0.2em;
+ font-weight:bold;
+ font-size:1.4em;
+}
+.SousRubrique{
+ color:#58529f;
+ font-weight:bold;
+ margin-left:0.4em;
+ font-size:1.2em;
+}
+
+/* Classe le dl qui contient chaque publication */
+.NoticeRes {
+ border: 0;
+ padding-bottom: 0.5em;
+ margin:0 0 1em;
+}
+.NoticeResAvecVignette {
+ border: 0;
+ padding-bottom: 0.5em;
+ min-height:100px;
+}
+
+/*classe dt qui permmettent d'afficher les noms des champs */
+.ChampRes {
+ clear:both;
+ float:left;
+ text-align:left;
+ font-size:0.9em;
+ font-weight:bold;
+ width: 23%;
+ margin-left:1em;
+ margin-bottom: 0em;
+ margin-top: 0em;
+ padding: 0em;
+}
+.ChampResAvecVignette {
+ display:none;
+width: 15%;
+ text-align:left;
+ font-size:0.9em;
+ color:#58529F;
+ font-weight:bold;
+ margin-bottom: 0em;
+ margin-top: 0em;
+ padding: 0em;
+ margin-left:120px;
+}
+
+
+/* classes dd pour l'affichage de la valeur des champs
+/* Nom du champ : titre, auteur, detail, acces au texte integral...
+ - pratique pour connaitre le nom du champ et la classe css associée
+ - ne fonctionne pas si on affiche les vignettes */
+
+/* Classe commune à tous les champs affichés */
+.ValeurRes {
+ margin-left:25%;
+ margin-bottom: 0em;
+ margin-top: 0em;
+ padding: 0em;
+ text-align:left;
+ font-size: 0.9em;
+ font-size: 1em;
+}
+.ValeurRes a{
+ color:black;
+ text-decoration:underline;
+ font-size: 1em;
+}
+/* quand il y a affichage de vignette */
+.ValeurResAvecVignette {
+ margin-left:120px;
+ margin-bottom: 0em;
+ margin-top: 0em;
+ padding: 0em;
+ text-align:left;
+ font-size: 0.9em;
+ font-size: 1em;
+}
+.ValeurResAvecVignette a{
+ color:black;
+ text-decoration:underline;
+ font-size: 1em;
+}
+
+
+/* classe pour les auteurs */
+.Auteurs {
+}
+/* classe pour les titres */
+.Titre {
+ font-weight:bold;
+}
+/* classe pour les identifiants */
+.Identifiant {
+}
+/* classe des détails de publication : une classe par type */
+.detail_revue,.detail_conf,.detail_cours,.detail_ouv,.detail_hdr,.detail_these,.detail_autre,.detail_brevet,.detail_rapport,.detail_sans_ref{
+}
+/* classe pour les doi */
+.DOI{
+}
+/* classe pour les résumés */
+.Debut_du_resume{
+}
+/* classe pour le type de document */
+.Type_de_document{
+}
+/* classe pour l'audience */
+.Audience{
+}
+/* affichage des vignettes*/
+.Vignette {
+ float: left;
+ clear:left;
+ padding-right:0em;
+ margin-left:0.5em;
+ }
+.VignetteImg {
+ width: auto;
+ height: auto;
+}
+
+/*affichage des fichiers joints*/
+.Fichier_joint a{
+ text-decoration:none;
+}
+
+/*lien vers le bibtex*/
+.LienBibtex{
+}
+.LienBibtexACoteFulltext{
+margin-left:1em;
+}
+/*mois de la conférence*/
+.MoisConf{
+}
+
+.ref_biblio_hal a{
+ text-decoration:none;
+}
diff --git a/doc/orgmode/css/VisuRubriqueEncadre.css b/doc/orgmode/css/VisuRubriqueEncadre.css
new file mode 100644
index 000000000..022ce8d7f
--- /dev/null
+++ b/doc/orgmode/css/VisuRubriqueEncadre.css
@@ -0,0 +1,70 @@
+
+/* classe css de la page*/
+#res_script{
+ border:0;
+ background-color:white;
+ color:black;
+}
+
+/*Titre*/
+div.ZoneTitreResultat
+{
+ display:none;
+}
+/* classe pour les rubriques pour certains type de classement (type de publi, année de publi) */
+.Rubrique{
+/* position: relative;*/
+ font-size:x-large;
+ color:#446;
+ letter-spacing:2px;
+ font-weight:bold;
+ background:#CCC;
+ text-align:left;
+ border: solid 1px #558;
+ padding: 3px 0px 2px 10px;
+ margin-top: 5px;
+ margin-bottom: 12px;
+}
+.SousRubrique{
+ font-weight:bold;
+ margin-left:10px;
+ font-size:1.3em;
+}
+
+
+/*nom du champ*/
+.ChampRes {
+ display:none;
+}
+
+/* classe commune à tous les champs affichés */
+.ValeurRes {
+ color:black;
+ margin-left:1em;
+}
+/* classe pour les auteurs */
+.Auteurs {
+}
+/* classe pour les titres */
+.Titre, .Titre a {
+ font-weight:bold;
+ color:#58529F;
+}
+/* classe pour les identifiants */
+.Identifiant {
+}
+/* classe des détails de publication : une classe par type */
+.detail_revue,.detail_conf,.detail_cours,.detail_ouv,.detail_hdr,.detail_these,.detail_autre,.detail_brevet,.detail_rapport,.detail_sans_ref{
+}
+/* classe pour les doi */
+.DOI{
+}
+/* classe pour les résumés */
+.Debut_du_resume{
+}
+/* classe pour le type de document */
+.Type_de_document{
+}
+/* classe pour l'audience */
+.Audience{
+}
diff --git a/doc/orgmode/css/worg.css b/doc/orgmode/css/worg.css
new file mode 100644
index 000000000..034fb09f5
--- /dev/null
+++ b/doc/orgmode/css/worg.css
@@ -0,0 +1,1038 @@
+@media all
+{
+ body {
+ font-family: "Helvetica Neue", "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, sans-serif !important;
+ font-size: 14px;
+ line-height: 21px;
+ color: #333;
+
+ max-width: 800px;
+ margin: auto;
+ /* background-image: url(http://orgmode.org/worg-unicorn.png); */
+ /* background-position: 25px 5px; */
+ /* background-repeat: no-repeat; */
+ }
+ body #content {
+ padding-top: 70px;
+ }
+ body .title {
+ margin-left: 120px;
+ }
+
+ #org-div-home-and-up{
+ position: fixed;
+ right: 0;
+ top: 4em;
+ }
+
+ #site-map {
+ font-size: 10pt;
+ position: fixed;
+ left: 0em;
+ top: 0em;
+ background: white;
+ -webkit-box-shadow: 0 0 1em #777777;
+ -moz-box-shadow: 0 0 1em #777777;
+ -webkit-border-bottom-right-radius: 5px;
+ -moz-border-radius-bottomright: 5px;
+ text-align: right;
+ /* ensure doesn't flow off the screen when expanded */
+ max-height: 80%;
+ overflow: auto; }
+ #site-map h2 {
+ font-size: 10pt;
+ max-width: 9em;
+ font-weight: normal;
+ padding-left: 0.5em;
+ padding-left: 0.5em;
+ padding-top: 0.05em;
+ padding-bottom: 0.05em; }
+ #site-map #text-site-map {
+ text-align: left;
+ display: block;
+ padding: 0.5em;
+ margin-top: -1.5em; }
+ /* #site-map #text-site-map { */
+ /* display: none; */
+ /* text-align: left; } */
+ /* #site-map:hover #text-site-map { */
+ /* display: block; */
+ /* padding: 0.5em; */
+ /* margin-top: -1.5em; } */
+
+ #blog-site-map {
+ font-size: 10pt;
+ position: fixed;
+ left: 0em;
+ top: 0em;
+ background: white;
+ -webkit-box-shadow: 0 0 1em #777777;
+ -moz-box-shadow: 0 0 1em #777777;
+ -webkit-border-bottom-right-radius: 5px;
+ -moz-border-radius-bottomright: 5px;
+ text-align: right;
+ /* ensure doesn't flow off the screen when expanded */
+ max-height: 80%;
+ overflow: auto; }
+ #blog-site-map h2 {
+ font-size: 10pt;
+ max-width: 9em;
+ font-weight: normal;
+ padding-left: 0.5em;
+ padding-left: 0.5em;
+ padding-top: 0.05em;
+ padding-bottom: 0.05em; }
+ #blog-site-map #text-blog-site-map {
+ text-align: left;
+ padding: 0.5em;
+ display: none; }
+ #blog-site-map:hover #text-blog-site-map {
+ text-align: left;
+ display: block;
+ padding: 0.5em;
+ margin-top: -1.5em;
+ }
+ /* #site-map #text-site-map { */
+ /* display: none; */
+ /* text-align: left; } */
+ /* #site-map:hover #text-site-map { */
+ /* display: block; */
+ /* padding: 0.5em; */
+ /* margin-top: -1.5em; } */
+
+ /* TOC inspired by http://jashkenas.github.com/coffee-script */
+ #table-of-contents {
+ font-size: 10pt;
+ position: fixed;
+ right: 1em;
+ top: 1em;
+ background: white;
+ -webkit-box-shadow: 0 0 1em #777777;
+ -moz-box-shadow: 0 0 1em #777777;
+ -webkit-border-bottom-left-radius: 5px;
+ -moz-border-radius-bottomleft: 5px;
+ text-align: right;
+ /* ensure doesn't flow off the screen when expanded */
+ max-height: 80%;
+ overflow: auto;
+ padding: 0.5em;
+}
+ #table-of-contents h2 {
+ font-size: 10pt;
+ max-width: 9em;
+ font-weight: normal;
+ padding-left: 0.5em;
+ padding-left: 0.5em;
+ padding-top: 0.05em;
+ padding-bottom: 0.05em; }
+ #table-of-contents #text-table-of-contents {
+ display: none;
+ text-align: left; }
+ #table-of-contents:hover #text-table-of-contents {
+ display: block;
+ padding: 0.5em;
+ margin-top: -1.5em; }
+
+ /* #license { */
+ /* padding: .3em; */
+ /* border: 1px solid gray; */
+ /* background-color: #eeeeee; */
+ /* } */
+
+ h1 {
+/*
+ font-family:Sans;
+ font-weight:bold; */
+ /*font-size:2.5em;*/ /*LUKA*/
+ padding:0 0 30px 0;
+ margin-top: 10px;
+ margin-bottom: 10px;
+ margin-right: 7%;
+ margin-left: 0.6em; /*LUKA*/
+ /*color: #6C5D4F;*/
+ color: #58529f; /*LUKA*/
+ }
+
+ .outline-text-1 { /*LUKA*/
+ margin-left: 0.6em;
+ font-size:1em;
+ }
+
+/*
+ h2:before {
+ content: "* "
+ }
+
+
+ h3:before {
+ content: "** "
+ }
+
+ h4:before {
+ content: "*** "
+ }
+*/
+
+ h2 {
+ font-family:Arial,sans-serif;
+ /*font-size:2.1em;*/ /*LUKA*/
+ line-height:16px;
+ padding:7px 0 0 0;
+ color: #D40000; /*LUKA*/
+ margin-left: 0.4em; /*LUKA*/
+ }
+
+ .outline-text-2 {
+ margin-left: 0.6em; /*LUKA*/
+ /*font-size:1.2em;*/ /*LUKA*/
+ }
+
+ .title {
+
+ }
+
+ h3 {
+ font-family:Arial,sans-serif;
+ /*font-size:1.3em;*/
+ color: #D40000; /*LUKA*/
+ margin-left: 0.6em;
+ }
+
+ .outline-text-3 {
+ margin-left: 0.9em;
+ }
+
+ h4 {
+ font-family:Arial,sans-serif;
+ /*font-size:1.2em;*/
+ margin-left: 1.2em;
+ color: #A5573E;
+ }
+
+ .outline-text-4 {
+ margin-left: 1.45em;
+ }
+
+ /*LUKA*/
+ a {text-decoration: none; color: #58529f} /*color: #537d7b}*/
+
+ /* a:visited {text-decoration: none; color: #224444} */ /* Taken out because color too similar to text. */
+ a:visited {text-decoration: none; color: #800000}/*color: #98855b} /* this is now the color of the Unicorns horn */
+ a:hover {text-decoration: underline; color: #a34d32}
+
+ .todo {
+ color: #CA0000;
+ }
+
+ .done {
+ color: #006666;
+ }
+
+ .timestamp-kwd {
+ color: #444;
+ }
+
+ .tag {
+
+ }
+
+ li {
+ margin: .4em;
+ }
+
+ table {
+ border: none;
+ }
+
+ td {
+ border: none;
+ }
+
+ th {
+ border: none;
+ }
+
+ code {
+ font-size: 100%;
+ color: black;
+ border: 1px solid #DEDEDE;
+ padding: 0px 0.2em;
+ }
+
+ img {
+ border: none;
+ }
+
+ .share img {
+ opacity: .4;
+ -moz-opacity: .4;
+ filter: alpha(opacity=40);
+ }
+
+ .share img:hover {
+ opacity: 1;
+ -moz-opacity: 1;
+ filter: alpha(opacity=100);
+ }
+
+ /* pre {border: 1px solid #555; */
+ /* background: #EEE; */
+ /* font-size: 9pt; */
+ /* padding: 1em; */
+ /* } */
+
+ /* pre { */
+ /* color: #e5e5e5; */
+ /* background-color: #000000; */
+ /* padding: 1.4em; */
+ /* border: 2px solid gray; */
+ /* } */
+
+ /* pre { */
+ /* background-color: #2b2b2b; */
+ /* border: 4px solid gray; */
+ /* color: #EEE; */
+ /* overflow: auto; */
+ /* padding: 1em; */
+ /* } */
+
+ pre {
+ font-family: Monaco, Consolas, "Lucida Console", monospace;
+ color: black;
+ background-color: #efefef;
+ padding: 1.2em;
+ border: 1px solid #dddddd;
+ overflow: auto;
+
+ -webkit-box-shadow: 0px 0px 4px rgba(0,0,0,0.23);
+ -moz-box-shadow: 0px 0px 4px rgba(0,0,0,0.23);
+ box-shadow: 0px 0px 4px rgba(0,0,0,0.23);
+ }
+
+ .org-info-box {
+ clear:both;
+ margin-left:auto;
+ margin-right:auto;
+ padding:0.7em;
+ /* border:1px solid #CCC; */
+ /* border-radius:10px; */
+ /* -moz-border-radius:10px; */
+ }
+ .org-info-box img {
+ float:left;
+ margin:0em 0.5em 0em 0em;
+ }
+ .org-info-box p {
+ margin:0em;
+ padding:0em;
+ }
+
+
+ .builtin {
+ /* font-lock-builtin-face */
+ color: #f4a460;
+ }
+ .comment {
+ /* font-lock-comment-face */
+ color: #737373;
+ }
+ .comment-delimiter {
+ /* font-lock-comment-delimiter-face */
+ color: #666666;
+ }
+ .constant {
+ /* font-lock-constant-face */
+ color: #db7093;
+ }
+ .doc {
+ /* font-lock-doc-face */
+ color: #b3b3b3;
+ }
+ .function-name {
+ /* font-lock-function-name-face */
+ color: #5f9ea0;
+ }
+ .headline {
+ /* headline-face */
+ color: #ffffff;
+ background-color: #000000;
+ font-weight: bold;
+ }
+ .keyword {
+ /* font-lock-keyword-face */
+ color: #4682b4;
+ }
+ .negation-char {
+ }
+ .regexp-grouping-backslash {
+ }
+ .regexp-grouping-construct {
+ }
+ .string {
+ /* font-lock-string-face */
+ color: #ccc79a;
+ }
+ .todo-comment {
+ /* todo-comment-face */
+ color: #ffffff;
+ background-color: #000000;
+ font-weight: bold;
+ }
+ .variable-name {
+ /* font-lock-variable-name-face */
+ color: #ff6a6a;
+ }
+ .warning {
+ /* font-lock-warning-face */
+ color: #ffffff;
+ background-color: #cd5c5c;
+ font-weight: bold;
+ }
+ pre.a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ pre.a:hover {
+ text-decoration: underline;
+ }
+
+ /* Styles for org-info.js */
+
+ .org-info-js_info-navigation
+ {
+ border-style:none;
+ }
+
+ #org-info-js_console-label
+ {
+ font-size:10px;
+ font-weight:bold;
+ white-space:nowrap;
+ }
+
+ .org-info-js_search-highlight
+ {
+ background-color:#ffff00;
+ color:#000000;
+ font-weight:bold;
+ }
+
+ #org-info-js-window
+ {
+ border-bottom:1px solid black;
+ padding-bottom:10px;
+ margin-bottom:10px;
+ }
+
+
+
+ .org-info-search-highlight
+ {
+ background-color:#adefef; /* same color as emacs default */
+ color:#000000;
+ font-weight:bold;
+ }
+
+ .org-bbdb-company {
+ /* bbdb-company */
+ font-style: italic;
+ }
+ .org-bbdb-field-name {
+ }
+ .org-bbdb-field-value {
+ }
+ .org-bbdb-name {
+ /* bbdb-name */
+ text-decoration: underline;
+ }
+ .org-bold {
+ /* bold */
+ font-weight: bold;
+ }
+ .org-bold-italic {
+ /* bold-italic */
+ font-weight: bold;
+ font-style: italic;
+ }
+ .org-border {
+ /* border */
+ background-color: #000000;
+ }
+ .org-buffer-menu-buffer {
+ /* buffer-menu-buffer */
+ font-weight: bold;
+ }
+ .org-builtin {
+ /* font-lock-builtin-face */
+ color: #da70d6;
+ }
+ .org-button {
+ /* button */
+ text-decoration: underline;
+ }
+ .org-c-nonbreakable-space {
+ /* c-nonbreakable-space-face */
+ background-color: #ff0000;
+ font-weight: bold;
+ }
+ .org-calendar-today {
+ /* calendar-today */
+ text-decoration: underline;
+ }
+ .org-comment {
+ /* font-lock-comment-face */
+ color: #b22222;
+ }
+ .org-comment-delimiter {
+ /* font-lock-comment-delimiter-face */
+ color: #b22222;
+ }
+ .org-constant {
+ /* font-lock-constant-face */
+ color: #5f9ea0;
+ }
+ .org-cursor {
+ /* cursor */
+ background-color: #000000;
+ }
+ .org-default {
+ /* default */
+ color: #000000;
+ background-color: #ffffff;
+ }
+ .org-diary {
+ /* diary */
+ color: #ff0000;
+ }
+ .org-doc {
+ /* font-lock-doc-face */
+ color: #bc8f8f;
+ }
+ .org-escape-glyph {
+ /* escape-glyph */
+ color: #a52a2a;
+ }
+ .org-file-name-shadow {
+ /* file-name-shadow */
+ color: #7f7f7f;
+ }
+ .org-fixed-pitch {
+ }
+ .org-fringe {
+ /* fringe */
+ background-color: #f2f2f2;
+ }
+ .org-function-name {
+ /* font-lock-function-name-face */
+ color: #0000ff;
+ }
+ .org-header-line {
+ /* header-line */
+ color: #333333;
+ background-color: #e5e5e5;
+ }
+ .org-help-argument-name {
+ /* help-argument-name */
+ font-style: italic;
+ }
+ .org-highlight {
+ /* highlight */
+ background-color: #b4eeb4;
+ }
+ .org-holiday {
+ /* holiday */
+ background-color: #ffc0cb;
+ }
+ .org-info-header-node {
+ /* info-header-node */
+ color: #a52a2a;
+ font-weight: bold;
+ font-style: italic;
+ }
+ .org-info-header-xref {
+ /* info-header-xref */
+ color: #ff6600; /*LUKA*/
+ /*color: #0000ff;*/
+ text-decoration: underline;
+ }
+ .org-info-menu-header {
+ /* info-menu-header */
+ font-weight: bold;
+ }
+ .org-info-menu-star {
+ /* info-menu-star */
+ color: #ff0000;
+ }
+ .org-info-node {
+ /* info-node */
+ color: #a52a2a;
+ font-weight: bold;
+ font-style: italic;
+ }
+ .org-info-title-1 {
+ /* info-title-1 */
+ font-size: 172%;
+ font-weight: bold;
+ }
+ .org-info-title-2 {
+ /* info-title-2 */
+ font-size: 144%;
+ font-weight: bold;
+ }
+ .org-info-title-3 {
+ /* info-title-3 */
+ font-size: 120%;
+ font-weight: bold;
+ }
+ .org-info-title-4 {
+ /* info-title-4 */
+ font-weight: bold;
+ }
+ .org-info-xref {
+ /* info-xref */
+ color: #ff6600; /*LUKA*/
+/* color: #0000ff;*/
+ text-decoration: underline;
+ }
+ .org-isearch {
+ /* isearch */
+ color: #b0e2ff;
+ background-color: #cd00cd;
+ }
+ .org-italic {
+ /* italic */
+ font-style: italic;
+ }
+ .org-keyword {
+ /* font-lock-keyword-face */
+ color: #a020f0;
+ }
+ .org-lazy-highlight {
+ /* lazy-highlight */
+ background-color: #afeeee;
+ }
+ .org-link {
+ /* link */
+ /*color: #0000ff;*/
+ color: #ff6600; /*LUKA*/
+ text-decoration: underline;
+ }
+ .org-link-visited {
+ /* link-visited */
+ color: #ff0000; /*LUKA*/
+ /*color: #8b008b;*/
+ text-decoration: underline;
+ }
+ .org-match {
+ /* match */
+ background-color: #ffff00;
+ }
+ .org-menu {
+ }
+ .org-message-cited-text {
+ /* message-cited-text */
+ color: #ff0000;
+ }
+ .org-message-header-cc {
+ /* message-header-cc */
+ color: #191970;
+ }
+ .org-message-header-name {
+ /* message-header-name */
+ color: #6495ed;
+ }
+ .org-message-header-newsgroups {
+ /* message-header-newsgroups */
+ color: #00008b;
+ font-weight: bold;
+ font-style: italic;
+ }
+ .org-message-header-other {
+ /* message-header-other */
+ color: #4682b4;
+ }
+ .org-message-header-subject {
+ /* message-header-subject */
+ color: #000080;
+ font-weight: bold;
+ }
+ .org-message-header-to {
+ /* message-header-to */
+ color: #191970;
+ font-weight: bold;
+ }
+ .org-message-header-xheader {
+ /* message-header-xheader */
+ color: #0000ff;
+ }
+ .org-message-mml {
+ /* message-mml */
+ color: #228b22;
+ }
+ .org-message-separator {
+ /* message-separator */
+ color: #a52a2a;
+ }
+ .org-minibuffer-prompt {
+ /* minibuffer-prompt */
+ color: #0000cd;
+ }
+ .org-mm-uu-extract {
+ /* mm-uu-extract */
+ color: #006400;
+ background-color: #ffffe0;
+ }
+ .org-mode-line {
+ /* mode-line */
+ color: #000000;
+ background-color: #bfbfbf;
+ }
+ .org-mode-line-buffer-id {
+ /* mode-line-buffer-id */
+ font-weight: bold;
+ }
+ .org-mode-line-highlight {
+ }
+ .org-mode-line-inactive {
+ /* mode-line-inactive */
+ color: #333333;
+ background-color: #e5e5e5;
+ }
+ .org-mouse {
+ /* mouse */
+ background-color: #000000;
+ }
+ .org-negation-char {
+ }
+ .org-next-error {
+ /* next-error */
+ background-color: #eedc82;
+ }
+ .org-nobreak-space {
+ /* nobreak-space */
+ color: #a52a2a;
+ text-decoration: underline;
+ }
+ .org-org-agenda-date {
+ /* org-agenda-date */
+ color: #0000ff;
+ }
+ .org-org-agenda-date-weekend {
+ /* org-agenda-date-weekend */
+ color: #0000ff;
+ font-weight: bold;
+ }
+ .org-org-agenda-restriction-lock {
+ /* org-agenda-restriction-lock */
+ background-color: #ffff00;
+ }
+ .org-org-agenda-structure {
+ /* org-agenda-structure */
+ color: #0000ff;
+ }
+ .org-org-archived {
+ /* org-archived */
+ color: #7f7f7f;
+ }
+ .org-org-code {
+ /* org-code */
+ color: #7f7f7f;
+ }
+ .org-org-column {
+ /* org-column */
+ background-color: #e5e5e5;
+ }
+ .org-org-column-title {
+ /* org-column-title */
+ background-color: #e5e5e5;
+ font-weight: bold;
+ text-decoration: underline;
+ }
+ .org-org-date {
+ /* org-date */
+ color: #a020f0;
+ text-decoration: underline;
+ }
+ .org-org-done {
+ /* org-done */
+ color: #228b22;
+ font-weight: bold;
+ }
+ .org-org-drawer {
+ /* org-drawer */
+ color: #0000ff;
+ }
+ .org-org-ellipsis {
+ /* org-ellipsis */
+ color: #b8860b;
+ text-decoration: underline;
+ }
+ .org-org-formula {
+ /* org-formula */
+ color: #b22222;
+ }
+ .org-org-headline-done {
+ /* org-headline-done */
+ color: #bc8f8f;
+ }
+ .org-org-hide {
+ /* org-hide */
+ color: #e5e5e5;
+ }
+ .org-org-latex-and-export-specials {
+ /* org-latex-and-export-specials */
+ color: #8b4513;
+ }
+ .org-org-level-1 {
+ /* org-level-1 */
+ color: #0000ff;
+ }
+ .org-org-level-2 {
+ /* org-level-2 */
+ color: #b8860b;
+ }
+ .org-org-level-3 {
+ /* org-level-3 */
+ color: #a020f0;
+ }
+ .org-org-level-4 {
+ /* org-level-4 */
+ color: #b22222;
+ }
+ .org-org-level-5 {
+ /* org-level-5 */
+ color: #228b22;
+ }
+ .org-org-level-6 {
+ /* org-level-6 */
+ color: #5f9ea0;
+ }
+ .org-org-level-7 {
+ /* org-level-7 */
+ color: #da70d6;
+ }
+ .org-org-level-8 {
+ /* org-level-8 */
+ color: #bc8f8f;
+ }
+ .org-org-link {
+ /* org-link */
+ color: #ff6600; /*LUKA*/
+ /*color: #a020f0;*/
+ text-decoration: underline;
+ }
+ .org-org-property-value {
+ }
+ .org-org-scheduled-previously {
+ /* org-scheduled-previously */
+ color: #b22222;
+ }
+ .org-org-scheduled-today {
+ /* org-scheduled-today */
+ color: #006400;
+ }
+ .org-org-sexp-date {
+ /* org-sexp-date */
+ color: #a020f0;
+ }
+ .org-org-special-keyword {
+ /* org-special-keyword */
+ color: #bc8f8f;
+ }
+ .org-org-table {
+ /* org-table */
+ color: #0000ff;
+ }
+ .org-org-tag {
+ /* org-tag */
+ font-weight: bold;
+ }
+ .org-org-target {
+ /* org-target */
+ text-decoration: underline;
+ }
+ .org-org-time-grid {
+ /* org-time-grid */
+ color: #b8860b;
+ }
+ .org-org-todo {
+ /* org-todo */
+ color: #ff0000;
+ }
+ .org-org-upcoming-deadline {
+ /* org-upcoming-deadline */
+ color: #b22222;
+ }
+ .org-org-verbatim {
+ /* org-verbatim */
+ color: #7f7f7f;
+ text-decoration: underline;
+ }
+ .org-org-warning {
+ /* org-warning */
+ color: #ff0000;
+ font-weight: bold;
+ }
+ .org-outline-1 {
+ /* outline-1 */
+ color: #0000ff;
+ }
+ .org-outline-2 {
+ /* outline-2 */
+ color: #b8860b;
+ }
+ .org-outline-3 {
+ /* outline-3 */
+ color: #a020f0;
+ }
+ .org-outline-4 {
+ /* outline-4 */
+ color: #b22222;
+ }
+ .org-outline-5 {
+ /* outline-5 */
+ color: #228b22;
+ }
+ .org-outline-6 {
+ /* outline-6 */
+ color: #5f9ea0;
+ }
+ .org-outline-7 {
+ /* outline-7 */
+ color: #da70d6;
+ }
+ .org-outline-8 {
+ /* outline-8 */
+ color: #bc8f8f;
+ }
+ .outline-text-1, .outline-text-2, .outline-text-3, .outline-text-4, .outline-text-5, .outline-text-6 {
+ /* Add more spacing between section. Padding, so that folding with org-info.js works as expected. */
+
+ }
+
+ .org-preprocessor {
+ /* font-lock-preprocessor-face */
+ color: #da70d6;
+ }
+ .org-query-replace {
+ /* query-replace */
+ color: #b0e2ff;
+ background-color: #cd00cd;
+ }
+ .org-regexp-grouping-backslash {
+ /* font-lock-regexp-grouping-backslash */
+ font-weight: bold;
+ }
+ .org-regexp-grouping-construct {
+ /* font-lock-regexp-grouping-construct */
+ font-weight: bold;
+ }
+ .org-region {
+ /* region */
+ background-color: #eedc82;
+ }
+ .org-rmail-highlight {
+ }
+ .org-scroll-bar {
+ /* scroll-bar */
+ background-color: #bfbfbf;
+ }
+ .org-secondary-selection {
+ /* secondary-selection */
+ background-color: #ffff00;
+ }
+ .org-shadow {
+ /* shadow */
+ color: #7f7f7f;
+ }
+ .org-show-paren-match {
+ /* show-paren-match */
+ background-color: #40e0d0;
+ }
+ .org-show-paren-mismatch {
+ /* show-paren-mismatch */
+ color: #ffffff;
+ background-color: #a020f0;
+ }
+ .org-string {
+ /* font-lock-string-face */
+ color: #bc8f8f;
+ }
+ .org-texinfo-heading {
+ /* texinfo-heading */
+ color: #0000ff;
+ }
+ .org-tool-bar {
+ /* tool-bar */
+ color: #000000;
+ background-color: #bfbfbf;
+ }
+ .org-tooltip {
+ /* tooltip */
+ color: #000000;
+ background-color: #ffffe0;
+ }
+ .org-trailing-whitespace {
+ /* trailing-whitespace */
+ background-color: #ff0000;
+ }
+ .org-type {
+ /* font-lock-type-face */
+ color: #228b22;
+ }
+ .org-underline {
+ /* underline */
+ text-decoration: underline;
+ }
+ .org-variable-name {
+ /* font-lock-variable-name-face */
+ color: #b8860b;
+ }
+ .org-variable-pitch {
+ }
+ .org-vertical-border {
+ }
+ .org-warning {
+ /* font-lock-warning-face */
+ color: #ff0000;
+ font-weight: bold;
+ }
+ .rss_box {}
+ .rss_title, rss_title a {}
+ .rss_items {}
+ .rss_item a:link, .rss_item a:visited, .rss_item a:active {}
+ .rss_item a:hover {}
+ .rss_date {}
+
+ #postamble {
+ padding: .3em;
+ border: 1px solid gray;
+ background-color: #eeeeee;
+ }
+
+
+} /* END OF @media all */
+
+
+
+@media screen
+{
+ #table-of-contents {
+ float: right;
+ border: 1px solid #CCC;
+ max-width: 50%;
+ overflow: auto;
+ z-index: 99999;
+ }
+} /* END OF @media screen */
+
+.left{float:left; margin:0 15px 4px 0;}
+.right{float:right; margin:0 0 4px 15px;}
+.photo{
+border:1px solid #bababa;
+padding:2px;
+background-color:#ffffff;
+margin:6px 18px 2px 5px;
+}
diff --git a/doc/orgmode/morse.css b/doc/orgmode/morse.css
deleted file mode 100644
index 41adb2007..000000000
--- a/doc/orgmode/morse.css
+++ /dev/null
@@ -1,72 +0,0 @@
-body {
- padding: 2em 1em 2em 70px;
- margin: 0;
- font-family: sans-serif;
- color: black;
- background: white;
- background-position: top left;
- background-attachment: fixed;
- background-repeat: no-repeat;
-}
-:link { color: #00C; background: transparent }
-:visited { color: #609; background: transparent }
-a:active { color: #C00; background: transparent }
-
-a:link img, a:visited img { border-style: none }
-
-a img { color: white; }
-@media all {
- a img { color: inherit; }
-}
-
-th, td {
- font-family: sans-serif;
-}
-
-h1, h2, h3, h4, h5, h6 { text-align: left }
-h1, h2, h3 { color: #005A9C; background: white }
-h1 { font: 170% sans-serif }
-h2 { font: 140% sans-serif }
-h3 { font: 120% sans-serif }
-h4 { font: bold 100% sans-serif }
-h5 { font: italic 100% sans-serif }
-h6 { font: small-caps 100% sans-serif }
-
-.hide { display: none }
-
-div.head { margin-bottom: 1em }
-div.head h1 { margin-top: 2em; clear: both }
-div.head table { margin-left: 2em; margin-top: 2em }
-
-p.copyright { font-size: small }
-p.copyright small { font-size: small }
-
-@media screen {
-a[href]:hover { background: #ffa }
-}
-
-pre { margin-left: 2em }
-
-dt, dd { margin-top: 0; margin-bottom: 0 }
-dt { font-weight: bold }
-
-pre, code { font-family: monospace }
-
-ul.toc, ol.toc {
- list-style: disc;
- list-style: none;
-}
-
-@media aural {
- h1, h2, h3 { stress: 20; richness: 90 }
- .hide { speak: none }
- p.copyright { volume: x-soft; speech-rate: x-fast }
- dt { pause-before: 20% }
- pre { speak-punctuation: code }
-}
-
-/*
-body {
- background-image: url();
-}
-*/
diff --git a/doc/orgmode/users_guide.org.in b/doc/orgmode/users_guide.org.in
index 2b0a3327a..4e5f3c2ea 100644
--- a/doc/orgmode/users_guide.org.in
+++ b/doc/orgmode/users_guide.org.in
@@ -3,6 +3,10 @@
#+LANGUAGE: en
#+OPTIONS: H:3 num:t \n:nil @:t ::t |:t _:nil ^:nil -:t f:t *:t <:t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil pri:nil tags:not-in-toc html-style:nil
+#+BEAMER_THEME: Rochester
+#+HTML_HEAD: <link rel="stylesheet" title="Standard" href="css/worg.css" type="text/css" />
+#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="css/VisuGen.css" />
+#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="css/VisuRubriqueEncadre.css" />
#+INCLUDE: "./version.org"
#+AUTHOR: version {{{VERSION}}}
* Version
@@ -15,7 +19,7 @@
* King Abdullah University of Science and Technology
* Copying
- * Copyright \copy 2017 Inria
+ * Copyright \copy {{{UPDATED-YEAR}}} Inria
* Copyright \copy 2014 The University of Tennessee
* Copyright \copy 2014 King Abdullah University of Science and Technology
diff --git a/doc/orgmode/version.org.in b/doc/orgmode/version.org.in
index 4481ea26c..8bc0a7dbe 100644
--- a/doc/orgmode/version.org.in
+++ b/doc/orgmode/version.org.in
@@ -1,4 +1,5 @@
-#+MACRO: UPDATED 25 August 2017
-#+MACRO: UPDATED-MONTH August 2017
+#+MACRO: UPDATED {{{time(%Y-%m-%d)}}}
+#+MACRO: UPDATED-MONTH {{{time(%m-%d)}}}
+#+MACRO: UPDATED-YEAR {{{time(%Y)}}}
#+MACRO: EDITION @CHAMELEON_VERSION_MAJOR@.@CHAMELEON_VERSION_MINOR@.@CHAMELEON_VERSION_MICRO@
#+MACRO: VERSION @CHAMELEON_VERSION_MAJOR@.@CHAMELEON_VERSION_MINOR@.@CHAMELEON_VERSION_MICRO@
--
GitLab