Defined Base.copy as per-required, e.g., by NLSolve.jl OneDifferentiable

[amartinhuertas]

No description provided.

[codecov-commenter]

Codecov Report

Merging #12 (d231a40) into master (65b7a26) will increase coverage by 0.26%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #12      +/-   ##
==========================================
+ Coverage   72.54%   72.81%   +0.26%     
==========================================
  Files           3        3              
  Lines         204      206       +2     
==========================================
+ Hits          148      150       +2     
  Misses         56       56              

Impacted Files	Coverage Δ
src/SparseMatricesCSR.jl	100.00% <ø> (ø)
src/SparseMatrixCSR.jl	67.62% <100.00%> (+0.47%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 65b7a26...d231a40. Read the comment docs.

[fverdugo]

Thanks for this @amartinhuertas !

[fverdugo]

Feel free to register a new patch version.

[fverdugo]

Hi @amartinhuertas!

this PR is making Gridap to crash. See e.g., https://github.com/gridap/Gridap.jl/pull/669/checks?check_run_id=3811313579#step:6:229

in any case this PR is correct!

The problem is that now we end up working with SparseMatricesSCR (as it should be) and it seems
that lu! is not yet implemented for this type.

We have 2 options.

1. Implement it now and see if Gridap works again
2. Pin SparseMatricesCSR to the previous version in Gridap and implement the missing method later.

Can you help with either 1. or 2. ?

[amartinhuertas]

Yes. I would pursue 1. better. How lu! should be implemented for this type? By transforming to CSC? (just guessing ... I did not give it a profound though).

[amartinhuertas]

in any case this PR is correct!

Of course it is. hehehe. We were transforming sparse matrices into dense matrices. This is veeeery dangerous.

[fverdugo]

How lu! should be implemented for this type?

as a first approach I would convert to native julia csc format. It should be a method convert for this somewhere.

Of course, when we have a 0-based csr the most efficient way would be to provide the raw data to UMFPACK but I don't know if we have time to do this now...

[amartinhuertas]

See e.g., https://github.com/gridap/Gridap.jl/pull/669/checks?check_run_id=3811313579#step:6:229

Is there only one test that fails or there are others as well? I am wondering if we need something else than lu ...

[amartinhuertas]

It should be a method convert for this somewhere.

Yes, indeed, there is.

Of course, when we have a 0-based csr the most efficient way would be to provide the raw data to UMFPACK but I don't know if we have time to do this now...

Agreed. Let us leave this for another moment. I will open an issue.

[fverdugo]

When we have a 1-based csr, perhaps we can build a csc with the raw data (which will be the transpose) and then call lu! with Tanspose(csc). Perhaps there is an efficient implementation of lu! for Transpose{<:SparseMatrix}. In any case, this is just an optimization that can be done later.

[fverdugo]

Is there only one test that fails or there are others as well? I am wondering if we need something else than lu ...

I don't know. grep -r SparseMatrixCSR test/ will give you the potentially problematic tests.

[amartinhuertas]

I don't know. grep -r SparseMatrixSCR test/ will give you the potentially problematic tests.

Ok. I will run the tests locally.