Skip to content
Snippets Groups Projects
Commit 22760b42 authored by Studer Gabriel's avatar Studer Gabriel
Browse files

Merge branch 'release-3.1.0'

parents a7fd92d3 42bde349
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1586 additions and 1579 deletions
CHANGELOG
+ 7
− 0
View file @ 22760b42
......@@ -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
--------------------------------------------------------------------------------
......
CMakeLists.txt
+ 1
− 1
View file @ 22760b42
......@@ -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})
......
container/Dockerfile
+ 2
− 2
View file @ 22760b42
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"
......
container/Singularity
+ 1
− 1
View file @ 22760b42
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
......
doc/buildsystem.rst
+ 1
− 1
View file @ 22760b42
......@@ -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|
......
doc/container/index.rst
+ 1
− 1
View file @ 22760b42
......@@ -15,7 +15,7 @@
|project| and Containers
======================
========================
|project| offers build recipes for Docker and Singularity in
......
doc/html/_sources/buildsystem.rst.txt → doc/html/_sources/buildsystem.txt
+ 172
− 172
View file @ 22760b42
.. 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
doc/html/_sources/container/docker.rst.txt → doc/html/_sources/container/docker.txt
+ 134
− 134
View file @ 22760b42
.. 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
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())
doc/html/_sources/container/index.rst.txt → doc/html/_sources/container/index.txt
+ 36
− 36
View file @ 22760b42
.. 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.
|project| and Containers
======================
|project| offers build recipes for Docker and Singularity in
<PATH_TO_PROMOD3_CHECKOUT>/container. To avoid code duplication,
the Singularity container bootstraps from the Docker one and adds
some sugar on top.
.. toctree::
:maxdepth: 1
Docker <docker>
Singularity <singularity>
.. 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.
|project| and Containers
========================
|project| offers build recipes for Docker and Singularity in
<PATH_TO_PROMOD3_CHECKOUT>/container. To avoid code duplication,
the Singularity container bootstraps from the Docker one and adds
some sugar on top.
.. toctree::
:maxdepth: 1
Docker <docker>
Singularity <singularity>
doc/html/_sources/container/singularity.rst.txt → doc/html/_sources/container/singularity.txt
+ 90
− 90
View file @ 22760b42
.. 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.
Singularity
===========
We do not provide a "standalone" Singularity image, but rather bootstrap from a
Docker image.
Build the image with:
.. code-block:: bash
sudo singularity build promod.img Singularity
Available apps
--------------
This container includes the following apps:
* **OST** - OpenStructure executable
* **PM** - |project| executable
* **IPython** - OST/|project|-powered iPython shell
* **Notebook** - A Jupyter notebook playground with OST, |project| and nglview
* **lDDT** - The Local Distance Difference Test
* **Molck** - Molecular checker
* **ChemdictTool** - Creating or update a compound library
To see the help for each individual app run:
.. code-block:: bash
singularity run-help --app <APP NAME> <PATH TO PROMOD IMAGE>
Eg.:
.. code-block:: bash
singularity run-help --app PM promod.img
To list all available |project| modelling actions:
.. code-block:: bash
singularity run --app PM promod.img help
The Compound Library
--------------------
You'll have the exact same problem with outdated compound libraries as in the
raw Docker image. You can find more information on that matter in the Docker
section of the documentation: :ref:`docker_compound_lib`.
The same trick of mounting an up to date compound library from the local host into
the container applies. The two relevant commands for Singularity are building
a new library and mount it.
Build a new library:
.. code-block:: bash
singularity run --app ChemdictTool <IMAGE> create components.cif.gz \
compounds.chemlib
Run some script with an updated compound library from localhost:
.. code-block:: bash
singularity run \
-B <COMPLIB_DIR_LOCALHOST>/compounds.chemlib:<COMPLIB_DIR_CONTAINER>/compounds.chemlib \
--app PM <IMAGE> my_script.py
Same as for the Docker, if you didn't meddle with the original Dockerfile,
<COMPLIB_DIR_CONTAINER> should be /usr/local/share/openstructure.
<COMPLIB_DIR_LOCALHOST> is the directory that contains the compound lib with the
name compounds.chemlib that you created before. Make sure that everything works
as expected by executing the exact same lines of Python code as described
in the Docker documentation: :ref:`docker_compound_lib`.
.. 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.
Singularity
===========
We do not provide a "standalone" Singularity image, but rather bootstrap from a
Docker image.
Build the image with:
.. code-block:: bash
sudo singularity build promod.img Singularity
Available apps
--------------
This container includes the following apps:
* **OST** - OpenStructure executable
* **PM** - |project| executable
* **IPython** - OST/|project|-powered iPython shell
* **Notebook** - A Jupyter notebook playground with OST, |project| and nglview
* **lDDT** - The Local Distance Difference Test
* **Molck** - Molecular checker
* **ChemdictTool** - Creating or update a compound library
To see the help for each individual app run:
.. code-block:: bash
singularity run-help --app <APP NAME> <PATH TO PROMOD IMAGE>
Eg.:
.. code-block:: bash
singularity run-help --app PM promod.img
To list all available |project| modelling actions:
.. code-block:: bash
singularity run --app PM promod.img help
The Compound Library
--------------------
You'll have the exact same problem with outdated compound libraries as in the
raw Docker image. You can find more information on that matter in the Docker
section of the documentation: :ref:`docker_compound_lib`.
The same trick of mounting an up to date compound library from the local host into
the container applies. The two relevant commands for Singularity are building
a new library and mount it.
Build a new library:
.. code-block:: bash
singularity run --app ChemdictTool <IMAGE> create components.cif.gz \
compounds.chemlib
Run some script with an updated compound library from localhost:
.. code-block:: bash
singularity run \
-B <COMPLIB_DIR_LOCALHOST>/compounds.chemlib:<COMPLIB_DIR_CONTAINER>/compounds.chemlib \
--app PM <IMAGE> my_script.py
Same as for the Docker, if you didn't meddle with the original Dockerfile,
<COMPLIB_DIR_CONTAINER> should be /usr/local/share/openstructure.
<COMPLIB_DIR_LOCALHOST> is the directory that contains the compound lib with the
name compounds.chemlib that you created before. Make sure that everything works
as expected by executing the exact same lines of Python code as described
in the Docker documentation: :ref:`docker_compound_lib`.
doc/html/_sources/core/geometry.rst.txt → doc/html/_sources/core/geometry.txt
+ 157
− 157
View file @ 22760b42
.. 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.
Geometry functions
================================================================================
.. currentmodule:: promod3.core
.. function:: EvaluateGromacsPosRule(rule, number, anchors)
Constructs *number* positions with the given Gromacs rule and anchor positions
(see Gromacs manual for details).
:param rule: Gromacs rule
:type rule: :class:`int`
:param number: Desired number of positions (max. 3)
:type number: :class:`int`
:param anchors: Anchor positions (max. 4)
:type anchors: :class:`list` of :class:`~ost.geom.Vec3`
:return: Constructed *number* positions.
:rtype: :class:`list` of :class:`~ost.geom.Vec3`
.. function:: ConstructCTerminalOxygens(c_pos, ca_pos, n_pos)
Constructs positions of O and OXT atoms for C terminal.
:param c_pos: Position of C atom
:type c_pos: :class:`~ost.geom.Vec3`
:param n_pos: Position of nitrogen atom
:type n_pos: :class:`~ost.geom.Vec3`
:param ca_pos: Position of C-alpha atom
:type ca_pos: :class:`~ost.geom.Vec3`
:return: Positions of O and OXT atoms.
:rtype: :class:`tuple` of :class:`~ost.geom.Vec3`
.. function:: ConstructAtomPos(A, B, C, bond_length, angle, dihedral)
Constructs position of atom "D" based on bond length (C-D), angle (B-C-D) and
dihedral (A-B-C-D).
:param A: Position of atom A
:type A: :class:`~ost.geom.Vec3`
:param B: Position of atom B
:type B: :class:`~ost.geom.Vec3`
:param C: Position of atom C
:type C: :class:`~ost.geom.Vec3`
:param bond_length: Bond length (C-D)
:type bond_length: :class:`float`
:param angle: Angle (B-C-D)
:type angle: :class:`float`
:param dihedral: Dihedral (A-B-C-D)
:type dihedral: :class:`float`
:return: Position of atom D
:rtype: :class:`~ost.geom.Vec3`
.. function:: ConstructCBetaPos(n_pos, ca_pos, c_pos)
Constructs position of C-beta atom given the positions of the backbone nitrogen,
C-alpha and C atoms.
:param n_pos: Position of nitrogen atom
:type n_pos: :class:`~ost.geom.Vec3`
:param ca_pos: Position of C-alpha atom
:type ca_pos: :class:`~ost.geom.Vec3`
:param c_pos: Position of C atom
:type c_pos: :class:`~ost.geom.Vec3`
:return: Position of C-beta atom
:rtype: :class:`~ost.geom.Vec3`
.. function:: RotationAroundLine(axis, anchor, angle)
Creates a geometric transform leading to a rotation with specified `angle`
around a line defined by `axis` and `anchor`.
:param axis: Axis of rotation
:type axis: :class:`~ost.geom.Vec3`
:param anchor: Anchor for rotation
:type anchor: :class:`~ost.geom.Vec3`
:param angle: Angle (in radians in range [-pi,pi]) of rotation
:type angle: :class:`float`
:return: Transformation matrix
:rtype: :class:`~ost.geom.Mat4`
.. function:: RotationAroundLine(axis, angle)
Creates a 3x3 matrix for a rotation by a specified `angle` around an `axis`
going through the origin.
:param axis: Axis of rotation
:type axis: :class:`~ost.geom.Vec3`
:param angle: Angle (in radians in range [-pi,pi]) of rotation
:type angle: :class:`float`
:return: Rotation matrix
:rtype: :class:`~ost.geom.Mat3`
.. class:: StemCoords()
StemCoords(res)
Simple container class to store N, CA and C coordinates.
:param res: Residue handle from which to extract N, CA and C coordinates.
:type res: :class:`ost.mol.ResidueHandle`
:raises: :exc:`~exceptions.RuntimeError` if *res* does not contain N, CA and C
atoms.
.. attribute:: n_coord
ca_coord
c_coord
Position of nitrogen / alpha carbon / carbon atom.
:type: :class:`~ost.geom.Vec3`
.. class:: StemPairOrientation()
StemPairOrientation(n_stem, c_stem)
Relative orientation of a pair of stems. Can be used to define gaps with four
angles and one distance and is used in the fragment database for fast lookups.
:param n_stem: Coordinates of stem A.
:type n_stem: :class:`StemCoords`
:param c_stem: Coordinates of stem B.
:type c_stem: :class:`StemCoords`
.. attribute:: distance
Distance of C atom of stem A to N atom of stem B.
:type: :class:`float`
.. attribute:: angle_one
angle_two
Angles defining relative orientation of stem B with respect to stem A.
:type: :class:`float`
.. attribute:: angle_three
angle_four
Angles defining relative orientation of stem A with respect to stem B.
:type: :class:`float`
.. 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.
Geometry functions
================================================================================
.. currentmodule:: promod3.core
.. function:: EvaluateGromacsPosRule(rule, number, anchors)
Constructs *number* positions with the given Gromacs rule and anchor positions
(see Gromacs manual for details).
:param rule: Gromacs rule
:type rule: :class:`int`
:param number: Desired number of positions (max. 3)
:type number: :class:`int`
:param anchors: Anchor positions (max. 4)
:type anchors: :class:`list` of :class:`~ost.geom.Vec3`
:return: Constructed *number* positions.
:rtype: :class:`list` of :class:`~ost.geom.Vec3`
.. function:: ConstructCTerminalOxygens(c_pos, ca_pos, n_pos)
Constructs positions of O and OXT atoms for C terminal.
:param c_pos: Position of C atom
:type c_pos: :class:`~ost.geom.Vec3`
:param n_pos: Position of nitrogen atom
:type n_pos: :class:`~ost.geom.Vec3`
:param ca_pos: Position of C-alpha atom
:type ca_pos: :class:`~ost.geom.Vec3`
:return: Positions of O and OXT atoms.
:rtype: :class:`tuple` of :class:`~ost.geom.Vec3`
.. function:: ConstructAtomPos(A, B, C, bond_length, angle, dihedral)
Constructs position of atom "D" based on bond length (C-D), angle (B-C-D) and
dihedral (A-B-C-D).
:param A: Position of atom A
:type A: :class:`~ost.geom.Vec3`
:param B: Position of atom B
:type B: :class:`~ost.geom.Vec3`
:param C: Position of atom C
:type C: :class:`~ost.geom.Vec3`
:param bond_length: Bond length (C-D)
:type bond_length: :class:`float`
:param angle: Angle (B-C-D)
:type angle: :class:`float`
:param dihedral: Dihedral (A-B-C-D)
:type dihedral: :class:`float`
:return: Position of atom D
:rtype: :class:`~ost.geom.Vec3`
.. function:: ConstructCBetaPos(n_pos, ca_pos, c_pos)
Constructs position of C-beta atom given the positions of the backbone nitrogen,
C-alpha and C atoms.
:param n_pos: Position of nitrogen atom
:type n_pos: :class:`~ost.geom.Vec3`
:param ca_pos: Position of C-alpha atom
:type ca_pos: :class:`~ost.geom.Vec3`
:param c_pos: Position of C atom
:type c_pos: :class:`~ost.geom.Vec3`
:return: Position of C-beta atom
:rtype: :class:`~ost.geom.Vec3`
.. function:: RotationAroundLine(axis, anchor, angle)
Creates a geometric transform leading to a rotation with specified `angle`
around a line defined by `axis` and `anchor`.
:param axis: Axis of rotation
:type axis: :class:`~ost.geom.Vec3`
:param anchor: Anchor for rotation
:type anchor: :class:`~ost.geom.Vec3`
:param angle: Angle (in radians in range [-pi,pi]) of rotation
:type angle: :class:`float`
:return: Transformation matrix
:rtype: :class:`~ost.geom.Mat4`
.. function:: RotationAroundLine(axis, angle)
Creates a 3x3 matrix for a rotation by a specified `angle` around an `axis`
going through the origin.
:param axis: Axis of rotation
:type axis: :class:`~ost.geom.Vec3`
:param angle: Angle (in radians in range [-pi,pi]) of rotation
:type angle: :class:`float`
:return: Rotation matrix
:rtype: :class:`~ost.geom.Mat3`
.. class:: StemCoords()
StemCoords(res)
Simple container class to store N, CA and C coordinates.
:param res: Residue handle from which to extract N, CA and C coordinates.
:type res: :class:`ost.mol.ResidueHandle`
:raises: :exc:`~exceptions.RuntimeError` if *res* does not contain N, CA and C
atoms.
.. attribute:: n_coord
ca_coord
c_coord
Position of nitrogen / alpha carbon / carbon atom.
:type: :class:`~ost.geom.Vec3`
.. class:: StemPairOrientation()
StemPairOrientation(n_stem, c_stem)
Relative orientation of a pair of stems. Can be used to define gaps with four
angles and one distance and is used in the fragment database for fast lookups.
:param n_stem: Coordinates of stem A.
:type n_stem: :class:`StemCoords`
:param c_stem: Coordinates of stem B.
:type c_stem: :class:`StemCoords`
.. attribute:: distance
Distance of C atom of stem A to N atom of stem B.
:type: :class:`float`
.. attribute:: angle_one
angle_two
Angles defining relative orientation of stem B with respect to stem A.
:type: :class:`float`
.. attribute:: angle_three
angle_four
Angles defining relative orientation of stem A with respect to stem B.
:type: :class:`float`
doc/html/_sources/core/helper.rst.txt → doc/html/_sources/core/helper.txt
+ 51
− 51
View file @ 22760b42
.. 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.
:mod:`~promod3.core.helper` - Shared Functionality For the Everything
================================================================================
.. module:: promod3.core.helper
:synopsis: Helper functions
.. currentmodule:: promod3.core.helper
Introduction
--------------------------------------------------------------------------------
We collect functions here, which should be useful in many places but would make
rather empty modules left alone.
Messages
--------------------------------------------------------------------------------
.. literalinclude:: ../../../tests/doc/scripts/core_msg_error.py
.. autofunction:: MsgErrorAndExit
File Tests
--------------------------------------------------------------------------------
The following example parses an argument (call as ``pm SCRIPTNAME FILENAME``) as
a file name and checks whether it is a ``pdb`` or ``mmcif`` file.
.. literalinclude:: ../../../tests/doc/scripts/core_file_checks.py
.. autofunction:: FileExists
.. autofunction:: FileExtension
.. autofunction:: FileGzip
.. 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.
:mod:`~promod3.core.helper` - Shared Functionality For the Everything
================================================================================
.. module:: promod3.core.helper
:synopsis: Helper functions
.. currentmodule:: promod3.core.helper
Introduction
--------------------------------------------------------------------------------
We collect functions here, which should be useful in many places but would make
rather empty modules left alone.
Messages
--------------------------------------------------------------------------------
.. literalinclude:: ../../../tests/doc/scripts/core_msg_error.py
.. autofunction:: MsgErrorAndExit
File Tests
--------------------------------------------------------------------------------
The following example parses an argument (call as ``pm SCRIPTNAME FILENAME``) as
a file name and checks whether it is a ``pdb`` or ``mmcif`` file.
.. literalinclude:: ../../../tests/doc/scripts/core_file_checks.py
.. autofunction:: FileExists
.. autofunction:: FileExtension
.. autofunction:: FileGzip
doc/html/_sources/core/index.rst.txt → doc/html/_sources/core/index.txt
+ 35
− 35
View file @ 22760b42
.. 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.
:mod:`~promod3.core` - |project| Core Functionality
================================================================================
.. module:: promod3.core
:synopsis: Basic functionality, supporting standard tasks in your code.
This module gathers functions and classes which are not devoted to homology
modeling per se but cover standard programming issues.
Contents:
.. toctree::
:maxdepth: 2
pm3argparse
helper
geometry
runtime_profiling
graph_minimizer
.. 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.
:mod:`~promod3.core` - |project| Core Functionality
================================================================================
.. module:: promod3.core
:synopsis: Basic functionality, supporting standard tasks in your code.
This module gathers functions and classes which are not devoted to homology
modeling per se but cover standard programming issues.
Contents:
.. toctree::
:maxdepth: 2
pm3argparse
helper
geometry
runtime_profiling
graph_minimizer
doc/html/_sources/core/pm3argparse.rst.txt → doc/html/_sources/core/pm3argparse.txt
+ 59
− 59
View file @ 22760b42
.. 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.
:mod:`~promod3.core.pm3argparse` - Parsing Command Lines
================================================================================
.. module:: promod3.core.pm3argparse
:synopsis: Argument Parsing
.. currentmodule:: promod3.core.pm3argparse
Introduction
--------------------------------------------------------------------------------
A lot of the actions in |project| have a bunch of command line parameters/
arguments in common. For example we need an input alignment quite often and
usually for an alignment we need information on what is the target sequence,
what identifies a template sequence and eventually a hint on the format. That
means we need the same functionality on the command line in several actions.
There :class:`~promod3.core.pm3argparse.PM3ArgumentParser` serves as a
simplification. It provides a set of standard arguments you just need to
activate for your action plus it comes with some verification functionality for
input.
.. literalinclude:: ../../../tests/doc/scripts/core_pm3argparse.py
When the example above is run with ``pm`` and no additional arguments, the
script exits with a code 2. If it is run with an additional argument ``-h`` or
``--help``, it exits with a code 0 and displays the help message given as a
docstring in your script.
Argument Parser
--------------------------------------------------------------------------------
.. autoclass:: PM3ArgumentParser
:members:
.. automethod:: __init__
.. |descattr| replace:: :attr:`description`
.. |argpinit| replace:: :meth:`argparse.ArgumentParser.__init__`
.. |progattr| replace:: :attr:`prog`
.. |sysargv| replace:: :attr:`sys.argv`
.. LocalWords: currentmodule argparse ArgumentParser autoclass automethod
.. LocalWords: init descattr attr argpinit meth progattr prog
.. 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.
:mod:`~promod3.core.pm3argparse` - Parsing Command Lines
================================================================================
.. module:: promod3.core.pm3argparse
:synopsis: Argument Parsing
.. currentmodule:: promod3.core.pm3argparse
Introduction
--------------------------------------------------------------------------------
A lot of the actions in |project| have a bunch of command line parameters/
arguments in common. For example we need an input alignment quite often and
usually for an alignment we need information on what is the target sequence,
what identifies a template sequence and eventually a hint on the format. That
means we need the same functionality on the command line in several actions.
There :class:`~promod3.core.pm3argparse.PM3ArgumentParser` serves as a
simplification. It provides a set of standard arguments you just need to
activate for your action plus it comes with some verification functionality for
input.
.. literalinclude:: ../../../tests/doc/scripts/core_pm3argparse.py
When the example above is run with ``pm`` and no additional arguments, the
script exits with a code 2. If it is run with an additional argument ``-h`` or
``--help``, it exits with a code 0 and displays the help message given as a
docstring in your script.
Argument Parser
--------------------------------------------------------------------------------
.. autoclass:: PM3ArgumentParser
:members:
.. automethod:: __init__
.. |descattr| replace:: :attr:`description`
.. |argpinit| replace:: :meth:`argparse.ArgumentParser.__init__`
.. |progattr| replace:: :attr:`prog`
.. |sysargv| replace:: :attr:`sys.argv`
.. LocalWords: currentmodule argparse ArgumentParser autoclass automethod
.. LocalWords: init descattr attr argpinit meth progattr prog
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment