detecting when the first perforation values cannot be made consistent

[GitPaean]

broadcastFirstPerforationValue() does nothing when no process reported holding the first open connection of the well, and every process then keeps its own value. That is intended when the well has no open connections at all, but if the well is perforated it means the processes silently end up with different values for the pvt region, the reference density and the pressure, temperature and salt concentration of the first connection.

communicateFirstPerforation() now also gathers whether a process has any perforation, so the two cases can be told apart, and throws for the second.

[Copilot]

Pull request overview

This PR tightens parallel well synchronization by detecting the invalid case where a well has (open) perforations but no rank reports owning the first open connection, which would otherwise allow ranks to silently diverge in “first perforation” derived properties (e.g., PVT region, reference density, first-connection P/T/salt).

Changes:

• Extend ParallelWellInfo::communicateFirstPerforation() to allgather an additional per-rank flag and throw std::logic_error when perforations exist but no rank claims the first open connection.
• Add a unit test asserting that this inconsistent “perforated well without first perforation owner” case is detected and rejected.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tests/test_parallelwellinfo.cpp	Adds a new Boost test case covering the newly-detected inconsistent first-perforation ownership scenario.
opm/simulators/wells/ParallelWellInfo.cpp	Updates first-perforation coordination to distinguish “no open connections anywhere” from “perforated but no first owner” and throw in the latter case.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[GitPaean]

jenkins build this please

[GitPaean]

I do not think we have problem so far with this corner situation, but it is more for safety on the code side found when working with #7367