...
Column | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
(Note that the word PathToTheSingularityImage is only a placeholder for the real path to user's image.) Check our documentation about Singularity for further information about the use of containers.
As mentioned before, Pawsey provides OpenFOAM modules that make use of containerised versions of OpenFOAM on Setonix. One advantage of the use of these modules, as explained in the main page of the OpenFOAM documentation, is that the explicit use of the singularity command is not needed anymore. Nevertheless, users can still use the singularity
command to access the corresponding images if they prefer. The path and name of the corresponding images is defined by default in the variable SINGULARITY_CONTAINER
after loading the module. So, a similar example to the above would be:
...
Column | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
(Note that in this example, an imaged owned by the user is being used.)
Or, if the user wishes to open an interactive session within the container:
Column | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
(Note that in this example, the image provided by the containerised module is being used.)
And, of course, the singularity
command can be used within Slurm batch scripts. So, the execution command in the example script for the solver execution in the OpenFOAM: Example Slurm Batch Scripts page can be modified to explicitly use the singularity
command:
Column | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
(For the use of their own image, users should comment the line that loads the containerised module and uncomment the lines that load the singularity module and define the SINGULARITY_CONTAINER
variable as the real path to their own image. Obviously, the <VERSION>
and the real path should be adapted.)
Wrappers of the shell and exec commands
...
Information in the following sections may be useful if you are looking to build a new container with additional tools.
Use of
...
OpenFOAM versions
...
not provided by Pawsey
Note | ||
---|---|---|
| ||
First of all, it is important to reiterate that one of the most important best practices of OpenFOAM at Pawsey is to minimise the number of result files. For this, we strongly recommend users to upgrade their workflows to the most recent versions of OpenFOAM, which are capable of reducing the number of result files with the use of the |
As mentioned in the main documentation for OpenFOAM, several recent versions of OpenFOAM containers are already available in Setonix through modules. One advantage of these modules is that OpenFOAM tools and solvers are accessible through basic commands without the need of calling singularity
explicitly in the command line. The call to singularity is performed under the hood by the tool/solver's wrappers.
If users need a new version of OpenFOAM that is still not installed in our systems, please they can create their own container for that version, or can contact support so that we can make it available to users.
If users are still forced to use an old version of OpenFoam that is not installed in our systems, we recommend to use a container equipped with the needed version.
Pawsey has already built several Docker images with the main intention to serve as examples for users to builid their own images. Pawsey-provided Docker images are available through our registry in Red Hat Quay.io (https://quay.io/pawsey) in directories openfoam & openfoam-org. Other directories with the "-legacy" post-fix contain images built with operating-system versions that do not run properly on Setonix anymore. The corresponding building recipes (Dockerfiles) are at Pawsey GitHub repostory (https://github.com/PawseySC/pawsey-containers). As said, users should use these recipes as examples to build their own.
...
- Get access to (or install) Docker within your own institution Linux environment.
- Download the building recipe (Dockerfile) that is closer to the version of OpenFOAM that the user wants to build from scratch.
- Use Docker to build the image from exactly the same Dockerfile without any modification. This in order to test that "user's own image" built on user's own installation is functional. (Pass to steps 4-7 for testing.)
- Modify the recipe as desired and use Docker to build new image with the desired version of OpenFOAM.
- Test user's own image with the needed Docker and OpenFOAM commands to check if it is functional at this level.
- Convert the recently created Docker image into a Singularity image:
- Push the Docker image into user's own online registry within Docker Hub or Quay
- Pull the Docker image from the registry using SIngularity (pulling a Docker image with singularity will perform conversion automatically). Pulling can be performed on Setonix (as shown in the example below) or it can also be performed in your own Linux installation if users also count with SIngularity, which can be very handy.
- (See also information in our general documentation about pulling or building a container image)
- Move the Singularity image to a directory in users' or project's space in
/software
file system on Setonix. - Test the functionality of the image on Setonix using Singularity commands.
...
Column | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
...
- OpenFOAM
- OpenFOAM: Best Practices
- OpenFOAM: Example Slurm Batch Scripts
- Containers
- Pull or build a container image