Re: [containerising NAMD with Singularity]

From: Josh Vermaas (
Date: Wed Oct 13 2021 - 08:57:23 CDT

Hi Maxim,

For single node jobs, wrapping up the precompiled multicore binaries
will likely be your best bet. However, for multinode jobs, it is likely
going to be easier for testing to use MPI backends, since that is the
far more common framework. There is even reasonable documentation for
how this is supposed to work with singularity:;!!DZ3fjg!qxymKdMN-43XC6BhN1S2Cl0I2Kifep9cyZE8tZw4MMH2ih3EZacE37EX8CA63oeq5g$ The downside to this
approach is that MPI+CUDA is a no-no with NAMD, and containerizing with
GPU support is one of the reasons you might prefer singularity over
docker. However, as Giacomo says, its usually not so bad to compile NAMD
for the handful of computing clusters you have access to.

In the handful of times I've needed to make a singularity container, my
usual workflow was to build the program interactively from within a
sandbox singularity container, adding dependencies as I went along.*build-images-from-scratch__;Iw!!DZ3fjg!qxymKdMN-43XC6BhN1S2Cl0I2Kifep9cyZE8tZw4MMH2ih3EZacE37EX8CCa_38tlw$


On 10/13/21 5:28 AM, Maxim Abalenkov wrote:
> Dear all,
> As part of my project I would like to containerise NAMD with
> Singularity to make it available on various HPC systems. At first I
> tried to utilise a pre-compiled NAMD binary: Linux-x86_64-ibverbs-smp
> (InfiniBand plus shared memory, no MPI needed) inside a container. I
> build my container from a definition file (md-centos.def). Please find
> it attached for a reference. According to a NAMD mailing list
> (*namd/mailing_list/namd-l.2020-2021/0310.html__;Lw!!HXCxUKc!j3RJZXL5DlTqYrU8yfi7niyn671McJnLm_tSTNIUt9ufYDZLw9JVZHoXAMxoaPs$
> ) I used the ibverbs-smp variant of the NAMD binary. To enable
> Charmrun I installed SSH onto the CentOS Linux inside my container.
> Currently I see the same error as the person on the mailing list
> (Please see the conversation thread using the link above). Charmrun is
> unable to connect to the individual nodes of the HPC system.
> To launch the containerised NAMD job on an HPC system I login to one
> of the nodes interactively with srun --pty /bin/bash. Once on a node a
> submit the Slurm job with sbatch < namd.slurm Please find the script
> file attached. The output of the failed run attempt is stored in
> multiple error log files: 01.log and namd-t.295873.log.
> While I’m waiting for a reply of our local system administrator, I
> thought I will investigate the problem further by trying to install
> NAMD inside a container from source. To compile Charm++ I use the
> “build" script from the "charm-6.10.2” archive with the following options:
> ./build charm++ verbs-linux-x86_64 gcc gfortran smp
> During the compilation I observe the fatal errors (infiniband/verbs.h:
> No such file or directory). These errors make me think, maybe the
> "verbs smp” variant of Charm++ is not the one to follow? It seems
> installing InfiniBand inside a container is an overkill. Plus it will
> require detailed knowledge of the underlying InfiniBand setup on a
> cluster. These setups will differ from cluster to cluster and
> therefore reduce the portability effect of a Singularity container.
> What would be your advice and recommendation? Is there a general
> guidance on preparing a container with NAMD? Now I’m inclined to
> trying MPI variants of Cham++ compilation. I hope these will be more
> portable.
> Thank you for your help and have a wonderful day ahead!
> —
> Best wishes,
> Maxim
> Maxim Abalenkov \\
> +44 7 486 486 505 \\
> <;!!DZ3fjg!oJ3b3zeJxN2Spsk0oV4OLDFo1s__mFd6Sgve8d-7T3ee7sLmdJTR8mRhOgl38lCTIw$>

Josh Vermaas
Assistant Professor, Plant Research Laboratory and Biochemistry and Molecular Biology
Michigan State University;!!DZ3fjg!qxymKdMN-43XC6BhN1S2Cl0I2Kifep9cyZE8tZw4MMH2ih3EZacE37EX8CCmfJzThg$ 

This archive was generated by hypermail 2.1.6 : Fri Dec 31 2021 - 23:17:11 CST