Fix resetting ReturnData::numstepsB when re-using Solver

[dweindl]

Fixes #1813

[codecov]

Codecov Report

Merging #1841 (16cb3cb) into develop (3fecfd7) will increase coverage by 0.67%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #1841      +/-   ##
===========================================
+ Coverage    76.32%   77.00%   +0.67%     
===========================================
  Files           74       74              
  Lines        12834    13879    +1045     
===========================================
+ Hits          9796    10687     +891     
- Misses        3038     3192     +154     

Flag	Coverage Δ
cpp	72.97% <100.00%> (+0.18%)	⬆️
petab	59.40% <ø> (ø)
python	69.17% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/amici.cpp	72.53% <100.00%> (+0.79%)	⬆️
src/backwardproblem.cpp	65.42% <100.00%> (+0.65%)	⬆️
python/amici/sbml_import.py	86.62% <0.00%> (-7.20%)	⬇️
python/amici/ode_export.py	91.96% <0.00%> (-0.95%)	⬇️
src/solver_cvodes.cpp	70.23% <0.00%> (+0.16%)	⬆️
src/sundials_matrix_wrapper.cpp	80.57% <0.00%> (+0.40%)	⬆️
src/exception.cpp	81.08% <0.00%> (+5.40%)	⬆️
ThirdParty/gsl/gsl/gsl-lite.hpp	86.44% <0.00%> (+5.48%)	⬆️
src/spline.cpp	72.04% <0.00%> (+6.45%)	⬆️

[FFroehlich]

sounds like numsteps is also not properly ordered in some cases?

[dweindl]

sounds like numsteps is also not properly ordered in some cases?

The last one seems to be 0 sometimes 🤔

[dweindl]

sounds like numsteps is also not properly ordered in some cases?

The last one seems to be 0 sometimes thinking

Ah, for t=inf it should just copy the previous value, as it's supposed to be the cumulative sum.

[FFroehlich]

sounds like numsteps is also not properly ordered in some cases?

The last one seems to be 0 sometimes thinking

Ah, for t=inf it should just copy the previous value, as it's supposed to be the cumulative sum.

would keep the numbers as is, as otherwise we would also have to carry over numbers from pre-equilibration and it's probably less confusing if these values are kept separate.

[dweindl]

would keep the numbers as is, as otherwise we would also have to carry over numbers from pre-equilibration and it's probably less confusing if these values are kept separate.

Ok. Could consider changing from cumulative sum to deltas, at some point...

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication