Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T TurTLE
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • TurTLE
  • TurTLE
  • Issues
  • #4

Closed
Open
Created Oct 09, 2016 by Cristian Lalescu@clalescuMaintainer

new fluid solver

Task: rewrite algorithm from fluid_solver.cpp in vorticity_equation.cpp, but using the field class.

Desirable result: vorticity_equation.cpp should not know anything about FFTW or other possible backends. We need a clear procedure to decide whether or not this is a reasonable goal with respect to efficiency/scalability. @bbramas, I will ask for help with this "procedure" after I address the first three immediate tasks below.

Branch: feature/new-solver.

Immediate tasks as of commit 2253a792:

  • test script tests/test_vorticity_equation.py should check that the results obtained with the two different codes are identical to within numerical precision.
  • timings should be placed throughout the vorticity_equation methods.
  • the test code should also be able to handle particles; this can be achieved by simply passing the get_rdata() pointers instead of fs->rvelocity.
  • figure out how to perform statistics with new code --- choose between direct translation of old statistics methods to the new class, or moving some functionality to the python class.
  • the vorticity_equation code should be able to use either binary I/O or HDF5 I/O (at the moment it's just binary).
  • the field class and related classes (field_layout and kspace) should be made consistent with the fftw_interface.hpp header.
  • the field.?pp files should be split into three.

More general things to consider:

  • some of the functionality from a solver might be better off as a method of the field class (for instance the computation of curls). In particular the field.?pp files define a method for computing the gradient of a field object into another field object; what are the pro-s and con-s of such an approach?
  • particle code should work directly with the field class (such that scalar/tensorial fields can be interpolated directly). There's an old feature/field-interpolator branch that is addressed to this, and there's also the hack/tensor-interpolation branch that needs to be cleaned up.

@bbramas, please let me know if you can think of anything I missed in this plan.

Assignee
Assign to
Time tracking