bkochuna / ners570f23-spmv Goto Github PK

Description:

Create a test for the dense matrix accessor functions. These functions should be able to obtain information on the dense matrix format specifically. These tests are necessary to ensure proper implementation of accessor function to be used in other dense matrix operations.

Tasks:

• Determine what kind of accessors are implemented
• Determine input/outpus arguments of each accessor function for the dense matrix
• Implement/declare a accessorDenTest() function into the source file for tests
• Create test to assert correct indexing of variables in DEN matrix
• Create test to assert that matrix is actually dense (zeros at non non-zero indices)
• Create test to assert that matrix size matches the inputted matrix size MxN
• Ensure that accessor functions work with matrix with "DEN" label/class
• Output error or pass messages for each test

Definition of done:

Ensure the code runs and is able to conduct test on the DEN accessor. Pass tests such as correct matrix size reads, correct value indexing and value display, and correct matrix storage type. Implement review feedback. Ensure all blocking tasks are completed beforehand. Examples of blocking issues: DEN class and matrix construction must be implemeted, along with accessor functions (can't test them if they don't exist!)

Background

Valgrind is an extremely useful tool for finding and catching bugs related to memory management such as branching off of unitialized values, other uses of uninitialized values (reads and writes), memory leaks, and bad array accesses.

By regularly testing your code with valgrind, you can ensure that any changes that might have introduced an issue are quickly identified and fixed.

This is a relatively simple task, so we give it 5pts of extra-credit.

Tasks

• Determine how to modify github actions or other automated testing frameworks to create an additional "action"
• Define the action to run valgrind.
• Have the test results posted somewhere that is accessible for project members

Definition of Done

Evidence of the library tests being run under valgrind is posted somewhere under this github repo.

Description:This task defines the accessor methods for the COO matrix. These methods are

Tasks: Define the following functions:

std::string getFormat() - get the format of the underlying SpMV format that is being used.
size_t operator() (size_t i, size_t j) : Have operator() to get the data of the matrix coefficients based on the storage map of COO
std::string getFilename() : underlying file for the COO format.
size_t getCoefficient(size_t i, size_t j) : read from the file and get the coefficients.
size_t setCoefficent(size_t i ,size_t j, size_t value) : Set the value of the (i,j) coefficient to the value 'value'
size_t getNumRows() : get number of rows
size_t getNumCols() : gte number of columns
size_t getNumNonZeros(): get number of nonzero entries of the matrix
MatrixState getState() : get state of the matrix

Definition of done: Define the above functions in a proper manner depending on the underlying COO matrix class.

Must include getFormat() and operator()(size_t i, size_t j)

Description:

Add a CSR matrix class, which is the child class of SparseMatrix

Tasks:

• Add a new class called SparseMatrix_CSR that stores the row pointer array, column index array, and non-zero coefficients.
• The SparseMatrix_CSR also has the assembled storages and can inherit the functions of SparseMatrix.
• This class will have the constructor, including default and overloaded types, the latter of which takes one argument per member variable and assembles the class, and the deconstructor.
• It can have polymorphism, or assmeble storage, which allows the assignment of the class from another format such as COO, and also have disassemble storage that takes in the data of CSR format and convert to others.
• Communicates with the users who may use this class to see whether there are some extra needs.

Definition of done:

Must include a default constructor and a constructor which takes one argument per member variable and directly assembles the class.

Description:

Build a test to check the correctness of the ELL matvec kernel. This is a unit test and would not add to any functionality in our library. However, it is a critical component since it validates the ELL matvec kernel.

Tasks:

1. Read the vecin and vecout values.
2. Input vecin(x) into ELL matvec kernel; compare its output with vecout.
3. If the L\inf error is within 1e-3 implies the test has passed
4. Check how the matvec kernel responds to invalid inputs(for example: empty input vector)

Definition of done:

The tests should be executed when ctest command is passed. If the ELL kernel is correctly implemented, the test should return "All tests passed". If not, then it must exit the code.

Description:

Performing matrix-vector multiplication is the crux of this library's functionality.

This method will perform matrix-vector multiplication using the the sparse matrix data stored in the CSR format and an input vector (stored densely). The method will return the computed RHS vector (stored densely). The implementation of the matrix-vector multiplication will use the CSR row pointers vector, column index vector, and values vector directly rather than using the accessor functions.

Tasks:

• Define matvec method that takes in a vector.
• Write a matvec implementation using CSR data vectors.
• Store results in a new RHS vector.
• Return the computed RHS vector.

Definition of done:

Evidence of a functional matvec implementation that can properly carry out matrix-vector multiplication showing the RHS matrix and vector and the computed LHS vector posted somewhere under this ticket.

Description:

In order to make sure that the assembleStorage and disassembleStorage methods are working properly, we need to test that the conversion to and from the COO format is being done correctly.

These tests will identify possible errors and corner cases that may come up when converting to the COO format in order to ensure that the assemble and disassemble functionality is robust and will not cause issues down the line.

Tasks:

• Check that the SparseMatrixCOO class has assembleStorage() and disassembleStorage() methods defined
• Check that the assembleStorage() and disassembleStorage() methods properly update the MatrixState
• Check that assembleStorage() method properly allocates and generates the rowIdx, colIdx, and values vectors based off of the coefficients defined with the setCoefficients() method
• Work with the other COO developers to make sure that our tests are not conflicting in their assertions

Definition of done:

Evidence of unit tests that evaluate different aspects of the assembleStorage and disassembleStorage functionality (described above in the Tasks list) will be posted under this ticket with descriptions of what is being evaluated in each test.

Description:

Tests must be created to ensure the accurate conversion of sparse matrix data to a dense format, as well as to ensure correct memory handling for this task. We specifically need tests for the functions "assembleStorage(...)" and "disassembleStorage(...)". These tests are necessary to guarantee the compatibility between DEN and other branches within this project.

Tasks:

For 'assembleStorage':

• Create a sparse matrix with known values.
• Use the assembleStorage(...) function to convert the sparse matrix to a dense matrix.
• Check that the correct values are assigned to the matrix
• Validate that the resulting dense matrix matches expected values.

For 'disassembleStorage':

• Start with a dense matrix with known values.
• Use the disassembleStorage(...) function to convert the dense matrix back to sparse format.
• Validate that the resulting sparse matrix matches expected sparse representation (like specific row, column indices, and values).

Definition of done:

This issue will be resolved when both assembleStorage and disassembleStorage tests are implemented and...

• Tests cover multiple edge cases
• Test results are documented and discrepancies are reported
• Tests are passed without memory issues

Description:

The matvec method of the COO class will be tested for a combination of matrices and vectors with known results. Correct size of the output will also be tested.

Tasks:

Implement a test for COO matvec method which catches possible errors like

• Incorrect output vector size

• Incorrect multiplication operation

Definition of done:

Developing tests that test the accuracy of the matvec method

Background

There are several tasks that can be performed on this repository that involve some knowledge or skills not covered in depth in the course. These tasks are extra credit.

Tasks

To complete this issue, the following new issues should be created.

• Add continuous integration testing (See #6)
• Add code coverage testing (See #7)
• Add memory testing (See #8)
• Setup project to build doxygen based documentation (See #10)
• Automatically generate sphinx documentation
• Create a python interface to the library
• Add integration to PETSc matrix types
• Add project packaging
• Add automated formating and linting checks for commits

Definition of Done

The aforementioned issues have been created and accepted. To be accepted each issue should have a milestone, project and project status, and label.

Description:

Add a matvec function to the SparseMatrix_COO class that conducts matrix-vector multiplication. The function takes the x vector and the A matrix (in COO) from function inputs and then conducts matrix-vector multiplication (Ax=b). The resulting b vector is stored in a newly created vector and returned as function output.

Tasks:

• Add function declaration in parent class
• Add function definition
• Initialize the output vector
• Conduct matrix-vector multiplication in COO format and write result to output vector
• Return the output vector

Definition of done:

The matvec method can conduct COO matrix-vector multiplication and passes the test.

I kind of hate that the project is now separate from the repo. But it makes sense because one project may have multiple repositories.

From a cursory review of the new system, it would appear that I also have to add users to the Kanban project. But we'll see what happens after they are added to the repository.

The users that need to be added to the Kanbran project are:

• preetb
• sathvikb
• ruidongd
• junfan
• mngarner
• rgrawe
• shujhan
• maxzog
• tjayasa
• zkjia
• umak
• djke
• whliu
• jdlorenz
• marchier
• ashraym
• pnakhate
• meetm
• jpavelka
• anvay
• quw
• reichowi
• jcrush
• avirup
• arsridha
• welchjc
• nzamb

Description:

The purpose of this task is to create a unit test for the constructors and destructors that are used for allocation and destruction of memory for variables and objects in the DEN matrix class.

Tasks:

• Call the default constructor and ensure that objects have been created as per requirement.
• Call our other parametrized constructors and ensure that all our variables have been initialized.
• Since overloading is being incorporated, ensure that the program is correctly defined such that our constructor calls match properly.
• Ensure that the constructor accepts inputs that are within our desired range of validity.
• Once the previous step is done, we now send invalid inputs such as that of a null matrix or passing negative value for our array sizes to ensure that our constructors and destructors are capable of proper error handling and throwing the necessary errors.
• Ensure that our constructors and destructors work properly with the correct data type and throw error if an incorrect data type is passed.
• Ensure proper functioning of our pointers used to create our class object. and that our object gets destroyed after its creation and usage.
• Ensure that all of our destructors get called properly at the end and that all of our memory gets deallocated.

Definition of done:

When the unit tests defined are capable of correctly catching any issues and throwing an error that signifies correctly any issue that may prevent the proper functioning of memory allocation and deallocation.

Background

To learn how to make use of software development best practices and workflows, its important to have well defined issues.
For our SpMV library, before we start coding, having an established design for teh structure of the classees will facilitate implementation.
Therefore, this issue is about developing some high level designs for possible implementation.

These will be discussed in groups because we think better with small groups of peers.

Tasks

Come up with a UML Class Diagram that includes the attributes for each sparse matrix format.

Definition of Done

A representative from each group has made a comment in this issue describing or showing their design in a UML class diagram.

Description:

Two methods must be created for the assembly and disassembly of a matrix in coordinate format. These methods will be included in the COO class and will allow for the conversion of data from a dense format to a sparse coordinate format.

Tasks:

• Create a method named "assembleStorage" in the COO class

  • takes in a dense array and its number of rows and columns as inputs
  • Allocate space for the same matrix in the COO format
  • returns a COO matrix

• Create a method named "dissasembleStorage" in the COO class

  • takes in a COO matrix as an input
  • Converts this matrix to a Dense matrix
  • deletes the original input matrix
  • returns a COO matrix

Definition of done:

The two methods pass all unit tests to ensure the accurate conversion of matrix data and correct memory handling.

Description:

The purpose of this issue is to implement a matvec method for the DEN matrix class. This method, is responsible for carrying out the matrix vector multiplication for the a 2-dimensional array stored in as a dense matrix where each element is populated with either non-zero values or with zero values. The function interface is virtual fp_type* matvec(fp_type* vecin)

After input, we process matrix vector multiplication as follows where the statement below is placed in a nested for loop that iterates for all elements in a[i][j]:
b[i]=a[i][j]*x[j]

Tasks:

• Create a function that takes in the parameters sent during function call. These inputs are our 2-dimensional array A, vector B and the number of rows and columns. The inputs would be passed as pointers and hence do not necessitate the need for being returned at the end of this method.
• Checks that all the input parameters have been appropriately passed. If not, pass an error. An example of an incorrect input is having negative numbers for the size of the matrix.
• Perform matrix vector multiplication. This would be done in a try and catch block and throw any errors encountered during matrix vector multiplication. Examples of errors that would be caught in this block are mismatch between matrix and vector size or errors due to insufficient memory allocation.

Definition of done:

Provided function is capable of performing matrix vector multiplication as required with the parameters that have been sent during the function call period.

Background

Documentation is always extremely helpful. However, it can also seem extremely daunting if it is put off for awhile and you wait to do it all at once. Fortunately, there is a tool Doxygen that can automatically create pretty formatted documentation in several formats (html, xml, LaTeX and pdf) by processing special markup comments in the source code.

This issue is about setting up the project to automatically create Doxygen documentation based on comments in the source code.

Tasks

• Choose an appropriate output format for documentation
• Define standards for what information the documentation should have.
• Modify CMake build system to create a target for building documentation
• Configure doxygen file for project

Definition of Done

When configuring the project, there is a make target for generating documentation. When executing the make target, the appropriately output documentation is produced. An example of that documentation output is attached somehwere in this issue (could be screen shot, could be file, could be link to somewhere else).

The generation of documentation should also be tested, and the test passing.

Description:

This library should provide interface to return and define a matrix in ELL format. It should implement the ELL library according to the UML diagram(child of SparseMatrix parent class)

Tasks:

1. Make a default constructor as follow:

namespace SpMV
{
    template <class fp_type>
    SparseMatrix_ELL<fp_type>::SparseMatrix_ELL(const int nrows, const int ncols) :
         SparseMatrix<fp_type>::SparseMatrix(nrows, ncols)

    template class SparseMatrix_ELL<float>;
    template class SparseMatrix_ELL<double>;
}

2. Define the attributes specific to the ELL class(colIdx and value) in the constructor.
3. The constructor should take each element of colIdx and value to assemble the class

Definition of done:

Must include a default constructor and a constructor which takes one argument per member variable and directly assembles the class.

Description:

This task defines the accessor methods for the ELL matrix. These methods are used to access protected or private variables of the class. These methods could be used by most other portions of the library. For example, the accessor for matrix coefficients could be used by the matrix-vector method to perform the computations. This task helps to fulfill the functional requirement "The library shall provide interfaces to return or define a matrix in ELLPACK format." because it allows the user to get and set information relevant to the ELLPACK format.

Tasks:

• Identify exactly where these methods would be used in the process of receiving an input matrix, storing it, converting its storage, and using it in matrix-vector multiplication
• communicate with others who depend on this method and who's work this method is dependent on
• develop get and set methods for all relevant attributes. These would likely include matrix coefficients, their indices, and general properties of the matrix.
• determine if set coefficient methods need to be able to add elements into storage instead of replacing existing ones
• determine all the attributes that would be relevant to this library.
• collaborate with other accessor developers and determine their method for implementing and interface

Definition of done:

This task can be complete if methods have been implemented and tested to get and set all relevant attributes. At the bare minimum, the getFormat() and operator()(size_t i, size_t j) methods must be included.

Background

Testing is a key activity in software quality. It is the primary means by which we determine if our change to the code has b roken some existing capability. Tests are tedious to run manually, where your time is valuable.

Therefore, the objective of this issue is to add some auotmated continious integration testing to the repository.

This is a moderate task to complete so it is worth 7 extra credit points)

Tasks

• Define appropriate tool for automating configure/build/test of a github repo.
• Determine under what conditions we want to be able to perform automated testing (each pull request, every hour, etc.)
• Implement auotmated testing protocoals ot repo,/build system/github

Definition of Done

Evidence of the continuous integration tests being run and results posted.

Description:

The library needs to be able to get information about matrices in the dense format. This matrix information will be important for performing dense format operations.

Tasks:

• Be able to determine the number of rows for a dense format matrix
• Be able to determine the number of columns for a dense format matrix
• Be able to determine the element value at given row and column index values for a matrix in the dense format
• Be able to set the element value at given row and column index values for a matrix in the dense format
• Be able to return a "DEN" label for matrices in the dense format

Definition of done:

Evidence of a functional accessor implementation that is able to return index, size, coefficient, and format information about matrices in the dense format

Description:

This issue creates tests for ELL matrix access methods. The library is tested for being able to access a few elements related to the ELL matrix format - ELL column indices, and ELL matrix values. It also tests for the correct implementation for the state, and correct format, and prints relevant messages. Accessor testing is an important way to ensure the matrix information is stored and retrieved correctly.

Tasks:

• Collaborate with the people working on other ELL methods e.g.- ELL_accessor() method to determine the interface and calls.
• Define an ELL_accessor_test() method for testing
• Assert that n_rows,n_cols have been defined using the get() command
• Test the ELL column index matrix is of the right format: ell_colIdx(size_t i, size_t j) (needs to be decided by all of us working on ELL)
• Test the ELL value matrix is rightly defined: ell_val(i,j)
• Test implementation for state
• Test the correct format is returned for ELL
• Check all the outputs and print appropriate error messages

Definition of done:

The accessor testing method is complete when all the relevant checks for the accessor method, rows, columns, ELL column indices, ELL matrix coefficients, state, and format are completed and the relevant messages for these tests - "Test X passed/failed" (where X is the relevant operation defined in tasks) are displayed. This method is important for testing the functioning of all ELL methods.

Description:

This issue describes implementing a method that prints the dense matrix A into a file. The method takes in the dense matrix A, nrows, ncols as the input and prints the 2D matrix into a file with the filename "DEN_matrix.out". View methods are essential to ensure the correct initialization and assignment of matrix coefficients. This view method can also provide a basis for debugging other sparse matrix initialization formats as it can serve as validation.

Tasks:

• Define method: void DEN_view(double **A, const size_t nrows, const size_t ncols)
• Set filename: Define a string for the filename - "DEN_matrix.out"
• Loop through the matrix and print the coefficient to filename using cout >>

Definition of done:

The file "DEN_matrix.out" is created with the dense matrix printed with appropriate spacing between the elements. Sample output:
[a11 a12 a13 ... a1col
a21 a22 a23 ... a2col
...
arow1 arow2 arow3 ... arowcol]

Description:

There needs to be unit tests to determine if the library is able to able to get information about matrices in the COO format. This unit test information will be important ensure that information about matrices in the COO format can be accessed to be used in other COO format operations for a variety of test cases.

Tasks:

• Test that the implementation can return the number of rows for a COO format matrix
• Test that the implementation can return the number of columns for a COO format matrix
• Test that the implementation can return an element value at given row and column index values for a matrix in the COO format
• Test that the implementation can return a "COO" label for matrices in the COO format
• Test that the implementation can identify invalid inputs and return a proper error message

Definition of done:

Evidence of a functional unit test code file that tests if a provided accessor function is able to return index, size, coefficient, and format information about matrices in the COO format

Description:

Unit tests for assembleStorage and disassembleStorage for ELL. These tests are used to check ELL matrix data structure and the accuracy of ELL method. They help us by identifying and resolving any potential issues or discrepancies in how data is packed and unpacked within the ELL matrix.

Tasks:

• These tests will check assembly and disassembly of a variety of matrices with different sparsity patterns.
• These tests will check assembly and disassembly methods dealing with different data types (e.g., integers, floating-point numbers).
• Checking performance for handling large matrices.
• Ensuring that the edge cases are correctly fed in (when moving from one row to the next)

Some tips for writing these tests:

1. Create a dataset and store it in SparseMatrix.
2. Create the reference answer/result to the assembleStorage and disassembleStorage for ELL.
3. Call assembleStorage and compare the colIdx vector, value vector, and the matrix multiplication result to the reference results.
4. Repeat this to check disassembleStorage.

Definition of done:

Tests will catch all bugs of assembleStorage and disassembleStorage for ELL.
Guarantee that these functions work correctly under different conditions.
Ensure that future changes and optimizations to these functions do not introduce regressions

Description:

Test the constructor and destructor of the COO class. Test that:

1. The constructor can create the class and assign the input matrix size to class variables
2. The destruction function can delete the class object properly

Tasks:

• Call the constructor and check whether class object is created
• Check matrix size
• Check memory leak (optional)

Definition of done:

The unit test can check the COO class constructor and destructor and catch bugs if there's any.

Description:

Defines a DEN matrix class that includes a class constructor, destructor, and declares variable types. This is a subclass of SparseMatrix. Declaration of this class also includes declaration of child functions, such as dense matrix-vector multiply.

Tasks:

• Determine what #include preprocessor directives are required
• Communicate with others to determine: namespace name, class name, input arguments, potential outputs
• Incorporate constructor of default and overloaded types, and deconstructor calls
• Determine names of required functions such as assebmleMat(), Matvev(), disassembleMat(), etc.
• Incorporate assembly and diassembly calls that takes data from parent class and constructs dense matrix

Definition of done:

Pass all the unit tests for declaring and calling class. Implement reviewers comments
Must include a default constructor and a constructor which takes one argument per member variable and directly assembles the class. Ensure all blocking issues are resolved before considering this task done. Issues that block the completion of this task is the creation of the SparseMatrix class.

Description:

A COO matrix needs to have following main variables,
size_t _nrows, _ncols, _nnz(inherited)
vector<fp_type> *val
vector<size_t> *rowIdx, *colIdx

To work with these variables, the class requires getters and setters for the number of rows, columns, and non-zeros, which are defined in the parent class with no need for overloading. The constructor method will set these values for the COO matrix being defined. It also stores the vectors of row indices, column indices and the associated values. Default constructor is defined with no functionality. The class will also have other required getter and setter methods. It will also include methods to assemble and dissemble storage, matVec, view the matrix, and a destructor.

Tasks:

• Create the class with a default constructor and an overloaded constructor which takes in nrows, ncols, nnz, vectors of row and column indices and a vector of corresponding values that assigns the rowIdx, colIdx, and value vectors and create the mapping.
• Declare other required methods including buildCoefficient, assembleStorage, dissembleStorage, matVec, and to output the matrix.
• Add a destructor for the object

Definition of done:

Must include a default constructor and a constructor which takes one argument per member variable and directly assembles the class.

Description:

The "assembleStorage" and "disassembleStorage" methods are intended to be added to the CSR (Compressed Sparse Row) class. These methods will facilitate the conversion of data from the base class SparseMatrix into a format that is compatible with the CSR storage format. CSR is a commonly used data structure for representing sparse matrices efficiently.

Tasks:

• Create a method named "assembleStorage" within the CSR class that takes necessary input arguments from SparseMatrix.
• Iterate through the existing data in the SparseMatrix and organize it into three vectors (that should already be variables of the CSR class): values, rowPointers, and columnIndices
• Create a method named "disassembleStorage" within the CSR class that takes input arguments from the CSR format.
• Convert the CSR format back into the format used by the base class SparseMatrix so the reverse of the assembleStorage method.
• Develop a set of unit tests to ensure the correctness of both the "assembleStorage" and "disassembleStorage" methods. Test various scenarios, including different matrix shapes, sparse patterns, and edge cases.

Definition of done:

Unit tests for both methods pass successfully, covering a variety of test cases and edge cases.

Description:

This task adds a program to test the CSR matvec method. This would be considered a Unit Test. This task does not directly satisfy any of the functional requirements, but it is critical to the requirement "The library shall provide an interface to perform sparse matrix vector multiplication". Tests are an important in programming because they ensure the program performs as expected in a variety of use cases.

Tasks:

• Communicate with implementer of CSR matvec method.
• Define a way to verify the output of the CSR matvec method. This will likely include using the input and output vector files we defined in HW2
• Define the ways we want to test invalid input for the CSR matvec method
• add tests that verify output for the CSR matvec method
• add tests that uses invalid and valid input to see how the CSR matvec method handles it
• define the tests for the CSR matvec method in a way that is compatible with cmake and make so that it is called when make test is called

Definition of done:

The test runs successfully when called by make tests. The test for the CSR matvec operation runs successfully when the program returns the correct answer for valid input and exits with invalid input.

Fill this out

Background

Coverage testing is one metric that can be used to assess the quality of the testing on a project. This metric shows how many lines of the source code are executed by the test suite.

In this issue, the objective is to setup automated testing to the continuous integration, so that coverage results from testing are readily accessible to project members.

Tasks

• Determine how to modify automated testing/build system/ test environment or whatever to create a new test action for coverage
• Define the action to run coverage testing
• Have the results posted somewhere that is easily accessible

Definition of Done

Description:

Currently, our ELL matrix implementation lacks comprehensive unit tests for construction and destruction operations. These operations are fundamental to ensure the correct initialization and cleanup of ELL matrices. In order to maintain the robustness and reliability of ELL matrix implementation, add comprehensive construction and destruction tests. These tests will help ensure that the matrix is correctly constructed and properly destroyed, preventing potential memory leaks and resource management issues. Make sure to cover various scenarios, including edge cases and potential sources of errors. The primary goal is to verify that the ELL matrix is correctly initialized, populated, and safely deallocated.

Tasks:

1. Construction Tests: Create a set of tests to validate the correct construction of ELL matrices under various conditions, including different matrix sizes, data types, and initialization methods. This will encompass both standard and edge cases.

• Verify Initialization and Allocation: Test the creation of a simple ELL matrix with a few elements. Validate the behavior when invalid input data is provided during construction.
• Matrix Creation from Existing Data: Verify that the matrix can be constructed from an existing data source, such as an array. Validate the behavior when invalid input data is provided during construction.
• Verifying for Data types: Ensure that the tests cover a wide range of data types and configurations, as the ELL matrix may be used in diverse contexts.
• Edge Cases: Test the matrix constructor with edge cases, such as empty matrices or matrices with a single element.
• All scenarios: Create tests for extreme scenarios, such as very large matrices and matrices with a small number of elements.

2. Destruction Tests: Develop tests to verify that the ELL matrices can be safely and completely destroyed without any memory leaks or resource issues.

• Matrix Destruction: Ensure that the ELL matrix is properly deallocated and memory is released with a note that the matrix can be properly destroyed without memory leaks.
• Create tests for extreme scenarios, such as very large matrices and matrices with a small number of elements.

3. Integration Tests: Integrate the test suite into the project's continuous integration pipeline to ensure ongoing verification of construction and destruction operations.

• Verify proper memory management during construction and destruction. Implement checks to ensure the integrity of the matrices after construction.
• Integration Tests: Integrate the construction and destruction tests into our automated testing pipeline to regularly check for regressions.
• Documentation Updates: Ensure that our documentation is updated to reflect the newly added tests, making it clear to developers and contributors how to run these tests and what to expect.

Definition of done:

• Construction tests for ELL matrices are implemented and successfully pass.
• Destruction tests for ELL matrices are implemented and successfully pass.
• Integration tests are integrated into our automated testing pipeline.
• Documentation is updated to include information on running these tests.

Description:

This will be a unit test added to the DEN matvec method. It will confirm that the vector output by the DEN matvec method is correct which is crucial to confirm the method functions accordingly.

Tasks:

• Collaborate with the person implementing the DEN matvec method
• Utilize the input and output vectors from HW 2
• Loop through the DEN matvec output vector and compare each value to the output file using assertions to a certain precision. If an assertion fails, print an error message stating the output vector is incorrect. This will handle the correctness of the matvec method.
• Create tests to handle invalid input. For example, if passed a non-matching vector size or incompatible matrix dimensions, print an error message stating the input was invalid.

Definition of done:

All of the assertions pass confirming the function produces the correct vector

Description:

To allow conversion between the ELL format and other SpMV formats (and vice versa), we require assembleStorage and disassembleStorage methods. The assembleStorage method will take input locations (i, j) and non-zero (val) values and map them into the ELL format. The disassembleStorage method will do the inverse, that is, take the ELL fomrat and convert it to locations (i, j) and non-zero (val) values.

Tasks:

• Define two arrays: colIdx and value
• Iterate through all non-zero values in original (COO) format and group by rows (i)
• Pad rows so each row is a consistent size
• Store the padded rows in column-major order into colIdx and value arrays (ELL format complete)
• Define three arrays: I, J, val
• Take ELL format and iterate through all colIdx values
• For each row i, get colIdx j and values and append each one to I, J, val arrays

Definition of done:

This issue is considered done when the ELL assembleStorage and disassembleStorage tests all pass.

The purpose of this issue is to add all the students in ners570f23 to this repo for collaboration on upcoming activities.

To complete this issues the following students should be added

• preetb
• sathvikb
• ruidongd
• junfan
• mngarner
• rgrawe
• shujhan
• maxzog
• tjayasa
• zkjia
• umak
• djke
• whliu
• jdlorenz
• marchier
• ashraym
• pnakhate
• meetm
• jpavelka
• anvay
• quw
• reichowi
• jcrush
• avirup
• arsridha
• welchjc
• nzamb

Description:

Add construction and destruction tests for the JDS matrix class to ensure that the matrix is properly constructed or destructed. Includes AssembleStrorage() and DisassembleStorage() as defined in the "Add a JDS matrix class" issue.

Tasks:

-[] Test whether matrix class has been constructed
-[] Test AssembleStorage() to ensure vectors have been allocated correctly
-[] Test DisassembleStorage() to ensure data returns to the general data format in SparseMatrix
-[] Test whether destruction works

Definition of done:

The issue is resolved when the units tests have all passed. The construction unit test will be passed if the matrix class exists. The destruction unit test will be passed if the matrix class does not exist. The AssembleStorage() test will pass if all the vectors are the correct size. The DisassembleStorage() test will pass if the storage vectors don't exist.

Background

In lab 07 we will tasks that students are to create as github issues. This ticket is about tracking the creation and assignment of issues

Tasks

Below are the students who need to submit a reply on this issue
TBD

This issue is about implementing the necessary file/directory structure and build system components in the repository designed in #4.

To complete this issue, the following tasks should be completed:

Definition of Done
All listed tasks are completed, the work is reviewed, and the changes are on the main branch

Description:

This adds functionality to the SparseMatrix library to access data stored in the CSR matrix subclass. This will be needed to perform the core sparse matrix-vector multiplication requirement of the SparseMatrix library. For a given (i,j) index, the corresponding element stored in the CSR format will be returned. If the data is not there in the CSR format, zero will be returned. Furthermore, a method to return the type of sparse storage will be implemented.

Tasks:

• If there is not already a getFormat() in the SparseMatrix superclass, define that method. It should return the enumerated format type.
• Check that the row and column indices are within the bounds of the matrix
• Index the rowPtrs array at the row specified
• Iterate through the colIdx array (or whatever the writer of the class calls it - I can check with them) until the desired column index is reached. If it isn't there then return zero.

Definition of done:

Must include getFormat() and operator()(size_t i, size_t j). The methods should be tested with the corresponding unit tests. Once tested, the implementation will be completed.

Description:

This task adds tests to verify the implementation of the constructors and destructors for the CSR matrix class in the SparseMatrix library. This does not add functionality critical to the function of the code but it is crucial to the requirement "The library shall provide interfaces to return or define a matrix in CSR format." It's important to test this to make sure that we are able to construct the CSR type and properly clean up the memory allocation.

Tasks:

• Talk to the person writing the CSR matrix class to see how they are defining their CSR data arrays.
• Input an example matrix and make sure that the output CSR format matches what I will work out by hand.
• Input some bogus data and make sure that the matrix construction fails.
• Run the destructor and make sure it doesn't fail.

Definition of done:

This will be done when all unit tests are implemented and pass.

Description: Write a bunch of tests to the library to be able to get information about matrices in the CSR format.

These functions should be able to obtain information on the CSR matrix format specifically. These tests are necessary to ensure proper implementation of accessor function to be used in other CSR matrix operations.

Tasks: The following tests are needed:

Test the implementation can return the number of rows for a CSR format matrix
Test the implementation can return the number of columns for a CSR format matrix
Test the implementation can return the element value at given row and column index values for a matrix in the CSR format from the original file source
Test the implementation can return an element value at given row and column index values for a matrix in the CSR format from the class object created
Test the implementation can return a "CSR" label for matrices in the CSR format
Test that the filename of the CSR s returned correctly. Match strings.
Test the number of nonzero entries in the martix. Integer match.
Return a state of the matrix in CSR. How to write the test case TBD.

For all the above tests include error message when tests fail.

Definition of done: Write all the test cases.

Pass the Test for the implementation of printing correct number of rows for a CSR format matrix
Pass the Test for the implementation of printing the number of columns for a CSR format matrix
Pass the Test for the implementation by printing the correct element value at given row and column index values from original source file.
Pass the Test for the implementation by checking the element value at given row and column index values is correct by doing a float/double comparison with the original source file value at the same location.
Pass the Test for the implementation by printing a "CSR" label for matrices in the CSR format
Pass the Test for the implementation by printing the filename of the CSR matrix correctly. Alternatively one can compare strings with given input string from command line. Depends on user.
Pass the Test for the implementation of printing the correct number of nonzero entries in the martix.
Pass the Test for the implementation of printing the a state of the matrix in CSR. How to write the test case TBD.

Background

Tasks

Definition of Done

Description:

The class provides interfaces to define a matrix in JDS format. It is a subclass of SparseMatrix.

Tasks:

• Include two types of constructors, default and overloaded. Default: JDS(). Overloaded: JDS(Matrix data, colIdx, value, iterPtr, row)
• Include destructors.
• Implement assembleStorage() which takes the data from SparseMatrix _buildCoeff to JDS format. The data will be stored in four vectors, one for row order, one for ColIdx, one for value, and one for IterPtr that loop ColIdx.
• Implement disassembleStorage() which is the reverse of assmebleStorage(), that takes data from JDS format to the general data format in SparseMatrix.
• Implement the matrix vector multiplication action method.
• Write methods to get information on function names for the MatVec and build_coeff calls and other dependencies that require information from other peoples code.

Definition of done:

Pass the unit test. The matrix vector multiplication will have the same results as using the DEN format.

Description:

The SpMV program performs sparse matrix multiplication for various formats, one of these formats is the ELL storage type,
this method perform matrix-vector multiplication (Ax=B) when the sparse matrix storage format is ELL. This method will require the input matrix A, the input matrix will need to be stored in a ELL matrix type and will need ELL_row_ptrs and ELL_col_ptrsto accurately assign the matrix, it will also need a vecin and vecout to write the x and B vectors. The multiplication step would require x vector to be informed by the ELL_row_ptrs and ELL_col_ptrs to ensure elements are multiplied correctly.

Tasks:

• Add a function declaration in the parent class
• Define the function definition in the SpMV_ELL.
• ensure ELL tests assembleStorage and disassembleStorage tests pass
• Ensure the vectorin x and matrix A exist in memory
• Convert the matrix A to an ELL sparse storage format
• Perform the matrix multiplication
• Ensure that vectorout B exists in memory
• Write to B
• Return B

Definition of done:

The vectorout should be outputted to the right location and the matrix vector multiplication should happen without errors. It should also pass the tests.

Description:

When working with ELL matrices, it can be challenging to inspect and understand their content due to the specific storage format. Currently, there is no built-in method to view the ELL matrix in a human-readable format, hindering debugging and development processes. This issue proposes adding a new method to the existing codebase that will allow for a more user-friendly view specifically tailored for ELL matrices with output in a new file and also print the matrix.

Tasks:

• Accept ELL matrix as input argument
• If the input is in form of file then load the file correctly
• Check for errors like correct matrix contents, pass for all data types.
• Implement the ell_matrix_view() method to display the ELL matrix.
• Should print the matrix correctly and be added to the matout file.
• Allow customization of the view, such as options to show/hide zero values, adjust column widths, or specifying a delimiter. etc.
• Ensure that the method is well-documented so that users can understand how to use it effectively.
• Test the method with various ELL matrices to ensure it handles different scenarios correctly.

Definition of done:

(Must print the matrix) was mentioned before as a part of the question.

The new method is added to the project and is documented. The method can successfully visualize ELL matrices. Appropriate tests are ran to verify the correctness of the method. The matout files and the print outputs look correct and user-friendly.

Description:

Add assemble storage and disassemble storage functions to the Dense matrix class

Tasks:

• Write an assemble function
  • Inputs are number of rows and number of columns
  • Allocates an array A that is nrows x ncols
• Write a disassemble function
  • Input is the dense matrix A
  • Deletes A

Definition of done:

This task is done when it passes the unit test which will test whether the storage has been created or destroyed.

Description:

if the format is COO then this routine should print the i,j, and values (COO format); Optionally it could also print in matrix form
| a1 b1 c1 d1 0 0 e1 |
| a2 0 0 0 b2 c2 d2 |
.................................
.
.
.
| an bn 0 0 0 0 0 |

This method takes in the roIdx(:), colIdx(:), and value(:) as the input and prints the 2D matrix into a file with filename "COO_matrix.out"

Tasks:

• Coordinate with COO constructor to know the interface
• Define method: void COO_view(double **value, const size_t roIdx, const size_t colIdx)
• Set filename: Define a string for the filename.
• Print the coefficient to filename using cout <<

Definition of done:

Must print the matrix with an appropriate format described above in a "COO_matrix.out"

Description:

The sparse matrix multiplication is implemented in various methods where the matrix is stored in different formats. It would be easier for developers to check the correctness of the CSR method when the matrix is printed in the original 2D format. In light of this, the CSR view method is designed to print the 2D matrix by taking the rowPtrs, colIdx, and value arrays in CSR format.

Tasks:

• Take rowPtrs, colIdx, and value arrays to be the inputs.
• Loop through the elements and rearrange them in a correct 2D matrix format.
• Print the matrix to a file from the given filename.

Definition of done:

The method can print the correct matrix to screen and a file given the arrays in CSR format. The method can pass all the CSR view method tests.

Description:

To allow conversion between the CSR format and other SpMV formats (and vice versa), we require assembleStorage and disassembleStorage methods. This issue will develop tests to ensure these CSR methods are functioning correctly.

Tasks:

• Ensure the assembleStorage and disassembleStorage methods for CSR have been written
• Have multiple datasets in original (COO) format
• Use CSR assembleStorage method
• Get row location i by iterating through row pointers
• For each i, get column location j by iterating through column ID array
• For each i, get value val by iterating through value array
• Compare extracted (i,j) and val to original (COO) format. If all values match, print pass otherwise fail
• Once CSR assembleStorage method passes, use CSR disassembleStorage method
• Compare new (COO) format to original (COO) format. If all values match, print pass otherwise fail

Definition of done:

This issue is considered done when the CSR assembleStorage and disassembleStorage tests all pass.