Add usage container documentation#25
Conversation
|
|
||
| ```bash | ||
| # Build Apptainer image | ||
| apptainer build haddock3_mpi.sif docker://ghcr.io/haddocking/haddock3:2025.8.0 |
There was a problem hiding this comment.
Is apptainer expected to be installed by default on an HPC system? Should the user install it in case it is not present? Some additional info required here
There was a problem hiding this comment.
This has been updated now. I have clarified that building Apptainer images may require elevated privileges and is often restricted on HPC systems, and added guidance to build the SIF image on a local Linux system and transfer it to the HPC system for execution.
|
|
||
| ```bash | ||
|
|
||
| apptainer build --build-arg HADDOCK_VERSION=1.0.0 \ |
There was a problem hiding this comment.
I would put an existing version number here, the latest one available
There was a problem hiding this comment.
I have updated the Apptainer build example to use the latest available HADDOCK3 release (2025.11.0) instead of a placeholder version number.
| - **Host**: Linux with Apptainer or Singularity installed (local machine or HPC environment) | ||
| - **Disk**: ≥ 2 GB free for building | ||
| - **Python**: 3.10+ (inside container) | ||
| - **Permissions:** Root (sudo) privileges are required to build Apptainer images locally. |
There was a problem hiding this comment.
This will most likely never be granted on an HPC system... How usable is this then?
There was a problem hiding this comment.
You need superuser to build the image, not to execute - so you should build it in a machine where you have sudo and then transfer to the supercomputer. This should indeed be clarified here
There was a problem hiding this comment.
Thank you for pointing this out.The documentation now explicitly states that the image should be built on a local Linux system where sudo access is available and then transferred to the HPC system for execution.
|
|
||
| ### 3. MPI run mode | ||
|
|
||
| When using multiple CPUs or running across multiple nodes, **HADDOCK3 must be executed in MPI mode**. |
There was a problem hiding this comment.
When running multiple CPUs on the same node, there is no need for MPI mode. HADDOCK3 can be simply run in local mode
There was a problem hiding this comment.
Documentation has been added to reflect the same information in the form of a note
| export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/openmpi/lib:$LD_LIBRARY_PATH | ||
|
|
||
| %arguments | ||
| HADDOCK_VERSION=2025.9.1 # Example HADDOCK3 version (can be overridden during build) |
There was a problem hiding this comment.
definition file is now updated to reflect the latest version.
| # Ensure the working directory is set correctly | ||
| apptainer run | ||
| /path/to/haddock3_image.sif \ | ||
| haddock3 your-docking-config.cfg |
There was a problem hiding this comment.
May-be some comments here to specify that the cfg file setting must match the total number of cores available (i.e. ncore must be set to 3x120 in this example (360) and the execution mode to mpi:
# execution mode
mode = "mpi"
# 3 nodes x 120 tasks = ncores = 360
ncores = 360
There was a problem hiding this comment.
I have added a comment in the script explaining that for MPI runs, the .cfg file must match the allocated HPC resources, with ncore set to the total number of available cores and the execution mode set to mpi.
This PR adds a new documentation directory (USAGE-CONTAINER) detailing how to use Haddock 3 within containerized environments. It covers setup instructions, integration examples, and reproducibility best practices. This aims to support users deploying Haddock in modular workflows, especially in HPC. Few paths are provisional and will be updated once a final location is designated.