Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 1422 #1461

Merged
merged 6 commits into from
Mar 15, 2021
Merged

Fix 1422 #1461

merged 6 commits into from
Mar 15, 2021

Conversation

paulstapor
Copy link
Contributor

fixes #1422

@codecov
Copy link

codecov bot commented Mar 15, 2021

Codecov Report

Merging #1461 (f76bccd) into develop (9d36032) will increase coverage by 0.03%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1461      +/-   ##
===========================================
+ Coverage    79.15%   79.19%   +0.03%     
===========================================
  Files           66       66              
  Lines        10191    10196       +5     
===========================================
+ Hits          8067     8075       +8     
+ Misses        2124     2121       -3     
Flag Coverage Δ
cpp 75.79% <100.00%> (+0.06%) ⬆️
petab 69.72% <ø> (ø)
python 67.88% <ø> (ø)

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

Impacted Files Coverage Δ
src/steadystateproblem.cpp 86.03% <100.00%> (+0.19%) ⬆️
src/solver_cvodes.cpp 70.41% <0.00%> (+0.20%) ⬆️
src/exception.cpp 91.30% <0.00%> (+8.69%) ⬆️

@dweindl dweindl linked an issue Mar 15, 2021 that may be closed by this pull request
throw AmiException("Steady state sensitivity computation failed due "
"to unsuccessful factorization of RHS Jacobian");
}
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really necessary? To me it looks like the sensi are already initialized above (and that code also accounts for whether we are doing pre/post-equilibration).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tried in my first commit what happens if we just skip the computeNewtonSensis().
There was an error for the Raimundez model, i.e. a model with preequilibration. In that case, no solver object had been created at that point and it ran into a core dump

terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
Aborted (core dumped)

So I guess the problem was a sx0 wasn't written to sx_. This is, why I added this...
I'm happy about any better idea

Copy link
Member

@FFroehlich FFroehlich Mar 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the first code block will be executed, no matter what you do in the changes.

In your first code attempt, you modified the flag whether sensitivities are necessary or not. What I am proposing here is:

    if (getSensitivityFlag(model, solver, it, SteadyStateContext::newtonSensi) && numsteps_[0] > 0)
    {
            try {
                /* this might still fail, if the Jacobian is singular and
                 simulation did not find a steady state */
                newtonSolver->computeNewtonSensis(sx_);
            } catch (NewtonFailure const &) {
                /* No steady state could be inferred. Store simulation state */
                storeSimulationState(model, solver->getSensitivityOrder() >=
                                     SensitivityOrder::first);
                throw AmiException("Steady state sensitivity computation failed due "
                                   "to unsuccessful factorization of RHS Jacobian");
            }
    }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the failures in the tests are due to reinitialization with the initial state instead of keeping the simulated state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the initialization has been done anyway... I think what you propose is logically equivalent to changing the flag, but let's give it a try...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the initialization has been done anyway... I think what you propose is logically equivalent to changing the flag, but let's give it a try...

storeSimulationState(model, getSensitivityFlag(model, solver, it, SteadyStateContext::sensiStorage));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing that one out!
The whole logic when which sensitivity is need in that code is frustrating sometimes...

@sonarcloud
Copy link

sonarcloud bot commented Mar 15, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@paulstapor paulstapor merged commit 68a8f4f into develop Mar 15, 2021
@FFroehlich FFroehlich deleted the fix_1422 branch March 15, 2021 17:29
@dweindl dweindl mentioned this pull request Mar 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Steadystate solver fails if preequilibration starts in steadystate
2 participants