dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, May 09, 2010 at 08:36:55PM +0100, Garth N. Wells wrote:
>
>
> On 09/05/10 20:11, Anders Logg wrote:
> >On Sun, May 09, 2010 at 07:50:14PM +0100, Garth N. Wells wrote:
> >>
> >>
> >>On 09/05/10 19:25, Anders Logg wrote:
> >>>On Sun, May 09, 2010 at 07:06:04PM +0100, Garth N. Wells wrote:
> >>>>
> >>>>
> >>>>On 09/05/10 15:04, Marie Rognes wrote:
> >>>>>Garth N. Wells wrote:
> >>>>>>Does this work from the C++ interface too?
> >>>>>>
> >>>>>
> >>>>>
> >>>>>Nope. It is a pure python prototype.
> >>>>>
> >>>>
> >>>>This isn't the design philosophy that we've used in developing
> >>>>DOLFIN. We have developed in C++ (and I think still should) and
> >>>>generated the Python interface automatically, and implemented Python
> >>>>extensions by hand only when necessary. I don't want to see a
> >>>>divergence of the interfaces and advocate that Python 'prototypes'
> >>>>should not be part of DOLFIN.
> >>>>
> >>>>Garth
> >>>
> >>>I think this prototype is too good to be kept as a prototype. We will
> >>>move the things that can be moved to C++, but it might not be possible
> >>>to move all of it since it relies on automatic differentiation and
> >>>auto-generation of the dual problem.
> >>>
> >>
> >>Having Python-only parts when required is fine (like we do now), but
> >>why not develop the C++ building blocks before committing to
> >>dolfin-main?
> >
> >Simply because we just finished the Python version and thought it
> >would be useful to others.
> >
> >>If the structure is clear and clean, it doesn't take much effort to
> >>write the C++ code. By not adding the C++ code now, there is a
> >>strong likelihood that it will never be added.
> >
> >It's not unlikely. There is quite a strong commitment to moving parts
> >of it to C++.
> >
> >>I would prefer that prototypes remain in the sandbox until the C++
> >>code is in place.
> >>
> >>The addition of the Python adaptivity code marks a change in
> >>development approach and should be discussed.
> >
> >I'm not sure the sandbox is a good place (at least not in its current
> >form). It's a mixture of stuff that works and stuff that doesn't work,
> >things that are broken, test snippets etc.
> >
> >If we decide to enforce a strong policy that we should not add
> >experimental code to DOLFIN,
>
> The question is not on experimental code - it's preserving the
> language-neutral nature of DOLFIN and whether we want to continue
> this approach. I would like DOLFIN to remain language-neutral.

Agree, at least C++/Python neutral (as much as we can).

> >is there a way that we could organize
> >modules like the adaptivity module and make them easily installable?
> >I don't think it's a good idea to create things as separate projects,
> >if the intention is to merge it into DOLFIN. It would be something
> >between dolfin-sandbox and dolfin-main.
> >
>
> A DOLFIN-app? Once ready, it could be merged into dolfin-main. I
> would like to have the adaptivity code in dolfin-main now (with C++
> code), but I'm too much of a cynic to be sold on assurances that C++
> code will be added ;). What's the driver if the code already meets
> the need of the developer?

It doesn't. There are two major driving forces to add a C++ version:

(i) Speed. Parts of it are currently too slow.

(ii) We plan to write a(nother) paper that demonstrates the efficiency
(as in little overhead) of the approach and then we need to write a
C++ version. Some parts have already been added to C++ (Extrapolation
and TimeSeries classes).

I also think the drive to add a C++ version will be helped if users
see a nice feature in the Python interface and ask for it to be added
to the C++ interface.

It would be beneficial to have a discussion on what the interface
should be as seen from the C++ side. Should there be a special option
to FFC that tells FFC to generate the additional pieces that are
needed, what should that option be called, what should the relevant
classes be called etc.

One starting point could be this:

  Poisson::BilinearForm a(V, V);
  Poisson::LinearForm L(V);
  Poisson::DualBilinearForm astar(V, V);
  Poisson::DualLinearForm Lstar(V);
  Poisson::CellResidualForm rT(?);
  Poisson::FacetResidualForm rdT(?);

  ffc -f adaptive Poisson.ufl

  AdaptiveVariationalProblem problem(a, L, astar, Lstar, rT, rdT);
  problem.parameters["strategy"] = "dorfler";
  problem.parameters["marking"]["fraction"] = "dorfler";
  Function u;
  problem.solve(u, 1e-6);

The above is for linear problems but the adaptivity module also
handles nonlinear problems.

--
Anders

Attachment: signature.asc
Description: Digital signature