Minimizing the size of Docker images using multi-stage builds

  1. A multi-stage build version of hello world
  2. Single-stage build of dummyFoam
  3. Analyzing library dependencies
  4. Multi-stage build of dummyFoam
  5. Summary

When compiling a new high-level application or utility that will be shipped as a container, ideally, you want to start from a base image that comes as close as possible to the build-environment you need to compile your application. For example, if you’re going to create and build a custom OpenFOAMĀ® solver, it makes perfect sense to start with the OpenFOAM-plus Docker image as a base (learn more about the Docker-based OpenFOAM workflow). You may install additional third-party libraries, copy your sources to the image, and compile. This workflow is really convenient since it allows, for example, to compile your application against a variety of OpenFOAM versions or flavors at lighting speed while keeping all dependencies nicely separated. One disadvantage, however, is the quickly increasing storage demand since every newly created image contains both the build-environment and the application. Moreover, sending the image over the network will take longer and cause significantly more traffic. Of course, there is an established way to overcome these disadvantages called multi-stage builds, and this article tells you how to apply it to OpenFOAM applications.

Continue reading “Minimizing the size of Docker images using multi-stage builds”

A detailed look at the OpenFOAM-plus Docker workflow

This article is all about

  • what the installOpenFOAM script does,
  • what the startOpenFOAM script does, and
  • ways to ship your OpenFOAM/solvers/utilities using Docker.

The quickest way to get a running OpenFOAM installation on any Linux distribution (or even Mac and Windows) is probably via a Docker image. In case you have never heard of Docker, and you are wondering why you should bother to use it, Robin Knowles from CFD Engine wrote a fantastic article entitled The complete guide to Docker & OpenFOAM, which I really recommend to read before continuing with this post. If you are not in the mood to read another article, here is why you should care about Docker in a nutshell:

  • Docker allows to create isolated, standardized images of software.
  • An image contains the software itself and all its dependencies, which is why you can share and run your app (almost) without limit.
  • This flexibility makes your app executable even if you do not know the hardware or operating system (OS) it is going to run on. You can run your app in the cloud, or you can share it quickly with a co-worker who uses a different OS, or you can conserve a solver and it will be still runnable in five years from now and it will still give the exact same results.
Continue reading “A detailed look at the OpenFOAM-plus Docker workflow”

3 ways to run tutorials in OpenFOAM

Tutorial Requirements

Tutorials – The starting point of almost every simulation

Tutorials are an interactive way of transferring knowledge. They are a kind of recipes which provide you with the necessary steps to complete a particular task. The maintainers of OpenFOAM, OpenFOAM+, and FOAM-extend deliver an extensive collection of tutorials together with the library. For OpenFOAM users, the supplied case setups are the most useful information provided for free. Reading this post to the end will enable you to run all these tutorials avoiding numerous pitfalls.

Tutorials are essential because to start your project in most cases you will:

  1. Select a solver implementing all necessary physics
  2. Check the available tutorials for the solver
  3. Copy, rename and modify the most similar tutorial
  4. Test and run your simulation

Continue reading “3 ways to run tutorials in OpenFOAM”