-
Notifications
You must be signed in to change notification settings - Fork 107
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
Add script for generating bigpoly test-data #8470
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8470 +/- ##
==========================================
- Coverage 90.82% 90.67% -0.16%
==========================================
Files 348 346 -2
Lines 21143 21022 -121
==========================================
- Hits 19204 19062 -142
- Misses 1939 1960 +21
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
8a6909a
to
57cf826
Compare
57cf826
to
2b98021
Compare
@@ -34,3 +34,6 @@ src/ert/shared/version.py | |||
/compile_commands.json | |||
*_pb2.py | |||
*_pb2.pyi | |||
/test-data/bigpoly/* | |||
!/test-data/bigpoly/make_bigpoly.sh | |||
!/test-data/bigpoly/generate_eclsum.py |
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.
do we need these lines here?
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.
I think we should add them for normal poly_example too. It is very easy to commit logs and poly_out by mistake
Should we have a PR in gkomodo-releases that demonstrates that it is able to build on this PR? It should get the grdecl script from Ert and generate the remaining queue system tests based on the files dumped by this script. |
Yes, I wanted to suggest the same. Also to have a small description how to run / build big poly or is it so simple to run the |
I want to add a file |
When refactoring snapshots, it was very useful to have a heavy run, so we had to manually clone over bigpoly from komodo-releases. This was more difficult than it had to be, and most of the bigpoly files created by the script are not for running on cluster anyways. Instead of manually cloning the script from komodo-releases and removing the cluster side of it, i think it is better to have the essential part of the script in Ert, and a smaller script for bigpoly_cluster in komodo. |
Suggestion: Let's create a new issue, which would aim to have such a case in |
It probably belongs in |
do you mean to move the entire big-poly there? |
Probably a more carefully written test setup that in some way stresses the message system without touching implementation details, with and without some mocked cpu-intensive internalization. |
I don't think so. I mainly use bigpoly for manually testing the GUI. If we want a pytest performance test for it, we can create a fixture and use it the same way we use |
Approach
✏️
(Screenshot of new behavior in GUI if applicable)
When applicable