Giter Club home page Giter Club logo

cuibm's Introduction

cuIBM - A GPU-based Immersed Boundary Method code

DOI_JOSS CITE_BIB

cuIBM solves the 2D incompressible Navier-Stokes equations with an immersed-boundary method on a single CUDA-capable GPU device with the CUSP library.

Currently, cuIBM runs only on Unix-based systems (no support on Windows) and was last tested on Ubuntu 16.04.


Documentation

User's documentation is available on the Wiki pages of the cuIBM repository.

Doxygen API documentation is available here.


Installation

Dependencies (last tested)

  • GNU C++ Compiler(g++-5.4)
  • NVIDIA's CUDA Compiler (nvcc-8.0)
  • CUSP (0.5.1)
  • Boost (1.64.0)

GNU C++ Compiler

Install g++ using the following command:

> sudo apt-get install g++

Check the version of g++ installed:

> g++ --version

Other development and version control tools can be installed by following the instructions under Step 1 in the CompilingEasyHowTo page on the Ubuntu Community Help Wiki. Software developers will find it useful to install all of them.

NVIDIA's CUDA Compiler

Download and install the CUDA Toolkit.

Check the version of NVCC installed:

> nvcc --version

CUSP Library

CUSP is a library that provides routines to perform sparse linear algebra computations on Graphics Processing Units. It is written using the CUDA programming language and runs code on compatible NVIDIA GPUs.

CUSP is currently hosted on GitHub. cuIBM has been tested and works with version 0.5.1, available for download here.

> export CUSP_DIR=$HOME/software/cusp/0.5.1
> mkdir -p $CUSP_DIR
> wget https://github.com/cusplibrary/cusplibrary/archive/v0.5.1.tar.gz
> tar -xvf v0.5.1.tar.gz -C $CUSP_DIR --strip-components=1
> rm -f v0.5.1.tar.gz

Boost library

In cuIBM, we use the parser YAML-CPP (version 0.5.1 bundled in cuIBM) that requires header files from the Boost library.

> export BOOST_DIR=$HOME/software/boost/1.64.0
> mkdir -p $BOOST_DIR
> wget https://dl.bintray.com/boostorg/release/1.64.0/source/boost_1_64_0.tar.gz
> tar -xvf boost_1_64_0.tar.gz -C $BOOST_DIR --strip-components=1
> rm -f boost_1_64_0.tar.gz

Compiling cuIBM

Clone cuIBM:

> mkdir -p $HOME/software
> cd $HOME/software
> git clone https://github.com/barbagroup/cuIBM.git

To compile cuIBM, make sure you have set correctly the environment variables CUSP_DIR and BOOST_DIR to point to their respective folder:

> export CUSP_DIR=$HOME/software/cusp/0.5.1
> export BOOST_DIR=$HOME/software/boost/1.64.0

We also recommend setting the environment variable CUIBM_DIR to point to the location of the cuIBM folder. While the code can be compiled and run without setting this variable, some of the validation scripts provided make use of it.

> export CUIBM_DIR=$HOME/software/cuIBM

To compile cuIBM, navigate to the cuIBM directory:

> cd $HOME/software/cuIBM

or

> cd $CUIBM_DIR

then, run make:

> make

Note: the current Makefile compiles cuIBM with the flag -arch=sm_35 (compute capability of 3.5). You should adapt the Makefile if your NVidia card has a different compute capability.

Run an example (2D flow around cylinder at Re=40) to check that cuIBM has been built correctly:

> bin/cuibm -directory examples/cylinder/Re40

Finally, you can add cuIBM to your path:

> export PATH="$HOME/software/cuIBM/bin:$PATH"

Users-documentation is available in the Wiki pages of the GitHub repository.

Post-processing

To post-process the numerical solution from cuIBM, we provide Python scripts (present in each case in the folder examples). They make use of the package snake that is bundled in the external folder of cuIBM (version 0.3).

To install snake:

> cd $CUIBM_DIR/external/snake-0.3
> python setup.py install

snake requires Python (2.7 or 3.5), Matplotlib, Scipy, and Pandas.


Example: Flow over impulsively started cylinder (Re=550)

To run the example:

> cd $CUIBM_DIR/examples/cylinder/Re550
> cuibm

To plot the instantaneous drag coefficient and the vorticity field at saved time steps:

> python scripts/plotDragCoefficient.py
> python scripts/plotVorticity.py

Figures are saved in the folder images of the simulation directory.

We also provide a detailed description for several examples:

with comparison to experimental and computational results from other studies.


List of examples

  • lidDrivenCavityRe100: lid-driven cavity flow at Reynolds number 100. (~5 seconds on a K40 GPU.)
  • lidDrivenCavityRe1000: lid-driven cavity flow at Reynolds number 1000. (~81 seconds on a K40 GPU.)
  • lidDrivenCavityRe3200: lid-driven cavity flow at Reynolds number 3200. (~5 minutes on a K40 GPU.)
  • lidDrivenCavityRe5000: lid-driven cavity flow at Reynolds number 5000. (~11 minutes on a K40 GPU.)
  • cylinderRe40: flow over a circular cylinder at Reynolds number 40. (~4 minutes on a K40 GPU.)
  • cylinderRe100: flow over a circular cylinder at Reynolds number 100. The initial flow field has an asymmetric perturbation that triggers instability in the flow and vortex shedding is observed in the wake.
  • cylinderRe150: flow over a circular cylinder at Reynolds number 150. The initial flow field has an asymmetric perturbation that triggers instability in the flow and vortex shedding is observed in the wake.
  • cylinderRe200: flow over a circular cylinder at Reynolds number 150. The initial flow field has an asymmetric perturbation that triggers instability in the flow and vortex shedding is observed in the wake.
  • cylinderRe550: initial flow over an impulsively started cylinder at Reynolds number 550. (~4 minutes on a K40 GPU.)
  • cylinderRe3000: initial flow over an impulsively started cylinder at Reynolds number 3000. (~25 minutes on a K40 GPU.)
  • flappingRe75: flow around a flapping foil at Reynolds number 75. (~10 hours on a K20 GPU.)
  • heavingRe500: flow around heaving foil at Reynolds number 500.
  • oscillatingCylindersRe100: flow across two oscillating cylinders at Reynolds number 100. (~25 minutes on a K20 GPU.)
  • snakeRe1000AoA30: flow around the cross-section of a gliding snake forming a 30-degree angle of attack with the freestream at Reynolds number 1000. (~65 hours on a K20 GPU.)
  • snakeRe1000AoA35: flow around the cross-section of a gliding snake forming a 35-degree angle of attack with the freestream at Reynolds number 1000. (~65 hours on a K20 GPU.)
  • snakeRe1000AoA30: flow around the cross-section of a gliding snake forming a 30-degree angle of attack with the freestream at Reynolds number 2000. (~65 hours on a K20 GPU.)
  • snakeRe1000AoA35: flow around the cross-section of a gliding snake forming a 35-degree angle of attack with the freestream at Reynolds number 2000. (~65 hours on a K20 GPU.)

To run any of the examples listed above:

> cd $CUIBM_DIR
> make <examplename>

or change directory to the corresponding example's folder and

> cuibm

The biggest cases (for the gliding snake) requires a GPU device with at least 4GB of memory.

To test an example on a smaller number of time steps, you can change the value of the parameters nt in the input file simParams.yaml of the example directory. (Note that the flow solution is saved every nsave time steps which value can be changed in the same input file.)


Papers published using cuIBM


Contact

Please e-mail Anush Krishnan or Olivier Mesnard, if you have any questions, suggestions or feedback.

To report bugs, please use the GitHub issue tracking system. We are also open to pull-requests.

cuibm's People

Contributors

anushkrish avatar arfon avatar gentryx avatar mesnardo avatar piyueh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cuibm's Issues

High Reynolds Cylinder Simulations: YAML Issue

Hi and thanks for your work on this!

I successfully ran the examples for Re<200, but seem to run into the following issue for the Re=550 and Re=3000 cases:

Parsing YAML file with simulation parameters ...
Parsing YAML file with flow conditions ...
terminate called after throwing an instance of 'YAML::InvalidNode'
what(): invalid node; this may result from using a map iterator as a sequence iterator, or vice-versa
Aborted (core dumped)

Any idea how to fix this? Thanks again.

Move SLL# implementations to a branch

Since we are not sure to obtain the right results when using the IBMs SLL{0,1,2}, these implementations should be removed from the master branch and put into a specific branch.

The point is to have a branch master with only correct and validated features.

User option to decide type of interpolation for Direct Forcing scheme

Currently, the code choose points nearest to the boundary that are outside it (in the fluid region), and performs a bilnear interpolation with nodes in the fluid. An alternative is to perform this interpolation in the interior of the body. Give the user the option to choose which interpolation to perform.

Use the second GPU in the workstation

Dear Madam/Sir,
I have a question with my using of cuIBM.
I have two NVIDIA Tesla K40 in my workstation. The question is how can I configure the cuIBM to use the second one. When I run several examples at the same time, the status always like this:
20180513104926
Could you help me with any options of using the second GPU.
Thank you for your patience and looking forward to your reply.
Yours sincerely
Hui-Yang Yu

Print and plot bodies

Had earlier deactivated printing the locations of boundary points at each save point for troubleshooting purposes. Do the following:

  • Ensure that the correct boundary points are output into the save point folders
  • Plot the body during post-processing.

JOSS Reviews: Plots do not work for flying snake example

Functionality: The plotting scripts don't work in flying snake examples.

plotForceCoefficients throws an IndexError (same error in 2.7 and 3.6):

[info] registering simulation ...
        - description: None
        - software: cuibm
        - directory: /home/osumageed/software/cuIBM/examples/flyingSnake/Re1000AoA30

[info] reading forces ...
/home/osumageed/anaconda/envs/py36/lib/python3.6/site-packages/numpy/core/_methods.py:59: RuntimeWarning: Mean of empty slice.
  warnings.warn("Mean of empty slice.", RuntimeWarning)
/home/osumageed/anaconda/envs/py36/lib/python3.6/site-packages/numpy/core/_methods.py:70: RuntimeWarning: invalid value encountered in double_scalars
  ret = ret.dtype.type(ret / rcount)
Traceback (most recent call last):
  File "scripts/plotForceCoefficients.py", line 15, in <module>
    simulation.get_mean_forces(limits=time_limits)
  File "/home/osumageed/anaconda/envs/py36/lib/python3.6/site-packages/snake-0.3-py3.6.egg/snake/simulation.py", line 106, in get_mean_forces
    order=order)
  File "/home/osumageed/anaconda/envs/py36/lib/python3.6/site-packages/snake-0.3-py3.6.egg/snake/force.py", line 90, in get_mean
    'start': self.times[mask[0]],
IndexError: index 0 is out of bounds for axis 0 with size 0

plotVorticity just doesn't make a plot or create images folder.

JOSS Reviews: Add link to API to Readme

Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?

To satisfy the documentation requirement, please add a link to the Doxygen API docs to the readme

Add automated regression tests

Lid-driven cavity flow at Re=100
Flow over a circular cylinder at Re=40, both with TairaColoniusSolver and with DirectForcingSolver

Write a 1-D code to see convergence of diffusion equation with different schemes

The three type of schemes used are:

  • The domain is uniformly divided and the velocity is evaluated at the nodes, and a central difference scheme is used.
  • The domain is divided similar to a staggered grid. Standard central difference is used on all interior nodes. A modified second order stencil is used at the boundaries.
  • The domain is similar to a staggered grid. Ghost cells are used, and the values are obtained via linear interpolation at the boundaries. A standard central difference scheme is used on all nodes.

Optional parameters in input files

When inputs are read from the YAML files, the program crashes if a field is missing. It would be better if some fields are optional, and default values used in the simulation if they are absent.

Type of Krylov solver as an input parameter

Right now, the type of Krylov solver to use for the systems is hard-coded in cuIBM.
We use a bi-CG-stabilized technique for the intermediate velocity system and a CG technique for the Poisson (or modified-Poisson) system.

Looking at the various input files simParams.yaml, they state CG for both solvers.
Even if there is a memo at the end of the README to report this "known issue", it is confusing to write CG in the input files.

The type of solver should not be hard-coded and the user should have to possibility to set it up in the file simParams.yaml.

Solver not showing expected order of convergence

The following graphs plot the difference in solutions between successive grids for the case of a lid-driven cavity (Re=100, run for non-dimensional time 1.35, normalised by velocity of the lid and the length of the side of the cavity. The same dt/dx ratio is used for each case):
pure-ns

and for a cylinder inside a lid-driven cavity:
direct-forcing

Both show an order of convergence of about 1.3. These graphs can be generate by running:

    ./DirectForcingMethod/convergence.py --folder cavityRe100 --run-cases
    ./DirectForcingMethod/convergence.py --folder FDDFExternal --run-cases

from the root directory of the project.

I've also written a unit test to check the convergence of just the convection kernel:

    make unitTests/convectionTerm
    make testConvection

It displays the expected second order convergence.

Remove generation of `run.info` file

The file run.info is useless if the post-processing part becomes completely independent from it.

First, Python scripts using run.info should be modified to remove the dependency.
Second, the code related to the generation of run.info should be remove from cuIBM source files.

New IBM solver

Add a solver that solves for the flow in the same way as done by Fadlun et al. (2000).

Move plotting to Matplotlib

Try to avoid Gnuplot since it requires a non-Python program, and automating it would require a system call from the python scripts (and also requires writing data to a file). Gnuplot is also an extra dependency. Matplotlib can be considered an extra dependency too, but most computational scientists who have python installed will also have Matplotlib.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.