Use d_prototype when solving PDSProblems

[SKopecz]

All (SSP)MPRK algorithms use d_prototype to initialize destruction vectors when solving a PDSProblem.

[SKopecz]

TODO:

• Add tests
• Update doc strings

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 93.75000% with 1 line in your changes missing coverage. Please review.

Project coverage is 98.24%. Comparing base (4fdc654) to head (2bf3d06).

Files	Patch %	Lines
src/mprk.jl	90.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #99      +/-   ##
==========================================
- Coverage   98.32%   98.24%   -0.08%     
==========================================
  Files           6        6              
  Lines        1250     1257       +7     
==========================================
+ Hits         1229     1235       +6     
- Misses         21       22       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ranocha]

Risking to be annoying for you, I have thought a bit more about the d_prototype issue. In the end, I think you are probably right and we do not need the p_prototype for now - we should just use similar(u0) (instead of zeros(eltype(u0), length(u0))). This also enables GPU arrays and stuff like that. Moreover, I do not really see that using a sparse version of the destruction terms will be crucial for performance since the linear system solves will dominate everything. Thus, it will likely be better to keep a simpler structure to reduce the amount of code we have to maintain.

If you agree and are not too annoyed by my premature thoughts earlier, we can keep the improvements to the docs for d_prototype from this PR - maybe moving that to another PR and mark this one here as draft for future reference? Then, we should remove the d_prototype stuff in another PR which brings a breaking change (since we change the documented API).

[ranocha]

We should definitely merge these documentation clarifications!

[SKopecz]

I guess we should also keep this test (without the d_prototype parts) ?

[ranocha]

Yes 👍

[SKopecz]

If you agree and are not too annoyed by my premature thoughts earlier, we can keep the improvements to the docs for d_prototype from this PR - maybe moving that to another PR and mark this one here as draft for future reference? Then, we should remove the d_prototype stuff in another PR which brings a breaking change (since we change the documented API).

Okay, let's do this.

[SKopecz]

This draft will not be pursued further. See #104 instead.