Conversation
…(keep existing compat)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.42.1 to 1.43.3. - [Release notes](https://github.com/crate-ci/typos/releases) - [Changelog](https://github.com/crate-ci/typos/blob/master/CHANGELOG.md) - [Commits](crate-ci/typos@v1.42.1...v1.43.3) --- updated-dependencies: - dependency-name: crate-ci/typos dependency-version: 1.43.3 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…-08-00-28-43-503-03382000766' into bg/fix-retcode-check
…-08-00-29-24-487-00230620603' into bg/fix-retcode-check
…-20-00-20-01-226-02439714846' into bg/fix-retcode-check
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #276 +/- ##
=======================================
Coverage 96.11% 96.11%
=======================================
Files 25 25
Lines 1260 1260
Branches 74 74
=======================================
Hits 1211 1211
Misses 45 45
Partials 4 4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Not 100% sure to be honest 😅. I think it was such that you have all packages you might need installed - how would you do time integration from C/Fortran instead?
Yes, but I am not sure if there are similar preferences for the split packages (maybe ask in the Trixi channel or at the next meeting) |
Our
As discussed on slack, there is no similar setting for split packages. |
This PR originates from: https://github.com/trixi-framework/libtrixi/actions/runs/21808243190/job/62915273766#step:19:211
According to the docs (https://docs.sciml.ai/SciMLBase/stable/interfaces/Solutions/#SciMLBase.ReturnCode) the return code has be checked for success differently, and this is what I did.
I am not sure which version actually introduced the change which made the old check fail, nor do I know which version introduced support for the new check.
Instead, I decided to move to the split OrdinaryDiffEq packages, which I wanted to do at some point anyway.
Doing so, I realized we actually do not need OrdinaryDiffEq in LibTrixi.jl itself (just like with Trixi.jl).
Remaining questions @sloede
libtrixi/LibTrixi.jl/test/Project.toml
Line 10 in f5fffee