Gerris is the Latin (and French) name of the water strider (or water boatman), an aquatic insect which uses surface tension to ``walk'' on the surface of the water. Have a look at the logo on the front page of the Gerris web site for a graphical description.
With a soft `g' like `genetics' or `general'.
The tutorial, FAQ and examples pages all have printable PDF (tutorial.pdf, faq.pdf, examples.pdf) and Postscript (tutorial.ps.gz, faq.ps.gz, examples.ps.gz) versions, the reference manual only exists as an HTML document.
Gerris uses an ``embedded boundary'' technique. Grid generation reduces to the computation of the ``shape'' (surface and volume fractions) of Cartesian (cubic) cells cut by the solid boundaries. These ``boolean operations'' between solids are performed automatically using GTS (the GNU Triangulated Surface Library). The cells cut by the boundaries can then be refined automatically using the quad/octree structure of the discretisation. Mesh generation is entirely automatic and works for any input geometry (provided it is topologically consistent, i.e. an orientable non-self-intersecting manifold).
Gerris uses a quadtree (octree in 3D) finite volume discretisation. It cannot handle unstructured meshes.
The focus is on time-dependent Navier-Stokes, so RANS is not really in my mind but nothing is in the way if this is what you need.
Large Eddy Simulation (LES) models is what I am thinking about as far as turbulence modelling is concerned.
Slip, no-slip solid boundaries, inflow, outflow, periodic..., but everything is there to implement your own boundary conditions as Gerris can not supply all the boundary conditions users could think of.
Gerris uses a domain decomposition approach using MPI for synchronisation at domain boundaries. For the moment it does not do dynamic balancing of domain sizes which limits its applicability to statically refined problems.
Yes but there may be load-balancing issues. I don't use the MPI version for the moment. For the type of studies I am interested in, it is usually much easier to do ``direct parallelism'' i.e. run several simulations with different parameters ``in parallel''.
No, the code does not have parallel load-balancing capabilities at the moment. It can do static load-balancing i.e. ``optimal'' partitioning of the domain so that an initial mesh is divided in roughly equal-sized subdomains while minimising the size of the communication boundaries.
I don't personally use the parallel capability of the code very much. What I usually need is several different sequential computations with a different set of parameters. This is of course the ideal case for ``parallelism''. I don't usually require to run ``one shot'' very large parallel computations.
Load-balancing is not very high on my list of priorities at the moment. I don't see fundamental obstacles to dynamic load-balancing. The main limitation of the current code which would be hard to do away with is the fact that only ``coarse grain'' parallelism is possible (i.e. domains can be partitioned only at the GfsBox level not at an individual cell level). This is a limitation only when the ratio of total number of cells to total number of CPUs becomes small however.
What's ultimately needed to implement ``full'' load-balancing is a way in the code to transfer entire GfsBoxes from one processor to the other (ensuring the correct restructuring of associated boundary conditions). This is a technical problem but which could be solved relatively easily by someone with a good understanding of the code structure at the GfsBox/GfsBoundary level.
An intermediate possibly easier (but not as clean) solution can be to save the simulation and stop the code when load-balancing becomes too bad, then do a static load-balancing step and restart a ``new'' simulation with this as initial state. I would probably first experiment with this approach to get used to the problems involved first and then move to the full internally-coded solution.
Not yet but this is planned for a next phase.
No, but this would be possible. The existing shallow-water solver in particular can be seen as one form of compressible flow solver.
Yes, starting with version 0.6.0, although I would not consider it ready for ``general consumption'' right now. For simple examples on how this works have a look in the source file in test/ocean.
Thanks for asking. The easiest way you can help me is first by using the code. Setting up your own test cases etc...And reporting problems, either in term of usability, unexpected results etc...
By doing that you will certainly help me ensure that the code is as robust as possible and you will soon find areas which need improvement and which you might like to work on (preferably after consultation with me so that we can coordinate our efforts).
An important point is also to remember to try to send your questions/comments to one of the two Gerris mailing lists (gfs-users or gfs-devel) so that other people can benefit from the exchange (I will also more readily reply to a message on the mailing list than to one addressed directly to me).