Jonathan Karlsen

Can this have been fixed by something else? I ran with `--count=2000` both locally and on rgs node, and both passed. > Reproduced locally with `pytest -vs tests/unit_tests/simulator/test_batch_sim.py::test_stop_sim --count=1000 -k...

> ## [Codecov](https://app.codecov.io/gh/equinor/ert/pull/7862?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=equinor) Report > Attention: Patch coverage is `87.40741%` with `17 lines` in your changes are missing coverage. Please review. > > > Project coverage is 85.43%. Comparing base...

What should the filename be? @berland I have some ideas: * bhist_job_summary.txt * lsf_job_summary.txt * job_summary.txt (would not be created for other queue systems than lsf anyways)

The one on the left is lsf stdout while the right one is the bhist long version. 

The lsf stdout already provides all the information found in `bhist -l`, so echoing the output to a file wouldn't give us anything extra.

One field that is not included in lsf stdout is `Dispatched to , Effective RES_REQ `. Maybe getting the resource requirement string would be reason enough to keep the output?...

I have manually tested this, and it works :)

> This is only for the convencience of the user. The inconvenience is to figure out which number to pick for `-n` when running this an arbitrary amount of time...

> I think `debug` log level means it will not be propagated to central logger (if that is installed) 🤔 I re-added the `logger.info(...)` line. Should I prefix it with...

> > Is this sufficient? > > Is it effectively logged twice?? Yes, to the two different loggers (lsf-driver and driver)