-
-
Notifications
You must be signed in to change notification settings - Fork 549
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
Issue 3361 - Improve print_parameter_info functionality #3584
Issue 3361 - Improve print_parameter_info functionality #3584
Conversation
Hello! I would appreciate it if someone could review this code. PS: I need to build some test cases. I would be grateful if someone could guide me on how to do it. |
NOTE: I have also tried coding something for #1500 and would be PR-ing it as soon as this PR is resolved. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #3584 +/- ##
========================================
Coverage 99.59% 99.59%
========================================
Files 258 258
Lines 20755 20778 +23
========================================
+ Hits 20670 20693 +23
Misses 85 85 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this on. A couple of stylistic changes suggested. I'm not sure what @brosaplanella had in mind, but it would be easier to just take the existing logic from print_parameter_info
to make a new function called get_parameter_info
which returns a list (instead of printing) - or maybe a dictionary of {parameter: details}
, and then in print_parameter_info
just do
def print_parameter_info(self):
info = self.get_parameter_info()
print(info) # or something else depending on the return type
… and modified "print_parameter_info" to print the dictionary
Hey @tinosulzer, I have implemented the feature following the logic you provided. It would be great if you could review it. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, is this what you had in mind @brosaplanella ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @cringeyburger, looks good to me too. It looks like the print_parameter_info
method is not documented in the API (see #3392), but we have a PR addressing that. I have a small suggestion about the readability of the output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for picking it up @cringeyburger! Looks good to me once the other comments are addressed.
…e parameters instead of their names
…ameter_info" (initial version)
Thanks for waiting! The string formatting took a lot of time.
I think improvements can be made regarding the dynamicness of the table. Otherwise, it should suffice. If there are any requests, I would happily take them in. |
…meter_info" and "print_parameter_info"
…meter_info" in CHANGELOG.md
Regarding the dynamicity of the import pybamm
model = pybamm.lithium_ion.SPM()
submodel = model.submodels["positive primary particle"]
submodel.print_parameter_info() OUTPUT
B) CODE import pybamm
model = pybamm.lithium_ion.SPM()
submodel = model.submodels["positive primary particle"]
model.print_parameter_info() OUTPUT
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look great to me – thanks @cringeyburger! Could you merge the changes from the develop branch and resolve the merge conflicts?
I think we are set to merge the PR. Thanks for helping me through out the issue! Also, I would be pulling another one for #1500, please look forward to it! 👋 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to merge once tests pass
Hii, I just had a small doubt. You can observe that the PR failed a few tests. The question is, why? like the PR doesn't have anything to do with the solvers, so shouldn't the performance remain same? |
Don't worry about those test and benchmark errors, however it looks like the example that is failing is legitimately broken |
I think the example notebook is failing due to the changes made here, it works and passes on other PRs. The notebook should be re-run and the outputs should be updated to get the tabular format for the parameters wherever necessary. The failing code block is this one: spm = pybamm.lithium_ion.SPM()
{k: v for k,v in spm.default_parameter_values.items() if k in spm._parameter_info} Another thing to be noted here is that we have previously been using a private API (i.e., |
Is there something I can help with? I would like to know the ins and outs of the project better. |
Yes, could you run and fix the notebook locally and push the newer outputs? I think it arises because |
I went through the notebook, ran some things and noticed a few things. A) The problem with simply removing EXAMPLE:
{k: v for k,v in spm.default_parameter_values.items()} OUTPUT:
{k: v for k,v in spm.default_parameter_values.items() if k in spm._parameter_info} OUTPUT:
Clear difference can be observed between the two outputs. NOTE: I used the output from So the first solution that comes to mind is that we replace B) Another problem is, the current
We can achieve this by using the following code snippet {k: v for k, v in spm.default_parameter_values.items() if any(k == getattr(param, 'name', str(param)) for param, _ in spm.get_parameter_info())} This snippet gives the same output we get when we use
This would make things easier for future development and contributors, for it would make things consistent and easy to understand at a glance. --> So, I think it would be better if we could rebuild the methods to use dictionaries instead of list of tuples. I am open to discussions and ideas, please do comment anything that comes to your mind. In the meantime, I am rebuilding the methods to use dictionaries. Thanks! |
… print parameter info from a dictionary. Modified "print_parameter_info" to store the info in a list "table" and then print it.
…er_info-functionality' into issue-3361-improve-print_parameter_info-functionality # Conflicts: # pybamm/models/base_model.py
… print parameter info from a dictionary. Modified "print_parameter_info" to store the info in a list "table" and then print it.
…and corrected method mentioned in "1.9. Finding the parameters in a model" in "parameterization.ipynb" notebook
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
Ah I probably misphrased my comment. Yes, the cell's output contained identical parameters with or without |
I think we are ready for testing. Hoping it'll pass all tests so we can merge this branch without any issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @cringeyburger! Looks good to me now – just a few comments on style and docstrings
Thanks for the help! Also, I noticed that in the previous commit, the PR failed again on benchmark tests (well, the good thing is it passed all other tests). |
This is an issue with GitHub Actions runners in general – they run on indefinite infrastructure and are stochastic with their specifications, which can sometimes mean slower benchmark times and therefore failures. The regressions appear when the time taken for the benchmarks' code to run is longer than a threshold we have set for those benchmarks, so having them unreliably occur once in a blue moon or twice for that matter is alright; it should not be a large slowdown (say, of the order of 3x–4x) . I don't think your changes in this PR are touching any parts of the benchmarks so these were just statistical outliers. |
Thanks! That was informative. So, we won't face any problems with merging this PR, right? |
Hey @agriyakhetarpal @tinosulzer! This PR is ready for testing. I would appreciate it if we proceed further. |
Yes, this should be ready and safe to merge. The Linux and macOS failures are just a one-off CMake cache issue which came from an update to its version – the cache contained |
Description
Implemented "parameter_info" method to extract parameters and modified "print_parameter_info" to print the required parameters.
Fixes #3361
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.
Key checklist:
$ pre-commit run
(or$ nox -s pre-commit
) (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)$ python run-tests.py --all
(or$ nox -s tests
)$ python run-tests.py --doctest
(or$ nox -s doctests
)You can run integration tests, unit tests, and doctests together at once, using
$ python run-tests.py --quick
(or$ nox -s quick
).Further checks: