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

Analyser: reworked the analysis of a model with external variables #1077

Merged
merged 17 commits into from
Jan 27, 2023

Conversation

agarny
Copy link
Contributor

@agarny agarny commented Dec 21, 2022

Fixes issue #1074.

By decrementing things wherever possible, which makes the code easier to read and, therefore, to update/maintain.
We used to do handle them after having analysed the model which meant having to requalify a variable-based constant equation as an algebraic equation if it depended on one or several external variables. In other words, as a developer, we had to think about what consequence(s) an external variable might have on our analysed model. Until now, it wasn't too much a problem, but with our wish to support systems of non-linear algebraic equations (and then DAEs), this is going to become a nightmare.
... since we may have only generated warnings.
With:
```
mDependencies.erase(std::remove_if(mDependencies.begin(), mDependencies.end(),
                                   [=](const auto &dependency) -> bool {
                                       return dependency.lock()->variable() == nullptr;
                                   }),
```
it reports that the first line is not covered...!?
Even with:
```
mDependencies.erase(std::remove_if(mDependencies.begin(), mDependencies.end(), [=](const auto &dependency) -> bool {
                        return dependency.lock()->variable() == nullptr;
                    }),
                    mDependencies.end());
```
GCov reports that the first line is not covered...!? So, we now put everything on stupidly long line!
@agarny
Copy link
Contributor Author

agarny commented Dec 21, 2022

I will likely have another quick look at it tomorrow morning, but I believe this is ready to be reviewed.

This PR:

  1. improves the handling of external variables in the analyser, as well as
  2. moves that handling as early as possible in the analysis of a model.

The second point is really the reason behind this PR since right now an equation of type VARIABLE_BASED_CONSTANT has to be requalified as an ALGEBRAIC equation if it relies on external variables (see here).

With this PR, by handling external variables as early as possible, we do NOT need to do any requalification anymore (see here). This is going to be particularly useful when addressing issue #882 since external variables could otherwise make things rather tricky.

@agarny
Copy link
Contributor Author

agarny commented Dec 21, 2022

Ok, just a minor cleaning up of the code and various dummy commits that eventually resulted in the CI passing as its should have in the first place (what a waste of time!). So, now, all good to review. @hsorby and @nickerso.

@luciansmith
Copy link

When nothing actually needs to be changed to get the CI to pass, you should be able to just click the 're-run failed tests' button; you don't need a whole dummy commit. Just FYI; I went through that phase myself before figuring it out.

@agarny
Copy link
Contributor Author

agarny commented Dec 21, 2022

When nothing actually needs to be changed to get the CI to pass, you should be able to just click the 're-run failed tests' button; you don't need a whole dummy commit. Just FYI; I went through that phase myself before figuring it out.

Agreed when it comes to GitHub Actions. I have done it on occasions, but we are not using GH Actions for our CI. We use Buildbot and, yesterday, I tried to rerun one of the tests and it passed, but its updated status wasn't reflected in GitHub. So, I had to create a dummy commit and hope for the best. Anyway, will see what @hsorby has to say about it. All I know is that it's very frustrating and a waste of people's time.

@agarny
Copy link
Contributor Author

agarny commented Jan 14, 2023

@hsorby and @nickerso: would be nice to have this one reviewed (and then PR #1080).

Copy link
Contributor

@nickerso nickerso left a comment

Choose a reason for hiding this comment

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

Assuming CI gets back to showing this as passing, then it looks good to me. I did wonder if there needed to be an update to the docs to go along with this change, but then I found: https://libcellml.org/documentation/v0.4.0/user/asides/analyser#understanding-analyser, so that will be a future issue ;-)

@agarny
Copy link
Contributor Author

agarny commented Jan 25, 2023

I did wonder if there needed to be an update to the docs to go along with this change, but then I found: https://libcellml.org/documentation/v0.4.0/user/asides/analyser#understanding-analyser, so that will be a future issue ;-)

🤪

@hsorby hsorby merged commit 0f695ca into cellml:main Jan 27, 2023
@agarny agarny deleted the issue1074 branch January 27, 2023 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants