search

SKopecz / PositiveIntegrators.jl

A Julia library of positivity-preserving time integration methods
https://skopecz.github.io/PositiveIntegrators.jl/
MIT License
13 stars 4 forks source link

Use `d_prototype` when solving `PDSProblem`s #99

Open SKopecz opened 3 months ago

SKopecz commented 3 months ago

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

SKopecz commented 3 months ago

TODO:

codecov-commenter commented 3 months ago

:warning: Please install the 'codecov app svg image' 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 :warning:

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

Additional details and impacted files ```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

ranocha commented 3 months ago

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).

SKopecz commented 3 months ago

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 commented 3 months ago

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