Reservoir coupling: Add end-of-sync-step slave-to-master data exchange

[hakonhagland]

• Add end-of-sync-step communication so the master receives slave production/injection data before writing summary output, fixing observed zero/stale FOPR in the master's summary
• Master waits for slaves after its first converged substep within each sync step, ensuring evalSummaryState() and all subsequent master substeps have up-to-date slave rates
• Slave sends data on last substep of the sync step

Background

The master process writes summary output (FOPR, GOPR, etc.) at every internal substep, but slave production data was previously only received at beginTimeStep(), reflecting the previous sync step's rates. For the very first sync step, no prior data existed at all, resulting in FOPR=0 for the entire first report step.

Approach

The master sets a needsSlaveDataReceive flag at the start of each sync step. On the first converged substep's timeStepSucceeded(), the master blocks on MPI_Recv until all slaves have completed their sync step and sent production data. Once received, the data is available for evalSummaryState() (called next in endTimeStep()) and all subsequent master substeps.

On the slave side, maybeUpdateLastSubstepOfSyncTimestep_() predicts before each substep whether it will complete the sync step. If so, timeStepSucceeded() sends the production data. If the prediction is wrong (convergence failure), timeStepSucceeded() is never called, so no MPI mismatch occurs. On retry with a smaller dt, the flag is recomputed correctly.

Performance impact

With this change, the master and slave no longer advance fully in parallel within a sync step. Previously the total sync step time was approximately max(T_master, T_slave). Now it is approximately T_slave + T_master_remaining, where T_master_remaining is the time for the master's remaining substeps after the first.

For dummy master grids single grid block, no wells, T_master_remaining is negligible and the overhead is minimal. For cases where the master is a real reservoir with its own wells, the overhead could be more noticeable.

Alternative: Deferred summary writing (future improvement)

A more efficient approach would let master and slave advance in parallel (as before), then have the master retroactively update its summary output with the slave's actual rates at the end of the sync step. This means the master could buffer summary data during substeps and rewrite it with the final slave rates. This would restore max(T_master, T_slave) parallelism but requires more complex changes to the summary output infrastructure. It could be implemented as a follow-up if the performance overhead of the current approach proves significant.

[hakonhagland]

jenkins build this please

[totto82]

Thanks. It looks good. The standard approach is to have a dummy reservoir for the master, so then the performance hit will be low.