dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

Johan Jansson wrote:
> 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.

I see modules as a conglomerations of low-level functionality to produce 
something specialised, but of sufficient importance and appeal to 
warrant inclusion. This might be in the form of solver, but could be 
something else. Modules together building blocks to do something useful 
and likely complicated. Inevitably as the number of modules expand, some 
modules will depend on other modules.


> 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.

Many problems are too specialised and peculiar to aim for full 
generalisation. I see this as the role of modules for important problems 
- build useful things from low-level abstractions. The key is to provide 
the appropriate low-level abstractions.

In terms of generalisation, you need to pick the level. For example, the 
plasticity solver implements (using tools from the kernel) a 
sophisticated projection algorithm. It is generalised in the sense that 
users can provide various functions (plastic potential, yield function, 
etc) that define the problem. (This solver was the main reason to 
introduce use uBLAS for dense matrices and vectors).

> 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.

Is the form for a given equation unique? I don't think so. It's not 
possible to strictly separate equations and solvers.

> 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?

Building on what I wrote above, I like the way it is now. I would like 
to have modules which are useful tools built on top of the kernel 
functionality.

> > 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.

Agree. Hopefully a point will come when the kernel is very stable and 
most developments take place in the modules.

Garth

> 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
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev