Commit 22760b42 authored by Studer Gabriel's avatar Studer Gabriel
Browse files

Merge branch 'release-3.1.0'

parents a7fd92d3 42bde349
......@@ -5,6 +5,13 @@
Changelog
================================================================================
Release 3.1.0
--------------------------------------------------------------------------------
* Introduce alignment processing steps in BuildRawModel
* Several minor bug fixes, improvements, and speed-ups.
Release 3.0.0
--------------------------------------------------------------------------------
......
......@@ -24,7 +24,7 @@ include(PROMOD3)
# versioning info
set(PROMOD3_VERSION_MAJOR 3)
set(PROMOD3_VERSION_MINOR 0)
set(PROMOD3_VERSION_MINOR 1)
set(PROMOD3_VERSION_PATCH 0)
set(PROMOD3_VERSION_STRING ${PROMOD3_VERSION_MAJOR}.${PROMOD3_VERSION_MINOR})
set(PROMOD3_VERSION_STRING ${PROMOD3_VERSION_STRING}.${PROMOD3_VERSION_PATCH})
......
ARG OPENSTRUCTURE_VERSION="2.0.0"
ARG OPENSTRUCTURE_VERSION="2.0.0-bionic"
FROM registry.scicore.unibas.ch/schwede/openstructure:${OPENSTRUCTURE_VERSION}
# ARGUMENTS
###########
ARG PROMOD_VERSION="3.0.0"
ARG PROMOD_VERSION="3.1.0"
ARG SRC_FOLDER="/usr/local/src"
......
BootStrap: docker
From: registry.scicore.unibas.ch/schwede/promod3:3.0.0
From: registry.scicore.unibas.ch/schwede/promod3:3.1.0-OST2.0.0-bionic
%post
##############################################################################
# POST
......
......@@ -40,7 +40,7 @@ The currently preferred versions are:
* |python|_ 3.6.0
* |boost|_ 1.68.0
* |eigen3|_ 3.3.1
* |sphinx|_ 1.3.1
* |sphinx|_ 1.4.9
--------------------------------------------------------------------------------
Using |cmake|
......
......@@ -15,7 +15,7 @@
|project| and Containers
======================
========================
|project| offers build recipes for Docker and Singularity in
......
.. Copyright (c) 2013-2020, SIB - Swiss Institute of Bioinformatics and
.. Biozentrum - University of Basel
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
.. http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
.. _building-promod:
Building |project|
================================================================================
--------------------------------------------------------------------------------
Dependencies
--------------------------------------------------------------------------------
|project| is build on top of |ost_l|_ (|ost_s|), requiring at least version
|ost_version|. |ost_s| must be configured and compiled with ``ENABLE_MM=1`` to
use |openmm|_. To create the build system, |cmake|_ is required. The same
versions of |python|_ and |boost|_ are needed as used in |ost_s|. For |eigen3|_
we need at least version 3.3.0. To build the documentation, |sphinx|_ is
required. We do not provide backwards compatibility to Python 2.7. The last
release supporting Python 2.7 is 2.1.0 which also requires |ost_s| to be
compiled with Python 2.7.
The currently preferred versions are:
* |ost_s|_ |ost_version|
* |openmm|_ 7.1.1
* |cmake|_ 3.12.1
* |python|_ 3.6.0
* |boost|_ 1.68.0
* |eigen3|_ 3.3.1
* |sphinx|_ 1.3.1
--------------------------------------------------------------------------------
Using |cmake|
--------------------------------------------------------------------------------
|cmake| is used to configure the build system and in the end produces makefiles
and certain directories needed for building |project|. Basically it is called
right from a shell with the directory containing the top-level
:file:`CMakeLists.txt` as an argument. The preferred approach is to generate a
build folder and configure and compile in there:
.. code-block:: console
# execute this in the ProMod3 root folder
$ mkdir build
$ cd build
$ cmake .. -DOST_ROOT=<PATH TO OST>
For us, at least pointer to the |ost_s| installation directory is needed,
handed over to |cmake| by ``-D`` into the variable ``OST_ROOT`` (e.g. |ost_s|
headers would be located in ``OST_ROOT/include/ost``).
Similarly, one can specify folders for |boost|, |python| and |eigen3|
if multiple versions exist and/or they are not installed in a default location.
These are set with the ``BOOST_ROOT`` (make sure that's the same as for |ost_s|),
``PYTHON_ROOT`` and ``EIGEN3_INCLUDE_DIR``.
Here is a list of more options used within |project|:
* ``DISABLE_DOCUMENTATION`` Don't build documentation, don't search for |sphinx|
* ``DISABLE_DOCTEST`` Don't run example code from documentation on
``make check`` (implicit by ``DISABLE_DOCUMENTATION``)
* ``DISABLE_LINKCHECK`` Don't test links from documentation on ``make check``
(implicit by ``DISABLE_DOCUMENTATION``)
* ``ENABLE_SSE`` Allow for more agressive optimization by adding -msse4 flag to
the compiler. At some places within the code, we use SSE intrinsics explicitely.
This is only enabled if |ost_s| has been compiled with single precision.
(``OST_DOUBLE_PRECISION`` flag)
Since we use |ost_s| in the background, some of its options for |cmake| are
also relevant, here. Basically they need to be set to exactly the same value.
Even if |project| builds with different settings, it may start producing funny
results at an unexpected point. If you do not know the values, grep the option
in the :file:`CMakeCache.txt` of |ost_s|:
* ``OPTIMIZE``
* ``OST_DOUBLE_PRECISION``
.. doesn't work (yet?)
Instead of providing all those options at the command line, you can also use
``ccmake`` instead of ``cmake``, which allows you to set the |cmake| variables
interactively. Press 'c' to try to configure the build. If it fails, enter the
requested paths and configure again. Advanced settings can be edited by
pressing 't'.
Instead of calling |cmake| by yourself, there is the :file:`conf-scripts`
directory, providing smallish scripts to invoke |cmake| the right way for
various systems. Usually those scripts just need the |ost_s| path
and the location of the top-level :file:`CMakeLists.txt`.
As mentioned earlier, we highly recommend to use out-of-source builds.
This way, you can have several builds with different configurations. Also if
anything goes wrong, just remove the build directory to get to a clean state
again. No searching for |cmake| cache files or checking if certain files
really got rebuild and similar things required.
--------------------------------------------------------------------------------
Running Make
--------------------------------------------------------------------------------
After configuring, you want to build |project| by
.. code-block:: console
$ make
to populate the :file:`stage` directory with a ready-to-go version of the
latest code.
.. index::
single: Make targets
Beside the usual ``make all`` and other default targets, there are a few
special targets:
* ``check`` :index:`make check` Runs unit tests and if |cmake| was invoked in
its standard configuration also documentation examples (``doctest``) and
links in the doc. (``linkcheck``) are checked
* ``html`` :index:`make html` Creates documentation as web page using the
|sphinx| ``html`` builder
* ``man`` :index:`make man` Creates a manual page using the |sphinx| ``man``
builder
* ``doc`` :index:`make doc` Creates documentation using the ``html`` and
``man`` targets
* ``help`` :index:`make help` Prints a list of targets available
--------------------------------------------------------------------------------
Installing |project|
--------------------------------------------------------------------------------
If you wish to install |project| (note that you can also safely keep it all in
the :file:`stage` directory), you can use
.. code-block:: console
$ make install
By default, this will copy the :file:`stage` directory to :file:`/usr/local`. To
override this, you can add the ``-DCMAKE_INSTALL_PREFIX=<INSTALL PATH>`` flag to
your ``cmake`` call.
After the installation, you should be able to delete the whole source folder. To
ensure that everything works, you can use a set of automated "sanity checks".
Please follow the instructions in :file:`extras/sanity_checks/README` to setup
and run those tests after moving the source folder. If everything works, you can
safely delete the whole source folder.
.. |qmean| replace:: QMEAN
.. |eigen3| replace:: Eigen 3
.. |openmm| replace:: OpenMM
.. _qmean: https://swissmodel.expasy.org/qmean/
.. _ost_l: https://www.OpenStructure.org
.. _cmake: https://cmake.org/
.. _python: https://www.python.org/
.. _boost: https://www.boost.org/
.. _eigen3: http://eigen.tuxfamily.org/index.php?title=Main_Page
.. _openmm: http://openmm.org
.. LocalWords: cmake makefiles CMakeLists txt DOCTEST LINKCHECK conf html
.. LocalWords: doctest linkcheck qmean DQMEAN eigen CMakeCache
.. LocalWords: OPTIMIZE
.. Copyright (c) 2013-2020, SIB - Swiss Institute of Bioinformatics and
.. Biozentrum - University of Basel
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
.. http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
.. _building-promod:
Building |project|
================================================================================
--------------------------------------------------------------------------------
Dependencies
--------------------------------------------------------------------------------
|project| is build on top of |ost_l|_ (|ost_s|), requiring at least version
|ost_version|. |ost_s| must be configured and compiled with ``ENABLE_MM=1`` to
use |openmm|_. To create the build system, |cmake|_ is required. The same
versions of |python|_ and |boost|_ are needed as used in |ost_s|. For |eigen3|_
we need at least version 3.3.0. To build the documentation, |sphinx|_ is
required. We do not provide backwards compatibility to Python 2.7. The last
release supporting Python 2.7 is 2.1.0 which also requires |ost_s| to be
compiled with Python 2.7.
The currently preferred versions are:
* |ost_s|_ |ost_version|
* |openmm|_ 7.1.1
* |cmake|_ 3.12.1
* |python|_ 3.6.0
* |boost|_ 1.68.0
* |eigen3|_ 3.3.1
* |sphinx|_ 1.3.1
--------------------------------------------------------------------------------
Using |cmake|
--------------------------------------------------------------------------------
|cmake| is used to configure the build system and in the end produces makefiles
and certain directories needed for building |project|. Basically it is called
right from a shell with the directory containing the top-level
:file:`CMakeLists.txt` as an argument. The preferred approach is to generate a
build folder and configure and compile in there:
.. code-block:: console
# execute this in the ProMod3 root folder
$ mkdir build
$ cd build
$ cmake .. -DOST_ROOT=<PATH TO OST>
For us, at least pointer to the |ost_s| installation directory is needed,
handed over to |cmake| by ``-D`` into the variable ``OST_ROOT`` (e.g. |ost_s|
headers would be located in ``OST_ROOT/include/ost``).
Similarly, one can specify folders for |boost|, |python| and |eigen3|
if multiple versions exist and/or they are not installed in a default location.
These are set with the ``BOOST_ROOT`` (make sure that's the same as for |ost_s|),
``PYTHON_ROOT`` and ``EIGEN3_INCLUDE_DIR``.
Here is a list of more options used within |project|:
* ``DISABLE_DOCUMENTATION`` Don't build documentation, don't search for |sphinx|
* ``DISABLE_DOCTEST`` Don't run example code from documentation on
``make check`` (implicit by ``DISABLE_DOCUMENTATION``)
* ``DISABLE_LINKCHECK`` Don't test links from documentation on ``make check``
(implicit by ``DISABLE_DOCUMENTATION``)
* ``ENABLE_SSE`` Allow for more agressive optimization by adding -msse4 flag to
the compiler. At some places within the code, we use SSE intrinsics explicitely.
This is only enabled if |ost_s| has been compiled with single precision.
(``OST_DOUBLE_PRECISION`` flag)
Since we use |ost_s| in the background, some of its options for |cmake| are
also relevant, here. Basically they need to be set to exactly the same value.
Even if |project| builds with different settings, it may start producing funny
results at an unexpected point. If you do not know the values, grep the option
in the :file:`CMakeCache.txt` of |ost_s|:
* ``OPTIMIZE``
* ``OST_DOUBLE_PRECISION``
.. doesn't work (yet?)
Instead of providing all those options at the command line, you can also use
``ccmake`` instead of ``cmake``, which allows you to set the |cmake| variables
interactively. Press 'c' to try to configure the build. If it fails, enter the
requested paths and configure again. Advanced settings can be edited by
pressing 't'.
Instead of calling |cmake| by yourself, there is the :file:`conf-scripts`
directory, providing smallish scripts to invoke |cmake| the right way for
various systems. Usually those scripts just need the |ost_s| path
and the location of the top-level :file:`CMakeLists.txt`.
As mentioned earlier, we highly recommend to use out-of-source builds.
This way, you can have several builds with different configurations. Also if
anything goes wrong, just remove the build directory to get to a clean state
again. No searching for |cmake| cache files or checking if certain files
really got rebuild and similar things required.
--------------------------------------------------------------------------------
Running Make
--------------------------------------------------------------------------------
After configuring, you want to build |project| by
.. code-block:: console
$ make
to populate the :file:`stage` directory with a ready-to-go version of the
latest code.
.. index::
single: Make targets
Beside the usual ``make all`` and other default targets, there are a few
special targets:
* ``check`` :index:`make check` Runs unit tests and if |cmake| was invoked in
its standard configuration also documentation examples (``doctest``) and
links in the doc. (``linkcheck``) are checked
* ``html`` :index:`make html` Creates documentation as web page using the
|sphinx| ``html`` builder
* ``man`` :index:`make man` Creates a manual page using the |sphinx| ``man``
builder
* ``doc`` :index:`make doc` Creates documentation using the ``html`` and
``man`` targets
* ``help`` :index:`make help` Prints a list of targets available
--------------------------------------------------------------------------------
Installing |project|
--------------------------------------------------------------------------------
If you wish to install |project| (note that you can also safely keep it all in
the :file:`stage` directory), you can use
.. code-block:: console
$ make install
By default, this will copy the :file:`stage` directory to :file:`/usr/local`. To
override this, you can add the ``-DCMAKE_INSTALL_PREFIX=<INSTALL PATH>`` flag to
your ``cmake`` call.
After the installation, you should be able to delete the whole source folder. To
ensure that everything works, you can use a set of automated "sanity checks".
Please follow the instructions in :file:`extras/sanity_checks/README` to setup
and run those tests after moving the source folder. If everything works, you can
safely delete the whole source folder.
.. |qmean| replace:: QMEAN
.. |eigen3| replace:: Eigen 3
.. |openmm| replace:: OpenMM
.. _qmean: https://swissmodel.expasy.org/qmean/
.. _ost_l: https://www.OpenStructure.org
.. _cmake: https://cmake.org/
.. _python: https://www.python.org/
.. _boost: https://www.boost.org/
.. _eigen3: http://eigen.tuxfamily.org/index.php?title=Main_Page
.. _openmm: http://openmm.org
.. LocalWords: cmake makefiles CMakeLists txt DOCTEST LINKCHECK conf html
.. LocalWords: doctest linkcheck qmean DQMEAN eigen CMakeCache
.. LocalWords: OPTIMIZE
.. Copyright (c) 2013-2020, SIB - Swiss Institute of Bioinformatics and
.. Biozentrum - University of Basel
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
.. http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
Docker
======
|project|'s Own Docker Registry
-------------------------------
For the current stable release of |project|, its
`GitLab project <https://git.scicore.unibas.ch/schwede/ProMod3>`_ is equipped with its own
`registry for Docker images <https://git.scicore.unibas.ch/schwede/ProMod3/container_registry>`_. There you
can explore the current tag and simply pull a ready made built:
.. code-block:: bash
docker pull registry.scicore.unibas.ch/schwede/promod3:<TAG>
Build Docker Image
------------------
In order to build the image:
.. code-block:: bash
docker build --tag <IMAGE_NAME> -f Dockerfile <PATH_TO_DOCKERFILE_DIR>
You can chose any image name (tag) eg. promod.
Run scripts and actions with pm executable
------------------------------------------
If script or action requires some external files eg. PDBs, they have to be located in the
path accessible via mounted volume and should be accessed via docker (NOT LOCAL)
path. Eg. assuming that we have a struc.pdb file in /home/<USER>/pdbs directory and
a script.py in /home/<USER> we could mount the /home/<USER> to /home in docker as
above by specifying -v /home/<USER>:/home. To run the script we thus need to
provide the (relative) path to the script and (relative) path to the file eg:
.. code-block:: bash
docker run --rm -v /home/<USER>:/home <IMAGE_NAME> script.py \
pdbs/struct.pdb
or with absolute paths:
.. code-block:: bash
docker run --rm -v /home/<USER>:/home <IMAGE_NAME> /home/script.py \
/home/pdbs/struct.pdb
An alternative is to mount the current working directory into the docker home:
.. code-block:: bash
docker run --rm -v $(pwd):/home <IMAGE_NAME> script.py pdbs/struct.pdb
.. _docker_compound_lib:
The Compound Library
--------------------
At build time of the container, a :class:`~ost.conop.CompoundLib` is generated.
Compound libraries contain information on chemical compounds, such as their
connectivity, chemical class and one-letter-code. The compound library has
several uses, but the most important one is to provide the connectivy
information for the rule-based processor.
The compound library is generated with the components.cif dictionary provided by
the PDB. As the PDB updates regularly, the compound library shipped with the
container is quickly outdated. For most use cases, this is not problematic.
However, if you rely on correct connectivity information of the latest and
greatest compounds, you have to keep the compound library up to date manually.
The suggested way of doing this is to generate your own compound library and
mount it into the container where the original compound lib resides to
override it.
The simplest way to create a compound library is to use the
:program:`chemdict_tool` available in the container. The program allows you
to import the chemical description of the compounds from a mmCIF dictionary,
e.g. the components.cif dictionary provided by the PDB.
The latest dictionary can be downloaded from the
`wwPDB site <http://www.wwpdb.org/ccd.html>`_.
The files are rather large, it is therefore recommended to download the
gzipped version.
After downloading the file use :program:`chemdict_tool` in the container to
convert the mmCIF dictionary into our internal format:
.. code-block:: bash
docker run --rm -v $(pwd):/home --entrypoint chemdict_tool <IMAGE_NAME> \
create components.cif.gz compounds.chemlib
To run a script with the upated compound library, use the -v option for mounting/overriding:
.. code-block:: bash
docker run --rm -v /home/<USER>:/home \
-v <COMPLIB_DIR_LOCALHOST>/compounds.chemlib:<COMPLIB_DIR_CONTAINER>/compounds.chemlib \
<IMAGE_NAME> script.py pdbs/struct.pdb
with COMPLIB_DIR_LOCALHOST being the directory that contains the newly generated
compound library with name compounds.chemlib and COMPLIB_DIR_CONTAINER the
according path in the container.
If you didnt change anything in the Dockerfile, the latter should be
/usr/local/share/openstructure
You can check whether the default lib is successfully overriden by looking at the
output when running a Python script with following code in the container:
.. code-block:: python
import promod3 # required to setup default lib
from ost import conop
lib = conop.GetDefaultLib()
print(lib.GetCreationDate())
.. Copyright (c) 2013-2020, SIB - Swiss Institute of Bioinformatics and
.. Biozentrum - University of Basel
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
.. http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
Docker
======
|project|'s Own Docker Registry
-------------------------------
For the current stable release of |project|, its
`GitLab project <https://git.scicore.unibas.ch/schwede/ProMod3>`_ is equipped with its own
`registry for Docker images <https://git.scicore.unibas.ch/schwede/ProMod3/container_registry>`_. There you
can explore the current tag and simply pull a ready made built:
.. code-block:: bash
docker pull registry.scicore.unibas.ch/schwede/promod3:<TAG>
Build Docker Image
------------------
In order to build the image:
.. code-block:: bash
docker build --tag <IMAGE_NAME> -f Dockerfile <PATH_TO_DOCKERFILE_DIR>
You can chose any image name (tag) eg. promod.
Run scripts and actions with pm executable
------------------------------------------
If script or action requires some external files eg. PDBs, they have to be located in the
path accessible via mounted volume and should be accessed via docker (NOT LOCAL)
path. Eg. assuming that we have a struc.pdb file in /home/<USER>/pdbs directory and
a script.py in /home/<USER> we could mount the /home/<USER> to /home in docker as
above by specifying -v /home/<USER>:/home. To run the script we thus need to
provide the (relative) path to the script and (relative) path to the file eg:
.. code-block:: bash
docker run --rm -v /home/<USER>:/home <IMAGE_NAME> script.py \
pdbs/struct.pdb
or with absolute paths:
.. code-block:: bash
docker run --rm -v /home/<USER>:/home <IMAGE_NAME> /home/script.py \
/home/pdbs/struct.pdb
An alternative is to mount the current working directory into the docker home:
.. code-block:: bash
docker run --rm -v $(pwd):/home <IMAGE_NAME> script.py pdbs/struct.pdb
.. _docker_compound_lib:
The Compound Library
--------------------
At build time of the container, a :class:`~ost.conop.CompoundLib` is generated.
Compound libraries contain information on chemical compounds, such as their