Re: [Gfs-devel] two phase vs. one phase free surface and ...

[Stephane P. <s.p...@ni...>]

> more easy to implement than PLIC (geometrical nature with CFL time step
> restriction). As examples see works due to Yabe team (semi lagrangian CIP
> family methods, look at JCP) or semi-lagrangian particle level set (fedkiw
> team) or semi-lagrangian contouring due to J. Strain (basic idea in
> JCP, efficiency of 3d version for handling complex free surface
> flow is demonstrated in ACM Transactions on Graphics, 25(1):19--38), these
> methods specially be attractive on addaptively refined Cartesian grid,
> where
> time step is limmited from stability of VOF on small cells.

I don't think these methods are necessarily easier to implement than VOF.
The main problem with almost any Lagrangian technique is the lack of mass
conservation. You were worried in an earlier message about losing 1% of
the mass... with a Lagrangian technique it would most probably be much
worse. In fact, I believe that the only published exactly mass conserving
technique is the LE-EI VOF scheme of Scardovelli & Zaleski (2002).

As far as the CFL restriction is concerned, my point of view is that the
CFL condition is not only a numerical stability condition, it's also a
statement that the physical timescales associated with a phenomenon
resolved on the finest grid, scale like the local velocity. For "complex
enough" phenomena, this is certainly true. Using a timestep larger than
the CFL criterion just means that these (important) physical timescales
will not be resolved properly: the simulation will run faster but will not
give correct results...

> Also, i am begineer with Gerris, when i look at body of code, i sense that
> it is poor commented

My philosophy (copied on Linus Torvald's) is that if the body of the code
needs lots of comments it means that its structure should be rethought
(e.g. split monolithic codes by calling sub-functions etc...)

> i think that if you design a flochart that
> graphically
> describe various portion of code and their connectivity to each other, it
> helps considrably  to new developers to familarity with code and saves
> their
> time.

This is a different point and I agree that their is a lack of a high-level
description of the code at the moment (this does not mean adding comments
in the code body however).

> In previous thresd i answer about reasons of in-effective contribution of
> peoples in Gerris, now i think one of them can be due to documentation
> problem, i think if you spend a portion of your time (or your co-worker)
> in
> this field (enriched documentation and definition of some standards for
> extension) insted enriching program capability, you can attract more
> peoples
> and resultant effect can be better than now.

Probably, however several groups have managed to develop their own
extensions to the code even with the current level of documentation. Not
all have contributed code back however...

cheers

Stephane