Giter VIP home page Giter VIP logo

life's Introduction

LIFE

Overview

A lattice Boltzmann-immersed boundary-finite element (LIFE) solver for fluid-structure interaction problems involving slender structures.

Key Features

  • BGK collision operator
  • central moments collision operator (De Rosis et al. 2019)
  • velocity and pressure boundary conditions set via the regularised method (Latt et al. 2008)
  • convective outlet condition (Yang 2013)
  • implicit immersed boundary method (IBM) for rigid and flexible structures (Li et al. 2016, Pinelli et al. 2010)
  • flexible motion solved via a corotational finite element method (FEM) for slender structures
  • implicit Newmark time integration scheme for FEM
  • force/displacement mapping between LBM and FEM grids
  • strongly-coupled block Gauss-Seidel implicit fluid-structure coupling scheme (Degroote 2013)
  • dynamic under-relaxation with Aitken's method (Irons and Tuck 1969)
  • shared memory parallelisation with OpenMP

Instruction for Users

Project Structure

The LIFE project is organised into five folders:

  • examples: contains the input files for some example cases
  • inc: contains the project header files
  • input: contains the geometry.config file that specifies the immersed boundary bodies
  • obj: contains the intermediate object files that are generated during the build
  • src: contains the project source files

Case Definition

LIFE uses two files to define the case setup:

  • params.h: sets up the domain and flow conditions
  • geometry.config: specifies the immersed boundary bodies (rigid/flexible)

The params.h file is a header file and therefore the project must be rebuilt every time this file is modified. The geometry.config is read by LIFE during initialisation and therefore does not require a rebuild after every modification. To set up a case with no immersed boundary bodies then geometry.config can be left blank or removed entirely. If present, it must exist within the input folder within the working directory. The instructions for the case setup are given in the comments within each of these files.

There are three steps to adding a new type of geometry for LIFE:

  1. Create a new keyword configuration describing the geometry in the geometry.config file.
  2. Add a new condition in the ObjectsClass::geometryReadIn() routine to read this configuration.
  3. Implement a new constructor for IBMBodyClass to build the new geometry type.

Dependencies

LIFE requires LAPACK and the Boost library. To install these on Ubuntu type the following into a terminal:

sudo apt-get install libblas-dev liblapack-dev libboost-all-dev

Building and running LIFE

A makefile is provided to build LIFE. To use the makefile just navigate to the top level LIFE directory and type:

make

An executable named LIFE will be generated. To run this just type:

./LIFE

Post-Processing

LIFE creates a directory called Results. This folder contains VTK and log files describing the results of the simulation.

Restarting

LIFE has support for restarting a simulation from where it left off. To do this just re-run the executable. There is also support for changing the geometry.config between restarts to add/remove bodies mid-simulation.

Contributing

To contribute to LIFE please follow these steps:

  1. Fork the repository and then clone the fork to your local machine.
  2. On the current master branch run the store-ref-data script to generate the test data which will be used for testing your new changes.
  3. Implement and test your new features/functionality.
  4. If implementing a substantial new feature then add a new example to the examples directory to showcase this.
  5. Run the run-tests script to make sure LIFE still produces the same results for the existing example cases.
  6. If the test script passes all of the tests then push the changes and open a pull request to incorporate the changes into this repository.

If your changes require adding/removing options from the params.h or geometry.config files then make sure to update these files in each of the example case directories otherwise the example/testing scripts will fail.

life's People

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

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

life's Issues

Tests take a long time to run

On my machine, the LIFE test suite takes about 6 minutes to run, making it less likely that people will run them. I notice that the test cases run a lot of timesteps. If the purpose is to test for regressions, then probably only a few timesteps are needed. The resolution also doesn't need to be very high.

Would it make sense to reduce the number of timesteps, and potentially also the resolution of each test?

Does this open source project support the study of the effect of surface roughness on the deformation behavior of flexible plates in flow fields?

Dear developers,
It is my honor to write this letter! I hope to investigate the effect of surface roughness on the deformation behavior of flexible plates in flow fields. However, due to a lack of understanding of the underlying logic of the project, I am not sure whether this open project can achieve my expected goals and whether there is complete validation of reference data and literature. I hope to receive a response from the developers, and I will be very grateful! Thank you!

Write restart file safely

Currently, LIFE writes restart files overwriting the previous ones. If there is a failure during writing the restart file, the original restart file will be lost and the simulation will have to be started from the beginning. LIFE could instead write the new restart file to a temporary filename, and only when all restart files have been successfully written, rename them over the old ones.

Running tests from top-level LIFE directory deletes everything in it

If you run the tests like this, from the LIFE directory rather than the testing directory (the README is unclear about this):

$ git clone [email protected]:joconnor22/LIFE.git
Cloning into 'LIFE'...
remote: Enumerating objects: 144, done.
remote: Counting objects: 100% (70/70), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 144 (delta 45), reused 36 (delta 36), pack-reused 74
Receiving objects: 100% (144/144), 89.68 KiB | 553.00 KiB/s, done.
Resolving deltas: 100% (68/68), done.
$ cd LIFE
$ testing/store-ref-data.sh 

Storing new * RefData!

cp: ../examples/*/params.h: No such file or directory
$ ls -a
*		.		..		.git		.gitignore

it deletes everything in the LIFE directory! This could be quite "irritating" if you happened to have uncommitted changes that could not be recovered from .git! (This just happened to me, and I luckily had a backup from yesterday, so could recover everything.)

The problem, as usual, is that bash is a terribly unsafe language. Adding some debug code, we see

$ testing/store-ref-data.sh 
+ for d in '../examples/*/'
+ casePath='../examples/*'
+ caseName='*'
+ printf '\nStoring new * RefData!\n\n'

Storing new * RefData!

+ echo 'rm -rf *'
rm -rf *
+ echo Exiting
Exiting
+ exit 0

Since '../examples/*/' doesn't match anything, since we are in the wrong directory, bash returns it unevaluated, and a lucky sequence of path manipulations converts this into rm -rf *. At least it doesn't delete anything outside LIFE! The (weird) behaviour of bash can be fixed by using

shopt -s nullglob

so that the empty wildcard expansion expands to a null string, rather than to itself. See here. The loop is then never run, and nothing is deleted.

It would also be good to have an initial check for being in the correct directory so that the user is given a good error message.

I will make a PR.

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.