Commit a3d6277e authored by Alan O'Cais's avatar Alan O'Cais

Merge branch 'master' into patch-4

parents 7dacb6f1 0133a8d0
......@@ -3,7 +3,7 @@ image: cloudcompass/docker-rtdsphinx
spelling:
script:
- pip3 install codespell
- codespell --skip=".git,_static,_build,Diff*,*.patch" --quiet-level=2 --ignore-words-list="adress"
- codespell --skip=".git,_static,_build,Diff*,*.patch,*.f90" --quiet-level=2 --ignore-words-list="adress,catalogue"
only:
- master
- merge_requests
......@@ -13,7 +13,7 @@ orphans:
# Report all the orphans but ignore the exit code
- find ./ -name "*.rst"|xargs -i grep -H orphan {} || true
# Now handle the error code
- if [ $(find ./ -name "*.rst"|xargs -i grep -H orphan {}|wc -l) -gt "1" ]; then $(exit 1); else $(exit 0); fi
- if [ $(find ./ -name "*.rst"|xargs -i grep -H orphan {}|wc -l) -gt "2" ]; then $(exit 1); else $(exit 0); fi
only:
- master
......
......@@ -244,4 +244,13 @@ August 2017. The following modules have been produced:
./modules/OpenPathSampling/ops_plumed_wrapper/readme
./modules/OpenPathSampling/ops_s_shooting/readme
The third ESDW for the Classical MD workpackage was held in Turin, Italy in July
2018. The following have been produced as a result:
.. toctree::
:glob:
:maxdepth: 1
./modules/HTC/decorators/readme
.. _E-CAM: https://www.e-cam2020.eu/
.. In ReStructured Text (ReST) indentation and spacing are very important (it is how ReST knows what to do with your
document). For ReST to understand what you intend and to render it correctly please to keep the structure of this
template. Make sure that any time you use ReST syntax (such as for ".. sidebar::" below), it needs to be preceded
and followed by white space (if you see warnings when this file is built they this is a common origin for problems).
.. Firstly, let's add technical info as a sidebar and allow text below to wrap around it. This list is a work in
progress, please help us improve it. We use *definition lists* of ReST_ to make this readable.
.. sidebar:: Software Technical Information
Name
``jobqueue_features``
Language
Python
Licence
`MIT <https://opensource.org/licenses/mit-license>`_
Documentation Tool
In-source documentation
Application Documentation
Not currently available.. Example usage provided.
Relevant Training Material
Not currently available.
Software Module Developed by
Adam Włodarczyk (Wrocław Centre of Networking and Supercomputing),
Alan O'Cais (Juelich Supercomputing Centre)
.. In the next line you have the name of how this module will be referenced in the main documentation (which you can
reference, in this case, as ":ref:`example`"). You *MUST* change the reference below from "example" to something
unique otherwise you will cause cross-referencing errors. The reference must come right before the heading for the
reference to work (so don't insert a comment between).
.. _htc:
#######################################
E-CAM High Throughput Computing Library
#######################################
.. Let's add a local table of contents to help people navigate the page
.. contents:: :local:
.. Add an abstract for a *general* audience here. Write a few lines that explains the "helicopter view" of why you are
creating this module. For example, you might say that "This module is a stepping stone to incorporating XXXX effects
into YYYY process, which in turn should allow ZZZZ to be simulated. If successful, this could make it possible to
produce compound AAAA while avoiding expensive process BBBB and CCCC."
E-CAM is interested in the challenge
of bridging timescales. To study molecular dynamics with atomistic detail, timesteps must be used on
the order of a femtosecond. Many problems in biological chemistry, materials science, and other
fields involve events that only spontaneously occur after a millisecond or longer (for example,
biomolecular conformational changes, or nucleation processes). That means that around :math:`10^{12}` time
steps would be needed to see a single millisecond-scale event. This is the problem of "rare
events" in theoretical and computational chemistry.
Modern supercomputers are beginning to make it
possible to obtain trajectories long enough to observe some of these processes, but to fully
characterize a transition with proper statistics, many examples are needed. In order to obtain many
examples the same application must be run many thousands of times with varying inputs. To manage
this kind of computation a task scheduling high throughput computing (HTC) library is needed. The main elements of mentioned
scheduling library are: task definition, task scheduling and task execution.
While traditionally an HTC workload is looked down upon in the HPC
space, the scientific use case for extreme-scale resources exists and algorithms that require a
coordinated approach make efficient libraries that implement
this approach increasingly important in the HPC space. The 5 Petaflop booster technology of `JURECA <http://www.fz-juelich.de/ias/jsc/EN/Expertise/Supercomputers/JURECA/JURECA_node.html>`_
is an interesting concept with respect to this approach since the offloading approach of heavy
computation marries perfectly to the concept outlined here.
Purpose of Module
_________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
This module is the first in a sequence that will form the overall capabilities of the library. In particular this module
deals with creating a set of decorators to wrap around the `Dask-Jobqueue <https://jobqueue.dask.org/en/latest/>`_
Python library, which aspires to make the development time cost of leveraging it lower for our use cases.
Background Information
______________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
The initial motivation for this library is driven by the ensemble-type calculations that are required in many scientific
fields, and in particular in the materials science domain in which the E-CAM Centre of Excellence operates. The scope
for parallelisation is best contextualised by the `Dask <https://dask.org/>`_ documentation:
A common approach to parallel execution in user-space is task scheduling. In task scheduling we break our program
into many medium-sized tasks or units of computation, often a function call on a non-trivial amount of data. We
represent these tasks as nodes in a graph with edges between nodes if one task depends on data produced by another.
We call upon a task scheduler to execute this graph in a way that respects these data dependencies and leverages
parallelism where possible, multiple independent tasks can be run simultaneously.
Many solutions exist. This is a common approach in parallel execution frameworks. Often task scheduling logic hides
within other larger frameworks (Luigi, Storm, Spark, IPython Parallel, and so on) and so is often reinvented.
Dask is a specification that encodes task schedules with minimal incidental complexity using terms common to all
Python projects, namely dicts, tuples, and callables. Ideally this minimum solution is easy to adopt and understand
by a broad community.
While we were attracted by this approach, Dask did not support *task-level* parallelisation (in particular
multi-node tasks). We researched other options (including Celery, PyCOMPSs, IPyParallel and others) and organised a
workshop that explored some of these (see https://www.cecam.org/workshop-0-1650.html for further details).
Building and Testing
____________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
The library is a Python module and can be installed with
::
python setup.py install
More details about how to install a Python package can be found at, for example, `Install Python packages on the
research computing systems at IU <https://kb.iu.edu/d/acey>`_
To run the tests for the decorators within the library, you need the ``pytest`` Python package. You can run all the
relevant tests from the ``jobqueue_features`` directory with
::
pytest tests/test_decorators.py
Examples of usage can be found in the ``examples`` directory.
Source Code
___________
The latest version of the library is available on the `jobqueue_features GitHub repository
<https://github.com/E-CAM/jobqueue_features>`_, the file specific to this module
is `decorators.py <https://github.com/E-CAM/jobqueue_features/blob/master/jobqueue_features/decorators.py>`_.
(The code that was originally created for this module can be seen in the specific commit `4590a0e427112f
<https://gitlab.e-cam2020.eu/adam/jobqueue_features/tree/4590a0e427112fbf51edff6116e34c90e765baf0>`_
which can be found in the original private repository of the code.)
......@@ -25,9 +25,10 @@ OPS-based modules
Licence
LGPL, v. 2.1 or later
.. contents:: :local:
Software module developed by
YOUR NAME(S) HERE
Authors: Alan O'Cais
.. contents:: :local:
This is the template for an E-CAM *module* based on OpenPathSampling (OPS). Several
sections are already pre-filled with the details of OPS. Please fill out the
......@@ -66,18 +67,19 @@ reading:
Testing
_______
Tests in OpenPathSampling use the `nose`_ package.
Tests in OpenPathSampling use `pytest`_.
.. IF YOUR MODULE IS IN OPS CORE:
.. This module has been included in the OpenPathSampling core. Its tests can
.. be run by setting up a developer install of OpenPathSampling and running
.. the command ``nosetests`` from the root directory of the repository.
.. be run by installing pytest and OPS (with commit ????????, which will be
.. part of release ??? and later), and running the command ``py.test
.. --pyargs openpathsampling``.
.. IF YOUR MODULE IS IN A SEPARATE REPOSITORY
.. The tests for this module can be run by downloading its source code,
.. installing its requirements, and running the command ``nosetests`` from the
.. installing its requirements, and running the command ``py.test`` from the
.. root directory of the repository.
Examples
......@@ -105,5 +107,5 @@ ___________
.. Here are the URL references used
.. _nose: http://nose.readthedocs.io/en/latest/
.. _pytest: http://pytest.org/
.. sidebar:: Software Technical Information
Name
Weigthed Linear Ridge Regression
Weighted Linear Ridge Regression
Language
C
......@@ -19,7 +19,7 @@
Francesco Fracchia
################################
Weigthed Linear Ridge Regression
Weighted Linear Ridge Regression
################################
.. contents:: :local:
......
......@@ -44,8 +44,8 @@ together with the partner and typically are to facilitate or improve the scope o
partner. The related code development for the pilot projects are open source (where the licence of the underlying
software allows this) and are described in the modules associated with the pilot projects.
Extended Software Development Workshops
=======================================
Software related to Extended Software Development Workshops
===========================================================
DL_MESO_DPD
-----------
......@@ -64,6 +64,7 @@ The following modules connected to the DL_MESO_DPD code have been produced so fa
./modules/DL_MESO_DPD_onGPU/fftw/readme
./modules/DL_MESO_DPD/check_dlmeso_dpd/readme
./modules/DL_MESO_DPD/tetra_dlmeso_dpd/readme
./modules/DL_MESO_DPD/sionlib_dlmeso_dpd/readme
ESPResSo++
----------
......@@ -104,17 +105,6 @@ The following modules connected to the ParaDiS code have been produced so far:
./modules/paradis_precipitate/paradis_precipitate_GC/readme.rst
./modules/paradis_precipitate/paradis_precipitate_HPC/readme.rst
ESDW Barcelona 2017
-------------------
The first Meso- and Multi-scale ESDW was held in Barcelona, Spain, in July 2017. The following modules have been produced:
.. toctree::
:glob:
:maxdepth: 1
./modules/DL_MESO_DPD/sionlib_dlmeso_dpd/readme
GC-AdResS
---------
......@@ -127,3 +117,48 @@ Adaptive Resolution Simulation: Implementation in GROMACS
./modules/GC-AdResS/Abrupt_AdResS/readme.rst
./modules/GC-AdResS/Abrupt_AdResS/abrupt_adress.rst
./modules/GC-AdResS/AdResS_RDF/readme.rst
.. _ALL_background:
ALL (A Load-balancing Library)
------------------------------
Most modern parallelized (classical) particle simulation programs are based on a spatial decomposition method as an
underlying parallel algorithm: different processors administrate different spatial regions of the simulation domain and
keep track of those particles that are located in their respective region. Processors exchange information
* in order to compute interactions between particles located on different processors
* to exchange particles that have moved to a region administrated by a different processor.
This implies that the workload of a given processor is very much determined by its number of particles, or, more
precisely, by the number of interactions that are to be evaluated within its spatial region.
Certain systems of high physical and practical interest (e.g. condensing fluids) dynamically develop into a state where
the distribution of particles becomes spatially inhomogeneous. Unless special care is being taken, this results in a
substantially inhomogeneous distribution of the processors’ workload. Since the work usually has to be synchronized
between the processors, the runtime is determined by the slowest processor (i.e. the one with highest workload). In the
extreme case, this means that a large fraction of the processors is idle during these waiting times. This problem
becomes particularly severe if one aims at strong scaling, where the number of processors is increased at constant
problem size: Every processor administrates smaller and smaller regions and therefore inhomogeneities will become more
and more pronounced. This will eventually saturate the scalability of a given problem, already at a processor number
that is still so small that communication overhead remains negligible.
The solution to this problem is the inclusion of dynamic load balancing techniques. These methods redistribute the
workload among the processors, by lowering the load of the most busy cores and enhancing the load of the most idle ones.
Fortunately, several successful techniques are known already to put this strategy into practice. Nevertheless, dynamic
load balancing that is both efficient and widely applicable implies highly non-trivial coding work. Therefore it has has
not yet been implemented in a number of important codes of the E-CAM community, e.g. DL_Meso, DL_Poly, Espresso,
Espresso++, to name a few. Other codes (e.g. LAMMPS) have implemented somewhat simpler schemes, which however might turn
out to lack sufficient flexibility to accommodate all important cases. Therefore, the ALL library was created in the
context of an Extended Software Development Workshop (ESDW) within E-CAM (see `ALL ESDW event details <https://www.e-cam2020.eu/legacy_event/extended-software-development-workshop-for-atomistic-meso-and-multiscale-methods-on-hpc-systems/>`_
), where code developers of CECAM community codes were invited together with E-CAM postdocs, to work on the
implementation of load balancing strategies. The goal of this activity was to increase the scalability of these
applications to a larger number of cores on HPC systems, for spatially inhomogeneous systems, and thus to reduce the
time-to-solution of the applications.
.. toctree::
:glob:
:maxdepth: 1
./modules/ALL_library/tensor_method/readme
.. In ReStructured Text (ReST) indentation and spacing are very important (it is how ReST knows what to do with your
document). For ReST to understand what you intend and to render it correctly please to keep the structure of this
template. Make sure that any time you use ReST syntax (such as for ".. sidebar::" below), it needs to be preceded
and followed by white space (if you see warnings when this file is built they this is a common origin for problems).
.. We allow the template to be standalone, so that the library maintainers add it in the right place
:orphan:
.. Firstly, let's add technical info as a sidebar and allow text below to wrap around it. This list is a work in
progress, please help us improve it. We use *definition lists* of ReST_ to make this readable.
.. sidebar:: Software Technical Information
Name
A Load Balancing Library (ALL)
Language
C++, Fortran interfaces available
Licence
`BSD 3-Clause <https://choosealicense.com/licenses/bsd-3-clause/>`_
Documentation Tool
No tool used in source code, repo documentation written in `Markdown <https://en.wikipedia.org/wiki/Markdown>`_
Application Documentation
See `ALL repository <https://gitlab.version.fz-juelich.de/SLMS/loadbalancing>`_
Relevant Training Material
None available
Software Module Developed by
Rene Halver
.. In the next line you have the name of how this module will be referenced in the main documentation (which you can
reference, in this case, as ":ref:`ALL_example`"). You *MUST* change the reference below from "ALL_method_example"
to something unique otherwise you will cause cross-referencing errors. The reference must come right before the
heading for the reference to work (so don't insert a comment between).
.. _ALL_method_example:
###############################
E-CAM example ALL method module
###############################
.. Let's add a local table of contents to help people navigate the page
.. contents:: :local:
.. Add an abstract for a *general* audience here. Write a few lines that explains the "helicopter view" of why this
module was are created.
The A Load Balancing Library (ALL) library aims to provide an easy way to include dynamic domain-based load balancing
into particle based simulation codes. The library is developed in the Simulation Laboratory Molecular Systems of the
Juelich Supercomputing Centre at Forschungszentrum Juelich.
Purpose of Module
_________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
This module provides an additional method to the ALL library, up-to-date descriptions of the methods in the library can
be found in the `ALL README file <https://gitlab.version.fz-juelich.de/SLMS/loadbalancing/blob/master/README.md>`_.
**Take the method description from the README and reproduce it here**
Background Information
______________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
See :ref:`ALL_background` for details.
Building and Testing
____________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
ALL uses the `CMake <https://cmake.org/runningcmake/>`_ build system, specific build and installation requirements can
be found in the `ALL README file <https://gitlab.version.fz-juelich.de/SLMS/loadbalancing/blob/master/README.md>`_.
**Need to provide information on how to test the particular method here.**
Source Code
___________
.. Notice the syntax of a URL reference below `Text <URL>`_ the backticks matter!
**Here link the source code *that is relevant for the module*. If you are using Github or GitLab and the `Gitflow
Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow>`_ you can point to your feature
branch. Linking to your pull/merge requests is even better. Otherwise you can link to the explicit commits or locations
in the source code.**
.. _ReST: http://www.sphinx-doc.org/en/stable/rest.html
.. _Sphinx: http://www.sphinx-doc.org/en/stable/markup/index.html
.. In ReStructured Text (ReST) indentation and spacing are very important (it is how ReST knows what to do with your
document). For ReST to understand what you intend and to render it correctly please to keep the structure of this
template. Make sure that any time you use ReST syntax (such as for ".. sidebar::" below), it needs to be preceded
and followed by white space (if you see warnings when this file is built they this is a common origin for problems).
.. We allow the template to be standalone, so that the library maintainers add it in the right place
.. Firstly, let's add technical info as a sidebar and allow text below to wrap around it. This list is a work in
progress, please help us improve it. We use *definition lists* of ReST_ to make this readable.
.. sidebar:: Software Technical Information
Name
A Load Balancing Library (ALL)
Language
C++, Fortran interfaces available
Licence
`BSD 3-Clause <https://choosealicense.com/licenses/bsd-3-clause/>`_
Documentation Tool
No tool used in source code, repo documentation written in `Markdown <https://en.wikipedia.org/wiki/Markdown>`_
Application Documentation
See `ALL repository <https://gitlab.version.fz-juelich.de/SLMS/loadbalancing>`_
Relevant Training Material
None available
Software Module Developed by
Rene Halver
.. In the next line you have the name of how this module will be referenced in the main documentation (which you can
reference, in this case, as ":ref:`ALL_example`"). You *MUST* change the reference below from "ALL_method_example"
to something unique otherwise you will cause cross-referencing errors. The reference must come right before the
heading for the reference to work (so don't insert a comment between).
.. _ALL_tensor_method:
#########################
ALL Tensor-Product method
#########################
.. Let's add a local table of contents to help people navigate the page
.. contents:: :local:
.. Add an abstract for a *general* audience here. Write a few lines that explains the "helicopter view" of why this
module was are created.
The A Load Balancing Library (ALL) library aims to provide an easy way to include dynamic domain-based load balancing
into particle based simulation codes. The library is developed in the Simulation Laboratory Molecular Systems of the
Juelich Supercomputing Centre at Forschungszentrum Juelich.
Purpose of Module
_________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
This module provides an additional method to the ALL library, up-to-date descriptions of the methods in the library can
be found in the `ALL README file <https://gitlab.version.fz-juelich.de/SLMS/loadbalancing/blob/master/README.md>`_.
For the Tensor-Product method, the work on all processes is reduced over the cartesian planes in the systems. This work
is then equalized by adjusting the borders of the cartesian planes.
Background Information
______________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
See :ref:`ALL_background` for details.
Building and Testing
____________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
ALL uses the `CMake <https://cmake.org/runningcmake/>`_ build system, specific build and installation requirements can
be found in the `ALL README file <https://gitlab.version.fz-juelich.de/SLMS/loadbalancing/blob/master/README.md>`_.
**Need to provide information on how to test the particular method here.**
Source Code
___________
.. Notice the syntax of a URL reference below `Text <URL>`_ the backticks matter!
**Here link the source code *that is relevant for the module*. If you are using Github or GitLab and the `Gitflow
Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow>`_ you can point to your feature
branch. Linking to your pull/merge requests is even better. Otherwise you can link to the explicit commits or locations
in the source code.**
.. _ReST: http://www.sphinx-doc.org/en/stable/rest.html
.. _Sphinx: http://www.sphinx-doc.org/en/stable/markup/index.html
.. deIn ReStructured Text (ReST) indentation and spacing are very important (it is how ReST knows what to do with your
document). For ReST to understand what you intend and to render it correctly please to keep the structure of this
template. Make sure that any time you use ReST syntax (such as for ".. sidebar::" below), it needs to be preceded
and followed by white space (if you see warnings when this file is built they this is a common origin for problems).
.. Firstly, let's add technical info as a sidebar and allow text below to wrap around it. This list is a work in
progress, please help us improve it. We use *definition lists* of ReST_ to make this readable.
.. sidebar:: Software Technical Information
Name
RDF's via Visualize Molecular Dynamics.
Language
TCL scripting language.
Licence
See http://www.ks.uiuc.edu/Research/vmd/allversions/disclaimer.html
Documentation Tool
none
Application Documentation
http://www.ks.uiuc.edu/Research/vmd/current/docs.html
Relevant Training Material
http://www.ks.uiuc.edu/Research/vmd/current/docs.html
.. In the next line you have the name of how this module will be referenced in the main documentation (which you can
reference, in this case, as ":ref:`example`"). You *MUST* change the reference below from "example" to something
unique otherwise you will cause cross-referencing errors. The reference must come right before the heading for the
reference to work (so don't insert a comment between).
###########################################
Radial Distribution Functions for GC-AdResS
###########################################
.. Let's add a local table of contents to help people navigate the page
.. contents:: :local:
.. Add an abstract for a *general* audience here. Write a few lines that explains the "helicopter view" of why you are
creating this module. For example, you might say that "This module is a stepping stone to incorporating XXXX effects
into YYYY process, which in turn should allow ZZZZ to be simulated. If successful, this could make it possible to
produce compound AAAA while avoiding expensive process BBBB and CCCC."
Purpose of Module
_________________
One purpose of our project is to promote GC-AdResS as method which provides new insights and is not much more complex
and difficult to use.
In GC-AdResS simulations we introduce artificial interfaces, from atomistic to hybrid and hybrid to coarse grained. To make
sure that we indeed have an open system we have to check several properties, from structural to dynamic properties.
Radial distribution functions (RDF'S) are the easiest way to check the structural properties of the
simulation. This module is dedicated to describe a straight forward and easy way to generate them for the atomistic
regions in the GC-AdResS simulations. In the current implementation in GROMACS we have two geometric setups. One is radial
and the other is a slab like structure. We use VMD as the tool sof choice to calculate the RDF's.
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
Background Information
______________________
.. Keep the helper text below around in your module by just adding ".. " in front of it, which turns it into a comment
The most widespread tool for analysing molecular dynamics simulations is `VMD <http://www.ks.uiuc.edu/Research/vmd>`_).
The program is based on TCL and Tk scripting language. Documentation and tutorials can be found
here: `VMD Docs <http://www.ks.uiuc.edu/Research/vmd/current/docs.html>`_
The reference coordinates (center of the AdResS region, as defined in the GROMACS mdp input file), configuration (standard input GROMACS: conf.gro) and trajectory (standard output GROMACS: traj_comp.xtc) are necessary to run AdResS. And they have to be used for two essential analysis parts for AdResS. The structural part, the radial distribution functions of the simulated system.
And the second part with the help of the `Density Profile tool <https://github.com/tonigi/vmd_density_profile>`_ (repository contains a tutorial on how to use) show the diffusion of the molecules during the simulation.
The RDF plugin is described here: `<https://www.ks.uiuc.edu/Research/vmd/plugins/gofrgui/>`_.
All results can be stored as plain ASCII files, thus can be analysed via any plotting program.
CASE 1: RDF
- Since we apply the routine in a subspace, the normalization factor is wrong. The correcting factor can be obtained by calculating the RDF in the full atomistic case. Then the RDF in the same subspace (as in the AdResS) in the full atomistic case. The quotient can be used to re-normalize the AdResS RDF.
- Important: for the AdResS RDF the *update selection* option tick has to be used, and the PBC switched off.
- good case: the RDF's are exactly the same
- bad case: the RDF's are different somehow
CASE 2: Density Diffusion
- It is possible to define the different regions in the simulation box. Thus it is possible to look at the region specific density diffusion.
- To do that: one has to specify several time frames and calculate the average profiles, each one gives a ASCII file which (in the end) can be plotted together.
- The frame of reference is set by the slider in the main menu. (The update selection option has to be switched off.) The particles in that frame are tagged and then via the different time frames one follows their path.
- Good case: smooth regular and symmetric diffusion
- bad case: spikes at the interface and asymmetric diffusion might hint at an artificial interface between the different regions.
Example Collection
__________________
.. Notice the syntax of a URL reference below `Text <URL>`_
We basically work with the atom selection and use the pre-existing Radial Pair Distribution Function tool in VMD. One has to load the configuration file (standard is conf.gro) and the trajectory file (standard: traj_comp.xtc) via either *vmd conf.gro traj_compt.xtc* or the vmd GUI.
Example case (for the radial systems), this selection was used with the reference point being defined in the GROMACS input file.
::
x_ref = x-value of the center of the chosen AdResS region
y_ref = y-value of the center of the chosen AdResS region
z_ref = z-value of the center of the chosen AdResS region
radius: radius of the atomistic region
name "insert your choice of atom here" and (((x-x_ref)^2 + (y-y_ref)^2 + (z-z_ref)^2) < radius*radius )
For the slab structures:
::
at_start: start of the atomistic regions along the x axis
at_end: end of the atomistic regions along the x axis
hy_start: start of the hybrid regions along the x axis
hy_end: end of the hybrid regions along the x axis
name "insert your choice of atom here" and (x>at_start and x<at_end)
name "insert your choice of atom here" and ((x>hy_start and x<at_start) or (x>at_end and x<hy_end)
......@@ -280,6 +280,15 @@ The function is given in the phase-space representation and is the basis for any
**PIM_qcf** is a library of quantum correlation functions for computing system's time-dependent properties.
.. toctree::
:glob:
:maxdepth: 1
./modules/PIM_qtb/readme
**PIM_qtb** implements various classical and semi-classical methods based on Langevin dynamics (classical Langevin dynamics, Quantum Thermal Bath (QTB) and two variants of adaptive QTB (adQTB-r and adQTB-f). The generated trajectories can be used to sample initial conditions for intramolecular vibrational-energy redistribution (IVR) dynamics.
.. toctree::
:glob:
:maxdepth: 1
......
This diff is collapsed.
......@@ -44,7 +44,7 @@ Install
_______
1. Under the ``install`` folder, once the fortran compile is available, do ``./install_quantics``.
2. Once the quantics serial version is correctely installed, in the same folder, do ``source QUANTICS_client``.
2. Once the quantics serial version is correctly installed, in the same folder, do ``source QUANTICS_client``.
3. Run ``compile -O quantics`` in order to install the OpenMP version of Quantics.
......
......@@ -88,4 +88,4 @@ project or implementing a redesign) we advise the creation of a `Software Requir
this and provide an overarching structure.
In addition, when dealing with numerical methods the creation of adequate tests can be difficult since bit-wise
reproducability of results is frequently not possible due to floating point precision and/or the use of random numbers.
reproducibility of results is frequently not possible due to floating point precision and/or the use of random numbers.
......@@ -64,7 +64,7 @@ specific things that need to be considered that impact the software development
.. * Applications and Libraries
.. * Portability and Optimisation
.. * Scalability
.. * Reproducability
.. * Reproducibility
.. * Hardware
.. * General Architecture
.. * Where is the compute power on modern HPC machines?
......
......@@ -115,6 +115,9 @@ todo_include_todos = True