1. 22 Aug, 2018 4 commits
    • Carsten Gräser's avatar
    • Carsten Gräser's avatar
      Normalize topologyId of grid capability · fc40bb56
      Carsten Gräser authored
      Otherwise overloading for the StaticGeometryType
      may fail if the same geometry type is encoded
      with 0 and 1 in the first digit.
    • Carsten Gräser's avatar
      Add support for GeometryTypeProviders to LagrangeBasis · b68cd2cb
      Carsten Gräser authored
      * For single element type grids the polymorphic interface is by
        default no longer used.
      * For mixed element type grids the polymorphic interface is by
        default used as before.
      * When explicitly switching fixing a single element type
        (in case you have additional knowledge) you can now also
        avoid the costly polymorphic interface.
    • Carsten Gräser's avatar
      Add different GeometryTypeProviders · 60664304
      Carsten Gräser authored
      These allow to map an entity to its geometry type. Depending on the
      selected provider and grid view, this is encoded as GeometryType or
      StaticGeometryType. There are several implementations:
      * MixedGeometryTypeProvider will always act like a mixed element
        grid and simply forward the dyanamic GeometryType. You'd normally
        not want to use this one.
      * AutoGeometryTypeProvider will use a StaticGeometryType if the grid
        satisfies hasSingleGeometryType(). Otherwise GeometryType is used.
        This is the default choise which should work always.
      * SimplexGeometryTypeProvider and CubeGeometryTypeProvider will
        always provide the corresponding StaticGeometryType. This can be used
        to avoid the costly polymorphic interface if your grid supports mixed
        elements, but you know, that there are only simplicies or cubes.
  2. 01 Aug, 2018 2 commits
  3. 22 Jun, 2018 2 commits
    • Carsten Gräser's avatar
      [cleanup] Be signed-correct · 43dd7bf9
      Carsten Gräser authored
      Maybe that's picky, but I tried hard to stay 'signed-correct'
      in dune-functions, i.e. use signed types only where you allow
      signed values. I'd rather not leave this just to hack around
      the sloppy ReferenceElement interface.
    • Oliver Sander's avatar
      Fix a signed/unsigned warning · 9c17ef9a
      Oliver Sander authored
      Like it or not: ReferenceElement::size returns a _signed_ integers.
  4. 20 Jun, 2018 1 commit
  5. 19 Jun, 2018 12 commits
  6. 14 Jun, 2018 4 commits
    • Carsten Gräser's avatar
      Switch to compatible function rage · 55690705
      Carsten Gräser authored
      Having HierarchicNodeToRangeMap as default, you must use a
      range type compatible with the tree structure.
    • Carsten Gräser's avatar
      Switch default node-to-range-map to HierarchicNodeToRangeMap · 7a17f787
      Carsten Gräser authored
      This is a non-compatible interface change. If you used a range
      on a nontrivial (depth>1) tree, this will not work as before,
      because the range entries are lo nonger accessed using a flat
      index. (But this is very unlikely.)
      As long as you only used power<...> or composite<...> in a non-nested
      way, the behaviour should still be the same.
    • Carsten Gräser's avatar
      Implement HiererachicNodeToRangeMap · b2c0261f
      Carsten Gräser authored
      This simply forwards the tree path entries to the range
      assuming it's a nested container with compatible structure.
    • Carsten Gräser's avatar
      Pass treepath to node to range map · db863cea
      Carsten Gräser authored
      In general using the treepath is more natural here.
      While the node stores its treepath this is very likely
      to be removed soon, since in any place where you need
      the treepath it's available by other means (e.g. during
      tree traversal).
      Notice that this is an interface change! If you have
      implemented your own node-to-range map, you will have
      to add the additional parameter to operator().
      At a later stage one may also want to drop the node argument.
      However, it's not totally clear if this is needed in custom
  7. 07 Jun, 2018 1 commit
  8. 05 Jun, 2018 2 commits
    • Carsten Gräser's avatar
      [bugfix] Fix makebasistest.cc · 8e41b98c
      Carsten Gräser authored
      This was missing a header which was implicitly
      included when the MR was created. Now we can simply
      drop the VectorBackend, because interpolate will
      create and use an ISTLVectorBackend automatically.
    • Steffen Müthing's avatar
      Fix typo · 45641f6e
      Steffen Müthing authored
  9. 03 Jun, 2018 2 commits
  10. 04 May, 2018 2 commits
    • Carsten Gräser's avatar
      [bugfix] Use PowerPreBasis::MultiIndex::max_size as size for SizePrefix · fb41c3f4
      Carsten Gräser authored
      The SubPreBasis::SizePrefix::max_size may be to small,
      if the current PowerPreBasis addds a digit. The solution
      if to use PowerPreBasis::MultiIndex::max_size. This may
      be suboptimal if this PowerPreBasis is an inner node
      and more digits are added later. Before trying to optimaze this,
      one should benchmark which solution is better:
      * Use an optimal (as small as possible) SizePrefix
        in each node.
      * Use the same SizePrefix for all nodes to allow
        modification insteaf of copying.
    • Carsten Gräser's avatar
      Add element() method to inner nodes · 62375c45
      Carsten Gräser authored
      There's no reason to not have the element method for inner
      nodes. Computing the element ic cheap here anyway, because
      this can be forwarded to the children (which themselves
      forward this to the LocalView that stores the actual
      element copy).
  11. 01 May, 2018 8 commits