Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • siesta siesta
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 82
    • Issues 82
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 25
    • Merge requests 25
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

Scheduled maintenance on the database layer will take place on 2022-07-02. We expect GitLab.com to be unavailable for up to 2 hours starting from 06:00 UTC. Kindly follow our status page for updates and read more in our blog post.

  • siesta-project
  • siestasiesta
  • Issues
  • #29
Closed
Open
Created Dec 30, 2019 by wenlibin02@wenlibin02

Memory leak

The problem: the memory used by Siesta increases by 0.1 GB every 3 seconds. Once it reaches the maximum memory of the compute node, Siesta crashes, with warning (from openmpi, I think): Primary job terminated normally, but 1 process returned ...

Test example is from the source package: ./Tests/si64. For demonstration purpose, I modified the K-Points to 10x10x10, and increase the precision requirements thus it won't end instantly (see the attached file si64.fdf)

More details about the calculation:

  • The Siesta version: MaX-1.0, from https://gitlab.com/siesta-project/siesta/-/archive/MaX-1.0/siesta-MaX-1.0.tar.gz
  • 8 MPI threads: mpirun -np 8 siesta_mpi < si64.fdf > si64.out
  • gcc/8.3.0 + OpenMPI/3.1.4 + netlib-lapack/3.8.0 + netcdf-fortran/4.5.2 + netcdf-c/4.7.3 + scalapack/2.0.2 (also tried 2.1.0, the newest version), please check the attached arch.make for compilation options
  • the job was submitted on high-performance cluster, with slurm system

More tests:

  1. This issue is similar to the one reported in https://bugs.launchpad.net/siesta/+bug/1847623 -- If I add the option Diag.ParallelOverK true, the memory will keep near a constant. However, enabling parallel over k makes the calculation quite slow for large-size system. There is a patch in the discussion of the issue https://bugs.launchpad.net/siesta/+bug/1847623, which is not applicable to the current Siesta version.
  2. For another system with transition metal element and more atoms (~ 400 atoms), the memory also increases.

si64.fdf arch.make

Assignee
Assign to
Time tracking