FEniCS CFD work-flow for complex geometries

Question

I have COMSOL and the CFD package therein available, which provides me with an all-in-one solution for solving CFD problems. I have modeled and solved the geometry shown in the pictures below, which took me roughly one hour.

Now (just for kicks) I want to do the same in FEniCS and see how that goes. At this point, I am trying to establish an optimal work flow.

My approach at the moment is this:

1. create the geometry in gmsh
2. create the mesh in gmsh
3. import the mesh to dolfin using dolfin-convert mesh_file.msh mesh_file.xml
4. set-up boundary conditions in dolfin
5. solve navier-stokes equations
6. post-processing in ParaView

Before I start doing that, I would like to know if this work-flow is a good idea?!

Possible issues I see are setting up the boundary conditions from the imported gmsh mesh in dolfin, based on this launchpad post. I.e. is it better to define the boundary conditions in gmsh or in dolfin?

Answer 1

I've used this exact workflow for solving the Navier-Stokes equations in FEniCS.

Almost certainly the hardest part in the process will be implementing the numerical solution method; there is no out-of-the-box support for that in FEniCS (although of course all differential operators you need are available). For reference, check out nsbench, a Navier-Stokes benchmark suite written for FEniCS. It features a collection of common numerical solution methods and tests them against a number of example problems. Also check out the FEniCS book, chapter 21. Depending on the Reynolds number of the flow you intent to simulate, you may need to stabilize the numerical solution with, e.g., SUPG.

Comparing to COMSOL, using FEniCS for the task will definitely require a better understanding of the Navier-Stokes equations, numerical solution methods, and appropriate boundary conditions.

As for the specification of boundary conditions, I think dolfin-convert still doesn't carry over the tag information from Gmsh meshes to the dolfin format. If your domain isn't too complicated, manually re-tagging the boundaries in FEniCS should be doable though.