dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Dec 07, 2006 at 02:58:48PM +0100, Johan Jansson wrote:
> On Wed, Dec 06, 2006 at 10:51:57PM +0100, Anders Logg wrote:
> > On Tue, Dec 05, 2006 at 10:05:02PM +0100, Johan Jansson wrote:
> > 
> > > 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.
> > > [...]
> > 
> > This is true, but we will always need the modules/solvers.
> > 
> > A solver is something that specifies a number of fixed parameters,
> > like which equation to solve, and allows a user to specify some
> > others.
> > 
> > This allows a user to solve say Navier-Stokes with a given right-hand
> > side on a given domain (and some other parameters).
> > 
> > If we didn't have the Navier-Stokes solver, one would need to at least
> > write down Navier-Stokes and we can't expect everyone to know that
> > (not to mention writing down the weak formulation including
> > stabilization etc).
> > 
> > So, in the end the modules could be very very short but they will still
> > be there.
> > 
> > /Anders
> 
> Yes, but if an entity only consists of written-down equations +
> coefficients, then let's call it an equation? And if an entity
> consists of equation-specific low-level functionality, then let's call
> it a module?
>
> Otherwise we have that a module consists of "stuff", which can be
> anything. And it becomes more difficult to quantify the progress of
> FEniCS, since everything looks the same, regardless if it's
> generalized/automated or not.

In that case, "solver" is a better name. A solver solves some equation
using a particular method.

   solver = equation + solution method

/Anders