Add max_memory keyword to the Everest config

[verveerpj]

Issue
Resolves #10624
Resolves #9569

Approach
Add the keyword, add to generated ert config

(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 unit tests pass locally after every commit (git rebase -i main --exec 'just rapid-tests')

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: Add backport label to latest release (format: 'backport release-branch-name')

[codspeed-hq]

CodSpeed Performance Report

Merging #10637 will not alter performance

_{Comparing add-max_memory (d431fb3) with main (9097b8b)}

Summary

✅ 25 untouched benchmarks

[oyvindeide]

Looks good, I have one question that is slightly more work, but think it might be worth it in the long run, not sure what you think?

[oyvindeide]

Can we reuse this?

ert/src/ert/config/queue_config.py

Line 364 in 99d7804

def _parse_realization_memory_str(realization_memory_str: str) -> int:

[verveerpj]

done.

[oyvindeide]

This would entail a bigger refactor, which would also touch ert, but there is a concept in ert of generic queue options, and I think this one probably belongs with that

ert/src/ert/config/queue_config.py

Line 40 in 99d7804

class QueueOptions(

[verveerpj]

Yes, I noted that also. It seems not everything lives in there though, for instance the QueueOptions base class does contain max_running, but not max_runtime, or realization_memory, they live in QueueConfig. Maybe realization_memory does belong in the options class since it is basically a property you set in the node. But maybe that is true for some of the other fields too? Changing that should maybe a separate issue since it touches ERT.

Also, then the question is if it changes the Everest config: Do we keep max_memory as a field in SimulatorConfig? Or does the user have to specify it in the queue-specific options?

[frode-aarstad]

This is somewhat related to this issue #10628. If we had the same keyword for max memory for everest and ert it would simplify giving the user error messages like this.