dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

This sounds like a good plan. But as we said, maybe we should wait to
specify the format of the time dependent PDE's until we know how these
will be handled (ODE timestepping or other...).

/Johan


> On Tue, 2006-02-21 at 08:03 -0600, Anders Logg wrote:
>> I suggest one class PDE that tries to be smart by looking at the
>> arguments to the constructor and finds out what to do.
>>
>
> Sure. We will still need to explicitly tell the PDE if it is nonlinear,
> as for simple nonlinear functions, the constructor is the same (no extra
> information is required). The only difference is the solve function.
>
> I've started PDE implementing as outlined below, modelled on the class
> Function.
>
> Garth
>
>> 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
>
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>