Running PyTorch models in OpenFOAM – basic setup and examples

  1. Why PyTorch
  2. Docker image with OpenFOAM and PyTorch
  3. Local installation of LibTorch
  4. Setting up Visual Studio Code
  5. Compiling examples using wmake and CMake
  6. Additional links to resources
  7. Summary

Incorporating data-driven workflows in computational fluid dynamics (CFD) is currently a hot topic, and it will undoubtedly gain even more traction over the months and years to come. The main idea is to use available datasets to make simulation-based workflows faster or more accurate. In the field of machine learning (ML) applied to CFD, deep learning (DL) algorithms allow us to tackle high-dimensional problems more effectively and promise significant progress in fields like turbulence modeling, flow control, or shape optimization. If you found your way to this article, chances are high that you don’t need to be convinced of the potential of ML/DL + CFD. So let’s skip the prose and get started with the nitty-gritty of this article: how to set up PyTorch to run DL models in OpenFOAM apps.

Continue reading “Running PyTorch models in OpenFOAM – basic setup and examples”

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”