[Dune] [#564] Use dynamic polymorphism

[Dune]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#564 - Use dynamic polymorphism
User who did this - Jö Fahlke (joe)

----------
For the static-implementation proposal I see the following advantages:

 1. The virtual-implementation proposal cripples the static interface:

    a) As a user, you explicitly have to give the type of function and of the
       coeffitionts you want to interpolate as template parameters of the
       classes.  With the static-implementation proposal the compiler can
       infere those from the arguments of the interpolate() method.  (Of
       course, this only adds a few characters to the users code, so this is
       not really an important point.)

    b) With the virtual-implementation proposal with the static interface, it
       is impossible for a user to interpolate a fucntion of one type and a
       function of another type later unless they share a common virtual
       basis.  With the static implementation proposal there is no such
       restriction.  (With the virtual interface you have that restriction for
       both proposals.)

    c) Similarly, with the virtual-implementation proposal with the static
       interface, it is impossible for a user to interpolate into one type of
       coefficients and into another type of coefficiens later, and nobody
       wants to derive his coefficient types from a common virtual basis.  Of
       course, this is probably not done in practice anyway.

    In the virtual implementation proposal, the static interface offers not
    advantage over the dynamic interface and is thus just dead weight.  Only
    the static-implementation proposal can offer the benefits of both
    interfaces to the user.

 2. Ease of implementation for maintainers and potential implementors:
    
    I feel much more at home with static polymorphism than I do with dynamic
    polymorphism.

For the virtual-implementation proposal I see the following advantages:

 1. Ease of implementation for maintainers and potential implementors:
    
    a) Of the current set of people actively involved in Dune, at least Oliver
       and Carsten seem to feel more at home with the virtual inheritance
       stuff.  (Concerning the poeple currently involved, this point probably
       boils down to counting how many poeple feel more at home with which
       option).

    b) People are usually tought the virtual inheritance stuff, so potential
       implementors of further local finite elements might feel more at home.

 2. The virtual implementation will probably lead to clearer error messages
    from the compiler automatically.  For the static version you would have to
    use dune_static_assert liberally.

Further remarks:

 1. The static-implementation proposal and the virtual-implementation proposal
    can actually be merged.  In this joint proposal, some local finite
    elements can have a static implementation while others have a virtual
    implementation.  The wrapper classes can then provide the other
    interface.

 2. Benchmarks using Olivers DUNE_VIRTUAL_SHAPEFUNCTIONS define will not
    actually tell us very much, since they leave out some levels of
    indirection for both proposals.  And I have the impression that both sides
    assume a lot about which optimizations will actually be done.  I'm not
    sure that the compiler will always optimize away as much as we assume with
    the static implementation for instance.  And there is the question of
    other compilers than gcc, which nobody has raised yet.  Which
    optimizations do they perform, and how much do we care?

 3. Implementing mixed finite elements is possible on top of the virtual
    interface in both proposals, so this is not really a deciding point.

My current preference is the a joint approach, where whoever implements the
local finite element decides whether to do it statically or dynamically.
Failing that, I would prefer the static implementation.

This preference is not very strong at the moment and some performance numbers
could easily change it, if they take the additional indirection of the two
proposals into account.
----------

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=564#comment973

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.