fenics team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

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

Ok. I think an even better compromise is to do both but keep it separate,
since it is clear that the "solvers" you are discussing is different from
what I have in mind for Unicorn.

That is, (1) let us create a page on the FEniCS wiki "FEniCS community
solvers" (or similar), where anyone interested can link to their own
FEniCS solver that may be of interest for the rest of the community (not
just duplicating DOLFIN demos for example...), using a certain format
(link to homepage, dependencies, etc.). I suggets we keep a loose format
concerning updates to dependencies, as long as it is clear what they are
(of course, if the solver is deemed "dead" we can remove it). This way we
minimize loss of resources to maintain such a solver project. To update
the wiki we could either let it completely free for anyone to update (at
least this could be tested), or someone could do the (minimal) work of
updating the links at the wiki. By setting up such a webpage we could also
get an idea of the interest in submitting solvers.

And (2), since Unicorn is maintained by people already having FEniCS
acounts (also webpage and maillinglist is already setup), and the scope of
the project is automation of mathematical modeling (including error
control) of continuum mechanics, in line with the FEniCS vision, Unicorn
is very much a FEniCS project in the standard sense. Also, when algorithms
in Unicorn initially unsuitable for direct implementation in DOLFIN have
matured enough in generality and simplicity they are moved upstream to
DOLFIN. So the coupling between the Unicorn and DOLFIN projects will be
clear and close.

/Johan