Add basic validations to ForwardModelStepPlugin such as executable exists
- Dominant language
- Python
- Stars
- 161
- Forks
- 140
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 138
Description
### What happened? (You can include a screenshot if it helps explain)
A user can create a ForwardModelStepPlugin to use in Ert with a bad path to an executable, and this will not be validated before it blows up mid run.
Discuss whether we should add this validation or not, or whether this is Ert's responsibility in the `ForwardModelStepPlugin` constructor, or the FM implementor's responsibility through the `ForwardModelStepPlugin.validate_pre_experiment(...)` api.
It should at most be a warning, because there can be forward models preceding this one that creates the necessary files/executables.
See previous discussion under PR: https://github.com/equinor/ert/pull/8735
### What did you expect to happen?
Warning if a non existent executable is provided, with a explanation that it might be ok
### steps to reproduce
Create a forward model step plugin with a bad executable.
### Environment where bug has been observed
- [ ] python 3.8
- [ ] python 3.9
- [ ] python 3.10
- [ ] python 3.11
- [ ] python 3.12
- [ ] macosx
- [ ] rhel7
- [ ] rhel8
- [ ] local queue
- [ ] lsf queue
- [ ] slurm queue
- [ ] openPBS queue
- [ ] used flag `--enable-scheduler`
Contributor guide
Research direction
Start by reviewing the previous discussion in PR 8735, then inspect the ForwardModelStepPlugin constructor and validate_pre_experiment(...) API. Clarify which layer owns the check and how to handle executables created by earlier forward-model steps. Done means an agreed warning behavior for a missing executable, with tests covering the relevant validation path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100