← Back to team overview

dolfin team mailing list archive

Re: Simplified solution process

 

I suggest one class PDE that tries to be smart by looking at the
arguments to the constructor and finds out what to do.

Then we have specialized classes as subclasses of GenericPDE and PDE
has a pointer to GenericPDE:

    class PDE
    {
    public:

    private:

      GenericPDE* pde;

    };

Maybe the specialized classes at this point should be

    StaticLinearPDE      (current solver in PDE class)
    StaticNonlinearPDE   (Garth's new nonlinear solver)

I expect we will add some automation for time-dependent PDEs at some
point and use the ODE-solvers for adaptive time-stepping. Maybe we
can then add

    TimeDependentLinearPDE
    TimeDependentNonlinearPDE

Other options would be Transient (but I don't like it since it
indicates something short-lived near t = 0) or Dynamic (which I don't
really like either).

Maybe we should also have a class called VariationalProblem that just
is a copy of the current PDE class. This can be nice to have to set up
variational problems for projections that are not really PDEs. Perhaps
the StaticLinearPDE class can in turn define a VariationalProblem and
solve it so that we don't have to duplicate the code.

/Anders


On Tue, Feb 21, 2006 at 11:27:07AM +0100, Garth N. Wells wrote:
> Is it preferable to have objects LinearPDE, NonlinearPDE, etc, or just
> one type, PDE, which knows (will be told) whether it is linear,
> nonlinear, time-dependent, etc?
> 
> Garth 
> 
> On Tue, 2006-02-21 at 11:19 +0100, Johan Hoffman wrote:
> > Ok, sounds good. We had a similar structure in early versions of DOLFIN
> > (StatProblem, TranProblem,...), which I think we removed since we wanted a
> > more flat structure of PDE tools. But now we have the possibility to
> > automate a lot of features within each class, so I think a resurrection is
> > motivated.
> > 
> > /Johan
> > 
> > 
> > > I've added the class NonlinearPDE in src/kernel/nls, which has a very
> > > similar interface to the class PDE, and has similar functionality for
> > > solving.
> > >
> > > I think that Anders' suggestion to split-up PDE in the same fashion as
> > > Function is good a good idea. I'm working in it now - at this stage for
> > > linear and nonlinear PDE's.
> > >
> > > Garth
> > >
> > > On Fri, 2006-02-10 at 14:14 -0600, Anders Logg wrote:
> > >> The new PDE class is now in place and takes care of some of the
> > >> standard stuff you need to do to solve a static linear PDE: define
> > >> vectors and matrices, assemble bilinear and linear forms, solve linear
> > >> system and create a Function from the degrees of freedom.
> > >>
> > >> Here's the new version of the Poisson demo:
> > >>
> > >>   // Set up problem
> > >>   UnitSquare mesh(16, 16);
> > >>   Poisson::BilinearForm a;
> > >>   Poisson::LinearForm L(f);
> > >>   PDE pde(a, L, mesh, bc);
> > >>
> > >>   // Solve
> > >>   Function u = pde.solve();
> > >>
> > >>   // Save function to file
> > >>   File file("poisson.pvd");
> > >>   file << u;
> > >>
> > >> This works for all linear static PDEs. I imagine that we can use the
> > >> PDE class to automate the solution of static nonlinear PDEs,
> > >> time-dependent etc. Depending on the arguments to the constructor
> > >> (among other things), the PDE class would know what to do to solve the
> > >> system. A first step would be to integrate Garth's Newton-solver with
> > >> the PDE class. Perhaps we need to partition it in the same way as the
> > >> Function class (GenericPDE, StaticLinearPDE etc) so it's easy to
> > >> plugin a new solver.
> > >>
> > >> Note that as an alternative to
> > >>
> > >>   Function u = pde.solve();
> > >>
> > >> one can do
> > >>
> > >>   Function u;
> > >>   pde.solve(u);
> > >>
> > >> which is slightly more efficient (avoids one copy of the vector of
> > >> degrees of freedom).
> > >>
> > >> The PDE class i parametrized and has one parameter "solver", so you
> > >> can do either
> > >>
> > >>   pde.set("solver", "direct"); // default option
> > >>
> > >> or
> > >>
> > >>   pde.set("solver", "iterative");
> > >>
> > >> /Anders
> > >>
> > >> _______________________________________________
> > >> 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
> > >
> > 
> > 
> > 
> > _______________________________________________
> > 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/



Follow ups

References