Skip to content

Sparsity lifetime #19

Open
Open

Description

@wrtobin

A sparsity is allocated inside of las and used to create a matrix of some type.

The matrix will then either own the sparsity and manage it's lifespan or the sparsity is still owned by the user and must be dealt with.

At present this detail is handled differently by different backends. When creating a PETSc matrix, the Sparsity NNZ is used to preallocate the matrix, but not owned by the PETSc Mat.

The sparse sparse(csr) backend captures the underlying CSR object, but doesn't own it since the object is not deleted when the matrix is. But if the user deletes the CSR object in user space the matrix would be invalidated.

We either need to copy the CSR (less desirable but not practically terrible), or invalidate the user-space pointer to the Sparsity so the user can't accidentally delete it and invalidate the Matrix, which would mean passing in a Sparsity ** to the matrix creation function instead of a Sparsity*.

Activity

  1. self-assigned this
    on May 3, 2018
  2. wrtobin commented on May 3, 2018

    @wrtobin
    OwnerAuthor

    Also in the dense backend the Sparsity is used but not captured so the object doesn't need to persist and the user should immediately delete it
    .
    Basically the usage needs to be standardized across the board.

  3. wrtobin commented on May 8, 2018

    @wrtobin
    OwnerAuthor

    Added the ability to specify csr ownership in the csrMat constructor in commit 3ee26dd, but usage of this additional interface facility isn't ubiquitous or consistent yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions