fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jan 09, 2008 at 01:28:33PM +0100, Johan Hoffman wrote:
> Hi all,
> 
> This sounds good: anyone that wants to put a solver under fenics.org
> should be encouraged to do so. It has many benefits. Any conditions for
> doing so should be simple; I suggest that all that is required is that the
> solver project fits with the FEniCS vision stated at the homepage, just as
> for the other projects, and as Anders says that there is a homepage with
> depencies etc. There will then be a natural selection among the solvers,
> if they are not used they will probably tend to fade away by themselves
> (just like the other projects at fenics.org).

Good.

> As you say, we are now in the process of publishing our solver project
> Unicorn for continuum mechanics under fenics.org, which is expected to
> happen this week or the next. A webpage is already in place (which we will
> brush up in time for the release): http://www.fenics.org/wiki/Unicorn

Good.

> This project is based on the suite FIAT/FFC/DOLFIN, and more info will be
> available shortly.
> 
> The reasonable thing is to present this project along with all other
> FEniCS projects at the main page. But of course, if the number of solvers
> grow too large we may consider dividing projects at fenics.org into
> subsets, such as form compilers, PSEs, pre- and postprocessing, etc. But
> at this point I do not see any reason for doing so.

The question is if all the solvers should be projects. If we want to
keep it loose, then maybe not? For all projects, we need a web page,
license, hg repository, bugzilla, user account, mailing list, software
directory, manual, build bot, Debian packages etc. If the solvers are
projects, then it also becomes important that the solvers are
coordinated with the latest versions of the other packages. It also
gets more difficult to add new solvers if each new solver requires a
user account (which puts limitations on who can create a solver).

So in short, if we want a loose solver framework where it is easy to
add new solvers with minimal friction, then it seems the solvers can't
be projects.

But maybe a good compromise could be to create a "solver" project,
which would contain the collection of solvers. Each solver is
maintained separately by its author (with minimal requirements) but
under the umbrella of the solver project. The solver project can have
a common mailing list, bugzilla data base etc for all the solvers.

-- 
Anders