1. 07 May, 2019 1 commit
    • Oliver Sander's avatar
      [!123] add explicit type cast in ?: ternary operator · 6ea8d3b0
      Oliver Sander authored
      Merge branch 'issue/missing_common_type' into 'master'
      
      ref:core/dune-localfunctions
      
      ### Summary
      
      Add an explicit cast to the known return type in a ?: operator for the case
      that no common-type is available to the compiler
      
      ### Details
      
      When using non-pod types as range type in localfunctions, like Float128, it
      may be that the ternary operator `bool ? Float128 : int` (or with interchanged
      arguments) can not be used, since the compiler can not deduce the return type
      of this operator. Since the return type is known in some functions, it can be
      used here directly to case the arguments of the ternary ?:.
      
      See merge request [!123]
      
        [!123]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/123
      6ea8d3b0
  2. 06 May, 2019 1 commit
  3. 24 Apr, 2019 1 commit
    • Andreas Dedner's avatar
      [!120] Feature/lagrangeinterpolate with general container · b591f135
      Andreas Dedner authored
      Merge branch 'feature/lagrangeinterpolate_with_general_container' into 'master'
      
      ref:core/dune-localfunctions Two changes made to the generic local finite
      element implementations:
      
      -   the interpolation can now take a more general vector container, i.e., is
          not restricted to std::vector. This simplifies using wrapped dof vectors,
          e.g., a masked vector
      
      -   the basis function also has a hessian method - the partial method is
          extended accordingly but hessian method can also be used directly
          returning a vector with value type FV<FV<Field,d,d>,r>. Since the full
          hessian is computed in any case this is more efficient then using partial
          (which requires the computation of the full hessian (d+1)d/2 times
      
      Thi MR only adds features so should not interfere with existing code
      
      See merge request [!120]
      
        [!120]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/120
      b591f135
  4. 10 Apr, 2019 3 commits
  5. 29 Mar, 2019 1 commit
    • Carsten Gräser's avatar
      [!116] Simplify the generic FEM factories · a69e00df
      Carsten Gräser authored
      Merge branch 'feature/simplify-generic-fem-factories' into 'master'
      
      ref:core/dune-localfunctions All *Factory classes where derived from
      TopologyFactory passing a *FactoryTraits class to the latter. The purpose is
      to implement a TopologyFactory::create() method with dynamic topology id
      parameter based on the template method *Factory::createObject<Topology>(). It
      turns out that this TopologyFactory::create() method is never used. Instead a
      counterpart TopologyFactory::create<Topology>() is called. Hence we can get
      rid of many indirections by just renaming *Factory::createObject<Topology>()
      to *Factory::create<Topology>() and dropping the base class.
      
      This also allows to remove the *FactoryTraits classes. If the types define in
      there are used in the corresponding *Factory, they are now defined directly in
      *Factory which avoids many `typename Traits::` making the code less cluttered.
      
      After this commit TopologyFactory itself is not used anymore in
      dune-localfunctions. TopologySingletonFactory is still used but serves a
      different purpose. It provides a singleton factory with caching. However it
      does not use TopologyFactory itself.
      
      See merge request [!116]
      
        [!116]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/116
      a69e00df
  6. 12 Mar, 2019 4 commits
    • Carsten Gräser's avatar
      [!119] [cleanup] Remove some very old code · 3861e60b
      Carsten Gräser authored
      Merge branch 'feature/remove-old-code' into 'master'
      
      ref:core/dune-localfunctions This was commented out using `#if 0 // OLD OLD`
      nine years ago. It seems that it's now aged enough to be removed.
      
      See merge request [!119]
      
        [!119]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/119
      3861e60b
    • Carsten Gräser's avatar
      [cleanup] Remove some very old code · 46482310
      Carsten Gräser authored
      This was commented out using `#if 0 // OLD OLD` nine years ago.
      It seems that it's now aged enough to be removed.
      46482310
    • Carsten Gräser's avatar
      [!118] Hide Dune::DerivativeLayout in namespace · 626c1b70
      Carsten Gräser authored
      Merge branch 'feature/hide-enum-dune-derivative' into 'master'
      
      ref:core/dune-localfunctions The 'generic' local finite element
      implementations based on the framework in utility/ define an
      `enum DerivativeLayout {value, derivative}` in the namespace Dune. By putting
      this into a seperate namespace Dune::DerivativeLayoutNS:: we can avoid
      cluttering the namespace Dune:: with Dune::derivative and Dune::value.
      
      See merge request [!118]
      
        [!118]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/118
      626c1b70
    • Carsten Gräser's avatar
      Hide Dune::DerivativeLayout in namespace · df5da783
      Carsten Gräser authored
      The 'generic' local finite element implementations
      based on the framework in `utility/` define an
      `enum DerivativeLayout {value, derivative}` in the
      namespace `Dune`. By putting this
      into a seperate namespace `Dune::DerivativeLayoutNS::`
      we can avoid cluttering the namespace `Dune::` with
      `Dune::derivative` and `Dune::value`.
      df5da783
  7. 07 Mar, 2019 1 commit
    • Carsten Gräser's avatar
      Simplify the generic FEM factories · fb77a9a1
      Carsten Gräser authored
      All `*Factory` classes where derived from `TopologyFactory` passing
      a `*FactoryTraits` class to the latter. The purpose is to implement a
      `TopologyFactory::create()` method with dynamic topology id parameter
      based on the template method `*Factory::createObject<Topology>()`.
      It turns out that this `TopologyFactory::create()` method is never used.
      Instead a counterpart `TopologyFactory::create<Topology>()` is called.
      Hence we can get rid of many indirections by just renaming
      `*Factory::createObject<Topology>()` to `*Factory::create<Topology>()`
      and dropping the base class.
      
      This also allows to remove the `*FactoryTraits` classes. If the types
      define in there are used in the corresponding `*Factory`, they are now
      defined directly in `*Factory` which avoids many `typename Traits::`
      making the code less cluttered.
      
      After this commit `TopologyFactory` itself is not used anymore in
      dune-localfunctions. `TopologySingletonFactory` is still used but
      serves a different purpose. It provides a singleton factory with
      caching. However it does not use `TopologyFactory` itself.
      fb77a9a1
  8. 10 Jan, 2019 2 commits
    • Carsten Gräser's avatar
      [!115] Disable floating point exceptions for clang · 9c04ebe1
      Carsten Gräser authored
      Merge branch 'feature/disable-fp-exception-with-clang' into 'master'
      
      ref:core/dune-localfunctions When compiling with -O3 clang versions \>= 5.0
      may generate code containing auxiliary operations dividing by zero altough the
      result is not used. Specifically code like this
      
          for (int i=0; i<=3; i++)
            for (int j=0; j<=3; j++)
              for (int k=0; k<=3; k++)
                if ((m!=i) && (m!=j) && (m!=k))
                  z += x*(1.0/(m-k))*(1.0/(m-j))*(1.0/(m-i));
      
      should never devide by zero. While the result of the code is correct with
      clang, it seems to produce additional operations for the ruled out cases where
      we would devide by zero. For more details see the clang bug:
      [https://bugs.llvm.org/show_bug.cgi?id=40280]
      
      The only possible solution on our side is to turn of FP exceptions for clang.
      This hoefully fixes [#13].
      
      See merge request [!115]
      
        [https://bugs.llvm.org/show_bug.cgi?id=40280]: https://bugs.llvm.org/show_bug.cgi?id=40280
        [#13]: gitlab.dune-project.org/NoneNone/issues/13
        [!115]: gitlab.dune-project.org/core/dune-localfunctions/merge_requests/115
      
      
      Closes #13
      9c04ebe1
    • Carsten Gräser's avatar
      Disable floating point exceptions for clang · 0bb9ba40
      Carsten Gräser authored
      When compiling with `-O3` clang versions >= 5.0 may
      generate code containing auxiliary operations dividing
      by zero altough the result is not used. Specifically code like this
      
      ```cpp
      for (int i=0; i<=3; i++)
        for (int j=0; j<=3; j++)
          for (int k=0; k<=3; k++)
            if ((m!=i) && (m!=j) && (m!=k))
              z += x*(1.0/(m-k))*(1.0/(m-j))*(1.0/(m-i));
      ```
      
      should never devide by zero. While the result of the code
      is correct with clang, it seems to produce additional
      operations for the ruled out cases where we would devide by zero.
      For more details see the clang bug: https://bugs.llvm.org/show_bug.cgi?id=40280
      
      The only possible solution on our side is to turn of FP exceptions
      for clang.
      0bb9ba40
  9. 31 Dec, 2018 2 commits
  10. 29 Dec, 2018 1 commit
  11. 16 Dec, 2018 4 commits
  12. 06 Dec, 2018 3 commits
  13. 02 Jul, 2018 1 commit
  14. 26 Apr, 2018 2 commits
  15. 25 Apr, 2018 2 commits
    • Ansgar Burchardt's avatar
      Merge branch 'feature/do-not-catch-polymorphic-type' into 'master' · d17214fc
      Ansgar Burchardt authored
      do not catch exceptions in main()
      
      See merge request !107
      d17214fc
    • Ansgar Burchardt's avatar
      do not catch exceptions in main() · 497d7846
      Ansgar Burchardt authored
      An uncaught exception will result in the test failing.  There is no
      need to explicitly catch them.
      
      Removing the exception handler also addresses the following compiler
      warnings from GCC 8:
      
          test-biorthogonality.cc:215:23: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      
          refinedelementtest.cc:34:24: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      
          brezzidouglasmarinielementtest.cc:37:24: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      
          rannacherturekelementtest.cc:26:24: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      
          virtualshapefunctiontest.cc:160:18: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      
          raviartthomaselementtest.cc:53:24: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      
          hierarchicalelementtest.cc:35:24: warning:
          catching polymorphic type ‘class Dune::Exception’ by value [-Wcatch-value=]
      497d7846
  16. 13 Apr, 2018 2 commits
  17. 09 Apr, 2018 2 commits
  18. 08 Apr, 2018 7 commits