Subject: [FEniCS-dev] Solvers

From: Anders Logg <[email-masked]>
Date: Tue, 8 Jan 2008 18:13:48 +0100

Hi all,

We have discussed a few times before how to organize a collection of
solvers on fenics.org (with limited success). One obstacle we had was
that no one was willing to maintain the solvers, but this does not
mean that we can't find (another) good solution.

My suggestion would be that we set up a (very loose) framework for
solvers based on FEniCS (in particular DOLFIN). We can have some
common requirements for solvers, like having a web page on the wiki,
needing to state which version of the other packages it depends on,
having a compatible license (GPL or LGPL) etc. The point would be to
make it easy to add solvers. We would have a common page for all
solvers, which lists the available solvers and link to that page from
the main page.

If this sounds reasonable, we can discuss exactly which (few)
requirements we want to make and get this going soon. I know that
Johan^2 have an FSI solver they can add, and Kristian has a plasticity
solver that can be added. Others may follow.

-- 
Anders

---

From: Gideon Simpson <[email-masked]>
Date: Tue, 8 Jan 2008 18:47:37 -0500

I'm an outsider to this project and don't want to ruffle any  
feathers, but if PETSc is going to be the intended back end linear  
algebra library, then consider this.  Instead of trying to maintain  
your own solver database within dolfin, wouldn't it be easier to rely  
on the existing, well maintained, PETSc database and provide a path  
for sending the options through a lightweight interface?

-Gideon Simpson
  Department of Applied Physics and Applied Mathematics
  Columbia University

On Jan 8, 2008, at 12:13 PM, Anders Logg wrote:

> _______________________________________________
> FEniCS-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/fenics-dev

---

From: "Garth N. Wells" <[email-masked]>
Date: 09 Jan 2008 08:09:55 +0000

>for sending the options through a lightweight interface?

By solvers we don't mean linear solvers. For linear solvers we'll continue 
to use libraries such as PETSc as much as possible. By 'solvers' we mean 
projects that use DOLFIN as a library to solve a problem, e.g. plasticity, 
Navier-Stokes, etc.

Garth

---

From: "Johan Hoffman" <[email-masked]>
Date: Wed, 9 Jan 2008 13:28:33 +0100 (MET)

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

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

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.

/Johan

---

From: "Theodore Omtzigt" <[email-masked]>
Date: Wed, 9 Jan 2008 07:47:15 -0500

When you guys talk about solvers are you talking about the PETSc/Trilinos
level or are you talking about a solver scheme such as SIMPLE/PISO, etc?

If you are talking about PETSc, I think it would be good to define an
interface that the solver needs to be able to respond to so that lib
dependency management is trivialized. If it is in the form of solver
schemes, it would be good to define a data structure + operator generic
programming interface so that the infrastructure is being build for all
solvers. I have pointed out this before but the generic programming folks
have made some good progress on this. BOOST with MTL, and domain specific
efforts like DUNE, and GrAL. 

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Johan Hoffman
Sent: Wednesday, January 09, 2008 7:29 AM
To: Discussion of FEniCS development; Claes Johnson
Subject: Re: [FEniCS-dev] Solvers

Hi all,

/Johan

---

From: "Theodore Omtzigt" <[email-masked]>
Date: Wed, 9 Jan 2008 07:55:16 -0500

Need to read this oldest to newest... sorry about the injection of a useless
statement.

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Garth N. Wells
Sent: Wednesday, January 09, 2008 3:10 AM
To: Gideon Simpson
Cc: Discussion of FEniCS development
Subject: Re: [FEniCS-dev] Solvers

Garth

---

From: Anders Logg <[email-masked]>
Date: Wed, 9 Jan 2008 21:17:46 +0100

> (just like the other projects at fenics.org).

Good.

> brush up in time for the release): http://www.fenics.org/wiki/Unicorn

Good.

> 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

---

From: "Johan Hoffman" <[email-masked]>
Date: Thu, 10 Jan 2008 11:09:27 +0100 (MET)

> 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

---

From: Anders Logg <[email-masked]>
Date: Thu, 10 Jan 2008 11:39:17 +0100

> DOLFIN. So the coupling between the Unicorn and DOLFIN projects will be

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

---

From: "Johan Hoffman" <[email-masked]>
Date: Fri, 11 Jan 2008 10:59:12 +0100 (MET)

>> >> 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
>> >> This project is based on the suite FIAT/FFC/DOLFIN, and more info
>> will
>> >> be
>> >> available shortly.
>> >>

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

---

From: Anders Logg <[email-masked]>
Date: Fri, 11 Jan 2008 11:13:52 +0100

> solver you mention an "offical" FEniCS solver this is perfectly fine by

Sounds good.

> Unicorn until the next release.

Yes, something like that...

-- 
Anders