fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jan 11, 2008 at 10:59:12AM +0100, Johan Hoffman wrote:
> > 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?
> >
> >
> 
> Yes, I suggest (i)-(ii).
> 
> 1. No. Not at all. For example, if someone wants to make the Plasticity
> solver you mention an "offical" FEniCS solver this is perfectly fine by
> me.

Sounds good.

> 2. Yes, although not neccessarily with the dolfin-dev repository. Rather I
> see a model where when releasing a new version of Unicorn we also release
> a new compatible version of DOLFIN, which then can be used together with
> Unicorn until the next release.

Yes, something like that...

-- 
Anders