On 13/06/11 14:54, Anders Logg wrote:
On Mon, Jun 13, 2011 at 02:42:57PM +0100, Garth N. Wells wrote:
On 13/06/11 14:10, Anders Logg wrote:
On Mon, Jun 13, 2011 at 01:09:20PM +0100, Garth N. Wells wrote:
On 13/06/11 12:51, Marie E. Rognes wrote:
On 06/13/2011 10:03 AM, Garth N. Wells wrote:
On 12/06/11 22:54, Anders Logg wrote:
On Wed, Jun 08, 2011 at 11:47:10PM +0200, Anders Logg wrote:
I'm on a cell phone and can't engage in any discussions but I
just want to throw something in. Marie and I discussed at
some point another option which is to write everything as F
= 0 and let UFL compute J even for linear problems. J would
be a optional variable. Then we could have a common
interface and also a common solver.
I think that this would be a nice option, but I don't think
that it can work without a more elaborate interface than just
pde = VariationalProblem(F, bcs)
because UFL cannot know which coefficient in a form is unknown,
and therefore which function to compute the linearisation with
respect to. Moreover,
- UFL cannot compute the linearisation for all forms
- In some cases it's not desirable to let UFL do the
linearisastion
Some specific responses: First, the moment solve is called (with
a coefficient), which function to compute the linearization
with respect to, is known.
Which means that the simple call
u = pde.solve()
will not be possible.
Why do you call it "pde" and not "problem"?
The name has nothing to do with the discussion.
This discussion is about just that: which names to use.
Yes, the class name, but not what I dream up for an object:
xxx = FooVariationalFoo(....)
u = xxx.solve()
I could call it xxx.
Once upon a time it was
called that, so yet another option would be
LinearPDE
NonlinearPDE
which is short enough.
What speaks against this, and likely one of the reasons we
switched to VariationProblem is that the above looks weird when
used to define a projection which does not involve any
derivatives.
And here's yet another option:
LinearProblem
NonlinearProblem
This looks ok, but it's a secondary issue for if we agree that we
should have separate classes for linear and nonlinear equations
(or have we agreed this?).
Not yet. I think we should settle first one whether we want
1. a common class for (non)linear problems
2. two classes
Agree. I strongly support 2.
What I oppose vehemently is distinguishing between linear and
nonlinear by the order of the lhs/rhs arguments. As pointed out by
Martin, the line
VariationalProblem(C, D)
says nothing to the reader about the type of problem, and it has led
to confusion.
The code
LinearVariationalProblem(C, D)
or
NonlinearVariationalProblem(C, D)
(class names subject to change) are clear, and the code can test for
the arity of C and D and throw an error if the order is mixed up.
