Add script for generating bigpoly test-data

[jonathan-eq]

Approach
✏️

(Screenshot of new behavior in GUI if applicable)

• PR title captures the intent of the changes, and is fitting for release notes.
• Added appropriate release note label
• Commit history is consistent and clean, in line with the contribution guidelines.
• Make sure tests pass locally (after every commit!)

When applicable

• When there are user facing changes: Updated documentation
• New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
• Large PR: Prepare changes in small commits for more convenient review
• Bug fix: Add regression test for the bug
• Bug fix: Create Backport PR to latest release

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.67%. Comparing base (acfc8c9) to head (2b98021).
Report is 10 commits behind head on main.

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     

Flag	Coverage Δ
gui-tests	75.92% <ø> (-0.23%)	⬇️
integration-tests	53.97% <ø> (-0.22%)	⬇️
unit-tests	68.69% <ø> (-0.12%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[berland]

do we need these lines here?

[jonathan-eq]

I think we should add them for normal poly_example too. It is very easy to commit logs and poly_out by mistake

[berland]

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.

[xjules]

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 make_bigpoly should be enough?

[jonathan-eq]

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 make_bigpoly should be enough?

I want to add a file modify_bigpoly.sh in komodo-releases/
The script will checkout the bigpoly script from ert, run it, then append the other queue_options for cluster

[xjules]

After giving big-poly some thoughts I've realized that this case / test should remain only in komodo IMHO. Semantically it only serves as a testing detail related to our production environment and as such it does not provide any value to potential users of ert. Any thoughts @sondreso @berland

[jonathan-eq]

After giving big-poly some thoughts I've realized that this case / test should remain only in komodo IMHO. Semantically it only serves as a testing detail related to our production environment and as such it does not provide any value to potential users of ert. Any thoughts @sondreso @berland

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.

[xjules]

Suggestion: Let's create a new issue, which would aim to have such a case in test-data, where we should give it a better name (than big-poly) and make a readme, which describes utilization of such a case; ie. stress-testing the messaging system and internationalization.

[berland]

It probably belongs in tests/performance_tests as a pytest test.

[xjules]

It probably belongs in tests/performance_tests as a pytest test.

do you mean to move the entire big-poly there?

[berland]

It probably belongs in tests/performance_tests as a pytest test.
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.

[jonathan-eq]

It probably belongs in tests/performance_tests as a pytest test.

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 copy_poly_example. It is easier to do it this way than the other way around.