fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jan 10, 2008 at 11:09:27AM +0100, Johan Hoffman wrote:
> > 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.
> >
> >
> 
> 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

Do you suggest having two separate things: (i) contributed solvers
(which everyone can contribute) and (ii) officially supported FEniCS
solvers. That sounds reasonable, but I still have two concerns:

1. Do you want Unicorn to be the one and only official FEniCS solver?

2. Will Unicorn be kept up-to-date with DOLFIN?

-- 
Anders