fenics team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

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

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.

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.

/Johan