You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guide/execution/quickrun_execution.rst
+24-29Lines changed: 24 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,34 +3,25 @@
3
3
Execution with Quickrun
4
4
=======================
5
5
6
-
The planning and preparation of a campaign of alchemical simulations using the ``openfe`` package is intended to be
7
-
achievable on a local workstation in a matter of minutes.
8
-
The **execution** of these simulations however requires a large amount of computational power,
9
-
and beyond running single calculations locally,
10
-
is intended to be distributed across a HPC environment.
11
-
Doing this requires storing and sending the details of the simulation from the local workstation to a HPC environment,
12
-
this can be done via the :func:`.Transformation.dump` function which
13
-
:ref:`creates a saved "json" version of the data<dumping_transformations>`.
14
-
These serialised "json" files are the currency of executing a campaign of simulations,
15
-
and contain all the information required to execute a single simulation.
16
-
17
-
To read this information and execute the simulation, the command line interface provides a ``quickrun`` command,
18
-
the full details of which are given in :ref:`the CLI reference section<cli_quickrun>`.
19
-
Briefly, this command takes a "json" simulation as an input and will then execute the simulation contained within,
20
-
therefore this command would execute a simulation saved to a file called "transformation.json".
6
+
The planning and preparation of a campaign of alchemical simulations using ``openfe`` is intended to be achievable on a local workstation in a matter of minutes.
7
+
The *execution* of these simulations however requires a large amount of computational power, and beyond running single calculations locally, is intended to be distributed across a HPC environment.
8
+
Doing this requires storing and sending the details of the simulation from the local workstation to a HPC environment, which can be done via the :func:`.Transformation.to_json` function which :ref:`creates a saved JSON version of the data<dumping_transformations>`.
9
+
These serialized JSON files are the currency of executing a campaign of simulations and contain all the information required to execute a single simulation.
10
+
11
+
To read the ``Transformation`` information and execute the simulation, the command line interface provides the ``openfe quickrun`` command, the full details of which are given in :ref:`the CLI reference section<cli_quickrun>`.
12
+
Briefly, this command takes in the ``Transformation`` information represented as JSON, then executes a simulation according to those specifications.
13
+
For example, the following command executes a simulation defined by ``transformation.json`` and produces a results file named ``results.json``.
Serial execution of multiple repeats of a transformation can be inefficient when simulation times are long.
51
-
Higher throughput can be achieved with parallel execution by running one repeat per HPC job. Most protocols are set up to
52
-
run three repeats in serial by default, but this can be changed by either:
53
-
43
+
Higher throughput can be achieved with parallel execution by running one repeat per HPC job.
44
+
Most protocols are set up to run three repeats in serial by default, but this can be changed by either:
45
+
54
46
1. Defining the protocol setting ``protocol_repeats`` - see the :ref:`protocol configuration guide <cookbook/choose_protocol.nblink>` for more details.
55
47
2. Using the ``openfe plan-rhfe-network`` (or ``plan-rbfe-network``) command line flag ``--n-protocol-repeats``.
56
48
57
-
Each transformation can then be executed multiple times via the
58
-
``openfe quickrun`` command to produce a set of repeats, however, you need to ensure to use unique results
59
-
files for each repeat to ensure they don't overwrite each other. We recommend using folders named ``results_x`` where x is 0-2
60
-
to store the repeated calculations as our :ref:`openfe gather <cli_gather>` command also supports this file structure.
49
+
Each transformation can then be executed multiple times via the ``openfe quickrun`` command to produce a set of repeats.
50
+
However, **you must use unique results files for each repeat to ensure they don't overwrite each other**.
51
+
We recommend using folders named ``results_x`` where x is 0-2 to store the repeated calculations as our :ref:`openfe gather <cli_gather>` command also supports this file structure.
61
52
62
-
Here is an example of a simple script that will create and submit a separate job script (``\*.job`` named file)
63
-
for every alchemical transformation (for the simplest SLURM use case) in a network running each repeat in parallel and writing the
64
-
results to a unique folder:
53
+
Below is an example of a simple script that will create and submit a separate job script (``\*.job`` named file) for every alchemical transformation (for the simplest SLURM use case) in a network running each repeat in parallel and writing the results to a unique folder:
65
54
66
55
.. code-block:: bash
67
56
@@ -111,6 +100,12 @@ it to the root directory which includes the repeat results and it will automatic
111
100
112
101
openfe gather results_parallel
113
102
103
+
Optimizing GPU performance with NVIDIA MPS
104
+
==========================================
105
+
106
+
You can further optimize execution of ``openfe quickrun`` using NVIDIA's Multi-Process Service (MPS).
107
+
See NVIDIA's documentation on `MPS for OpenFE free energy calculations <https://developer.nvidia.com/blog/maximizing-openmm-molecular-dynamics-throughput-with-nvidia-multi-process-service/?ref=blog.omsf.io#mps_for_openfe_free_energy_calculations>`_ for details.
0 commit comments