Parallel improvement (switch back to 4-argument input).

[panasun1994]

The problem

Af ther I created the first documentation for running parallel from Python, I still have a question: What is the trade-off if you input only the file_name instead of the 4 args (dec, state, schedule, summary config)? The answer is that the simulator ignores the well control function, such as shut_well.

Why

Because when it comes to the mpirun from Python, in the readDeck function, if you have only file_name input, the simulator will create its own schedule on rank 0, and the schedule is empty on the other ranks. On the other hand, readDeck will keep the schedule in every rank when it receives 4 args as input. Without handling the schedule, you cannot control the well; i.e., you can't shut/open/close the well.

The solution

The real argument that prevents MPI parallelism in Python is the Eclipstate. So, we can normally input the 4args with state = None. The other 3 arguments will work as in the sequential case.

To Reviewer

You can write the Python code to test the shut_well function in both file_only input and 4 args input, and compare them. If you want my test code, please let me know. I am happy to share.

[hakonhagland]

@panasun1994 Thanks for this, and for tracking down the shut_well behavior. I have reproduced it: in a 4-rank run, a shut_well made through the Schedule passed to BlackOilSimulator(deck, None, schedule, summary_config) takes effect, while with the filename constructor there is no way to reach the simulator's own Schedule from Python at all.

Before I post a full review, I would like to check whether this is better fixed in the opm-simulators Python bindings themselves — for example, by letting the simulator return the Schedule it actually uses, so that well controls work with the filename constructor and the None workaround is not needed. If that turns out to be feasible, the documentation could stay simpler. I will get back to you here with the review either way.