Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • hyteg hyteg
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 34
    • Issues 34
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 4
    • Merge requests 4
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • hyteg
  • hyteghyteg
  • Issues
  • #61

Closed
Open
Created Feb 20, 2018 by Nils Kohl@kohl🌝Maintainer

Implement vector valued unknowns by extending the indexing functions

For higher order finite elements or e.g. DG1 discretizations, we need vector values unknowns on the discretized domain.

Currently this is implemented (but not tested and most likely not functional!) by template parameters (ValueType) that could theoretically be set to std::array or similar.

As an alternative, we could extend the indexing functions by another dimension that refers to the nth element of such a vector valued unknown.

Example: To get the three DG1 unknowns at position x, y on a macro-face an indexing function call could look like this:

real_t dg1_a = data[ index< Level >( x, y, DG_CENTER, 0 ) ];
real_t dg1_b = data[ index< Level >( x, y, DG_CENTER, 1 ) ];
real_t dg1_c = data[ index< Level >( x, y, DG_CENTER, 2 ) ];

(Such mappings of course must be documented (which would be true for the templated approach as well).)

The function memory is simply extended to the required size.

Further advantages:

  • the ValueType template parameter can be removed would be restricted to either float or double
  • the memory layout (AoS vs SoA) can be easily switched by exchanging the indexing function(!) - this would not be possible with the ValueType-template approach

Disadvantages:

  • we would restrict the function classes to unknowns of type real_t^N float^N or double^N (for uint_t typed functions we then need extra classes (but maybe that's not that bad anyway?))
  • https://i10git.cs.fau.de/terraneo/tinyhhg/issues/34 would be really hard to solve (but uncertain if we ever need that)
Edited Feb 21, 2018 by Nils Kohl
Assignee
Assign to
Time tracking