dolfin team mailing list archive

[Johan Jansson <jjan@xxxxxxxxxxx>]

On Tue, Dec 05, 2006 at 05:25:16PM +0100, Anders Logg wrote:
> On Tue, Dec 05, 2006 at 05:17:45PM +0100, Garth N. Wells wrote:
> > 

...

> > This looks a bit messy to me. I like it with demos, tests, benchmarks 
> > grouped together.
> 
> Grouping demo, test and benchmark for all modules signals that
> the modules somehow belong together.
> 
> By separating demo, test and benchmark for the modules from the
> corresponding demo, test and benchmark for the kernel signals that the
> modules are separate from the kernel. It also indicates that we could
> move the modules to a separate tree. A consequence of not putting them
> separate is that users are forced to download the modules even if they
> don't want to build them.

The way I see modules is that they shouldn't exist at all. A module
today is some equation- or domain-specific functions and
algorithms. But the goal of FEniCS is that we shouldn't need
equation-specific methods and algorithms. And this is not some
abstract goal, we can concretize it for most of the common equations,
it's just that we are focusing on so many things that progress isn't
very fast in this regard.

So a module to me is more of a sketch or an experiment. And a module
is either:

1. Obsolete, and has already been generalized in the kernel.

2. Generalized, and the general functionality should be moved
wholesale into the kernel, since it can be applied in general to other
equations.

3. Generalizable, and needs more work until it reaches 2 and 1.

If we look at the existing modules and classify them as above, we get:

convdiff (1)
elasticity (1)
elasticity-updated (2, or very close)
heat (1)
navierstokes (3)
plasticity (3)
poisson (1)
stokes (1)

So we effectively only have 2 real modules in DOLFIN, according to
this classification. And at least for Navier-Stokes I think it's quite
clear how it can be generalized, I (we) am actively working on that,
though we may not have the solution first thing in the morning. I'm
still a bit unfamiliar with the plasticity module, but presumably it's
generalizable as well along the lines of the other solvers.

Perhaps there's a confusion of identity for modules. Should a module
simply be a correct implementation of an equation? This means that
DOLFIN would try to provide a number of already implemented equations
people could use. But to me this is different from a module, this is
more like the demo/pde structure we have, or some of the PyDOLFIN
"solvers". An equation should be a form description, coefficients and
a plot function.

Do we want to have already-implemented equations in DOLFIN (except for
demonstrating DOLFIN)? In that case, let's call them "equations". Can
we agree on that a module should be equation- or domain-specific code?
And perhaps more difficult, also agree that the goal is that all such
modules should be generalized?

If we are in agreement on this, then the modules structure is simply a
workshop where things are put which don't really fit anywhere else
(because they're not general). And in this workshop many things will
be obsoleted, but many things will also be identified and refined
until they can be lifted into the kernel. And some might reamain as
"modules" indefinitely, but then this will be either due to lack of
effort, or due to a failure in the generality of FEniCS (and science).

With this setup, the modules do indeed belong together with the
kernel. But perhaps the "equations" do not, they could be distributed
as a separate package called dolfin-equations or something like that.

What do you think about this?

> If we put demo, test and benchmark inside each individual module, then
> we would signal that each individual module could be put in a separate
> tree and this is what we have objected to before.

With the reasoning above, this is not really relevant. The demo for a
module is usually just a test that it works at all. And if it's so
mature that it warrants a real test, then it's probably already
obsolete.

Equations however, do need demo, test and benchmark. But I don't
really see it as a problem if equations are perceived as
separate. Typically if you want to formulate a multi-physics problem,
you formulate a new equation anyway which probably includes other
equations, but still is a new equation.

> So my suggestion would be to have common demo, test and benchmark for
> all modules, and maybe at some point (when someone is willing to
> maintain it) put them in a separate tree.

Equations could be put in a separate tree, but as you say, we need a
maintainer for that. I think the easiest solution right now is to keep
the equations as part of DOLFIN, but mark them somehow (with a
separate target for instance). We could have:

src/kernel (or library)
src/equations
src/modules

Or perhaps even simpler (least change needed):

src/kernel
src/modules/equations
src/modules/experimental

  Johan