Add a vector class to GridKit

[pelesh]

Description

Add vector class to GridKit to replace std::vector and provide portable data management.

Proposed changes

The LinearAlgebra::Vector class was ported from Re::Solve. It has basic initialization and data management functionality. I can be use as a vector, multivector or vector view class.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• I have updated CHANGELOG.md to reflect the changes in this PR. If this is a minor PR that is part of a larger fix already included in the file, state so.

Further comments

The multivector capability in this class should replace DenseMatrix object in GridKit.

[PhilipFackler]

For an all-in-one solution like this, I would prefer some revisions as explained in my line comments. None of those is a deal-breaker if this is meant only for "advanced" use-cases, but I still think it would be helpful.

[PhilipFackler]

This would make more sense as part of a constructor. An instance should be constructed with ownership and data (if non-owning) for host and device respectively. Ownership should not be allowed to change. And I think the data you're wrapping in the non-owning case shouldn't be allowed to change either. This function wouldn't exist in that case.

[pelesh]

I agree, changing ownership after construction is looking for trouble.

This method was experimental and should not be a part of the vector class.

[pelesh]

This method was used to get a vector from a multivector. Better solution is to construct non-data-owning vector object instead, or create a separate VectorView object as @lukelowry suggested.

[pelesh]

I restricted this function to be able to operate only on vectors with data not allocated. Intended use would be:

Vector v(n)
...
double* data = new double[n];
...
v.setData(data);

The danger is still that user needs to set data that matches the vector size. This is a makeshift solution to create vector views for now.

[PhilipFackler]

This is why I think it should be part of the constructor.

Vector v;
...
double* data = new double[n];
...
v = Vector(n, data);

[pelesh]

For an all-in-one solution like this, I would prefer some revisions as explained in my line comments. None of those is a deal-breaker if this is meant only for "advanced" use-cases, but I still think it would be helpful.

All of your suggestions are spot on and should be incorporated before this PR is merged.

[lukelowry]

I think we need a zombie approach if we do merge this implementation. We should take the best parts of this and graft them onto a more scalable implementation that can isolate the Component in memory (is "closure" the right word here?).

[PhilipFackler]

What if the memspace not passed to the function had already been tagged as updated?

[pelesh]

It will be tagged as out of date. This is desired behavior.

[nkoukpaizan]

A few minor comments.

I'm not convinced the class in GridKit needs to mirror Re::Solve, and I tend to prefer solutions that are driven by the application needs first, but I'm willing to see what happens when we try to use this in GridKit.

[nkoukpaizan]

I recommend removing references to resolve, even if commented.

[nkoukpaizan]

I don't recall that we've defined this yet. Now may be a good time. Need to clarify GRIDKIT_ENAGLE_ vs GRIDKIT_USE_ if we choose to differentiate between CMake options and pre-cprocessor directives.

[pelesh]

I would use the same names for both.

[shakedregev]

Why is this test commented out?

[shakedregev]

Address the comment and clarify that this is ready for testing.