Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • dumux dumux
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 84
    • Issues 84
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 80
    • Merge requests 80
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • dumux-repositories
  • dumuxdumux
  • Issues
  • #846

Closed
Open
Created Mar 30, 2020 by Kilian Weishaupt@kweisOwner

[staggered] Memory requirements

The (free flow) staggered model requires huge amounts of memory for larger systems, especially in 3D and when caching is enabled.

As an example, a 3D domain with 4332960 cells takes around 50GB RAM when caching is enabled.

Investigating a smaller 2D domain with valgrind massif revealed that 8% of the total memory consumption is caused by the StaggeredSubControlVolumeFace. This kind of makes sense because we store a lot of information, such a neighboring dof indices and distances within the scvf (needed to calculate velocity gradients, etc.)

We even store large parts of the same information twice (two scvfs per intersection).

Would it make sense to put all the information stored so far in the scvf into a staggered fvGeometry? We could then store one fvGeometry per intersection and avoid duplication.

I could image something like

void fu(const FVGeometry& fvGeometry)
{
    const auto& ccFVGeometry = fvGeometry.cellCenterFVGeometry(); // regular fvGeometry as for tpfa
    const auto& faceFVGeometry = fvGeometry.faceFVGeometry(); // new fvGeometry, centered around element faces

    for (const auto& scvf : scvfs(ccFVGeometry))
    // do stuff with "normal" scvfs, defined on element faces

    for (const auto& scvf: scvfs(faceFVGeometry))
    // do stuff with scvf defined for staggered control volume
}

As still want element-wise assembly, the faceFVGeometry's scvfs would probably have to know in which element they lie.

Assignee
Assign to
Time tracking