dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Sep 23, 2005 at 09:18:58AM +0200, Johan Hoffman wrote:

> > I think so too. There's just a question about naming. Should we call
> > it PDE or LinearProblem? The reason one would like to call it
> > LinearProblem is that a pair (a, L) can be used to define a projection
> > as well, which is not a PDE but a linear problem:
> >
> >     a = u*v*dx
> >     L = f*v*dx
> >
> > The solution u of a(v, u) = L(v) is the projection of f onto the
> > space.
> >
> > A reason not to call it LinearProblem might be that a linear problem
> > might be Ax = b, but maybe we will never have a reason to work with
> > pairs (A, b)?
> 
> Maybe we should go with PDE. The projection is also a PDE, and further
> ahead we might want to work with nonlinear forms.

Other reasons to call it PDE is that we already have ODE and PDE is
shorter than LinearProblem, but is the projection really a PDE? There
are no derivatives. A special case which happens to have no derivatives?

> >> For the linear algebra we have Petsc + Hypre giving access to a range of
> >> parallel Krylov based solvers plus algebraic multigrid.
> >
> > Yes. One thing we should do is to find out how to specify AMG as a
> > preconditioner without having to do it through the command-line with
> > -pc_type hypre -pc_hypre_type boomeramg.
> 
> Yes, this we should take care of.

Andy posted instructions for how to do this. Maybe you can try it in
the Navier-Stokes solver?

> >> For efficiency the next big challenge is to have all components in
> >> DOLFIN
> >> parallelized; that means the mesh and the assembly routine. It seems
> >> that
> >> Matt's Sieve will be the solution.
> >
> > That should be the plan for the 0.6.x series. What things do we want
> > to finish before releasing 0.6.0? Manual + Navier-Stokes? What is the
> > status of the Navier-Stokes solver?
> 
> The Navier-Stokes solver has been working fine for some weeks. Possibly I
> have do update the boundary conditions after the changes in the
> BoundaryCondition class. The benchmark problem setup is a standard
> benchmark problem for 2d flow past a circular cylinder. If one wants to do
> 3d one just have to change the form-file elements to tetrahedrons and
> change the boundary conditions to 3d. The solution is written to an
> m-file.

ok, great. Is it any good? How does it compare to your old implementation?

> That leaves the Manual, which is in progress.

Yes, I'll be writing another chapter today. Let's try to have the
manual + DOLFIN 0.6.0 ready for FEniCS'05 in October.

/Anders

> >> As for abstraction of the implementation, hiding the linear algebra as
> >> you
> >> say is one thing. Another is to automate space-time FEM in FFC. That is,
> >> to give the forms for a space-time domain, instead of just for a space
> >> domain, as is the case today. The functionality of space-time FEM is
> >> already there, but the time discretization today has to be given
> >> explicitly to FFC. This would take the form-file code closer to the PDE
> >> formulation for time dependent problems.
> >
> > Yes, we should do that, but the ODE solvers are not (yet)
> > parallel. And I don't think we are even completely satisfied with the
> > current sequential implementation yet. I think it's basically ok,
> > especially after the major rewrite Johan and I did last winter, but it
> > needs some more work (testing, tuning).
> 
> To have FFC work with the ODE solver is one thing. What I meant is to have
> FFC automatically discretize a PDE in space-time, that is we do not write
> out the discretization of the derivatives in time for example ((u-u0)/k)
> but instead we write u.dt().
> 
> The heat equation would then be something like:
> 
> a = v.dx(i)*u*dx(i)*dx*dt
> f = v*f*dx*dt
> 
> > > Another thing to think about is to also automate the discretization of
> >> non
> >> linear problems. That is to give FFC the non-linear form to either
> >> discretize for the non-linear solvers of Petsc, or to linearize and
> >> dicretize for a linear solver.
> >
> > Then we need to extend the FFC form language. The question is how to
> > do this properly. Matt Knepley has a grammar + AST (abstract syntax
> > tree) worked out for nonlinear forms and he can do differentiation.
> > Maybe we should use that?
> 
> Maybe this is something for a future release, we can to fine with the
> linearization for now. But this is something worth planning for ahead. I
> do not know much about Matt's nonlinear forms but it sounds interesting,
> has he written anything about it?
> 
> /Johan
> 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >
> 
> 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/