dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Dec 07, 2006 at 10:16:54PM +0100, Garth N. Wells wrote:
> 
> 
> Johan Jansson wrote:
> > On Thu, Dec 07, 2006 at 09:33:18PM +0100, Garth N. Wells wrote:
> >>
> >> Johan Jansson wrote:
> >>> On Thu, Dec 07, 2006 at 08:18:31PM +0100, Garth N. Wells wrote:
> >>>> This is how I see it. Can we agree for now on the structure
> >>>>
> >>>> src/modules/solvers
> >>>> src/modules/demo
> >>>>
> >>>> ? The compile time for the modules is annoying.
> >>>>
> >>>> Garth
> >>>>
> >>> Ok, I've started fixing it in dolfin-stable. I've removed all the
> >>> obsolete solvers which should also reduce compile time.
> >>>
> >> I thought that dolfin-stable was only for bug fixes, and that it would 
> >> be updated when a new development release is made? Shouldn't the change 
> >> be made in the development version?
> > 
> > No, dolfin-stable keeps the kernel stable and is for module
> > development. The "dolfin" repository is for kernel development, and
> > should keep the modules stable to make sure nothing breaks which has
> > previously worked.
> >
> 
> I think that it's better to make these types of changes in the 
> development version. That way any changes will get some testing before 
> reaching dolfin-stable. From experience, changes in the build system of 
> are likely to cause problems and should be avoided in dolfin-stable.

Agree. I think dolfin-stable should be stable or we should call it
something else. It does not seem natural to have a branch named

    dolfin-kernel-stable-and-modules-unstable

We really need something like

    dolfin (dolfin-dev)
    dolfin-stable
    dolfin-modules (dolfin-modules-dev)
    dolfin-modules-stable

This would require us to move the modules to a separate tree.

If we can't do that (for lack of maintainers), I think we should keep
dolfin-stable stable and make big changes only in dolfin.

> >> Which modules did you remove? Some, like convection-diffusion, I would 
> >> like to keep. These are useful for people that write a flow solver and 
> >> want to solve an advection-diffusion problem with their flow field 
> >> (saves them having to implement everything).
> > 
> > I removed all except navierstokes, elasticity-updated and plasticity
> > (the ones I didn't mark as obsolete before). I'll put it back since
> > you need it though.
> > 
> > This is what I mean with differentiating between pure equations and
> > solvers though. Does the convection-diffusion equation really require
> > a specialized solver?

Yes, it requires a specialized solver. The specialized solver can be
very short and it can be implemented using the TimeDependentPDE
interface.

It should be possible to solve convection-diffusion even if you don't
know how to write down the equation (or the stabilized variational
form).

> > Can't it be implemented in a general way using
> > the TimeDependentPDE interface we have? Note that it also exists in
> > src/demo/pde/convection-diffusion.
> > I don't think that any non-bug changes should be made in stable as thay 
> 
> Let's be pragmatic with the modules. I'm fine with Poisson being removed 
> because it's trivial, but let's not be too hasty with the others.

I think we should keep Poisson as well for the above reason.

Another reason is that the Poisson solver can choose a suitable solver
(like multigrid) which a user would otherwise need to know.

> It would be great if advection-diffusion, for example, can be
> implemented via TimeDependentPDE, but we can still have it as a
> module. A user supply can some data and the module will return a
> solution. Most modules do require improvement to reach this level.

Agree.

/Anders