Question/Idea: Supporting Monolithic Solvers and Multi-Region Interface Constraints

[rpasolari]

Hello,

I would like to start by thanking the developers for this project. blastAMR is a great tool, and it has specifically solved many of the issues I faced with 2D and axisymmetric adaptive refinement in OpenFOAM.

I am reaching out to discuss a specific use case: Implicit (Monolithic) Multi-Region Coupling. In recent OpenFOAM versions, multi-domain problems can be solved monolithically, solving both regions in a single matrix simultaneously (e.g., for CHT). This approach is numerically superior but imposes a strict topological constraint: cells on both sides of a mapped interface must reside on the same processor.

When using blastAMR in this context, I have encountered a significant hurdle:

1. If one region refines significantly, the load balancer moves those refined cells to a different processor.

2. If the neighboring region does not refine or update its distribution at the exact same time, the interface "snaps."

3. Because the monolithic solver assembles a global matrix, this mismatch leads to immediate memory errors (Segmentation Faults) during matrix coefficient transfer.

Is there a planned feature or a recommended way to enforce a "Cross-Region Constraint" in blastAMR? Specifically, I am looking for a way to ensure that even when a region refines to Level 2 or 3, the entire lineage (parent and children) at the interface remains anchored to the processor owning the neighbor region.

Do you think a shared decomposition constraint could be implemented to keep these independent regions synchronized during the mesh.update() phase?

[FoamScience]

Hi; I have been thinking of having some decomposition constraints for a while now; so it's on the backlog. I'll have a look later this week if I can start something out; can we have a specific test case for this? Some specific solver/case setup? preferably from the tutorials but I'm also open to any third-party case.

[rpasolari]

Hi,

I took some time to adapt a solver in OpenFOAM-v2412 so you can work on it directly. I’ve confirmed that the v2212 blastAMR library works in v2412 without issues.

In the attached folder, you’ll find potentialMultiRegionFoam. It’s a simple solver for the electric potential (Poisson equation) in two domains using a coupled boundary condition. I’ve included the B.C. and constants; a simple ./Allwmake in the root folder will compile everything.

The solver handles two coupling types:

Explicit: Typical coupling (like chtMultiRegionFoam) where domains communicate through the B.C. but matrices are solved separately.

Implicit: Activated via the useImplicit keyword in 0/ePotential. Here, a global matrix is built and solved monolithically.

As I mentioned, the monolithic solution has two strict limitations:

Processor Constraints: Cells sharing an interface must be on the same processor. I tried a constraint to keep interface cells on their original processors, but it created "islands" where parts of the same region became disconnected on the same processor. I can send you this constraint code if it helps.

Conformality: The interface mesh must be conformal.

Regarding conformality, I tried setting one region as the "master" and transferring a refineField (based on the calculated error) to the "coupled" region via a B.C. This way, the second region knows exactly where its adjacent region refined. While this works for simple hex meshes, it fails for tet meshes where the split logic isn't as straightforward. It also fails when the master region refines cells due to buffer layers rather than the error field itself. In these cases, even if the error is zero, the master cell refines to maintain the buffer transition, but this information isn't transferred to the slave region. This breaks the conformality at the interface immediately.

I’ve provided two examples, one explicit and one implicit, with both serial and parallel Allrun scripts.

I would really like to see this move forward as implicit coupling makes these simulations significantly faster by avoiding the wait for domains to reach convergence at every coupling step. If there is anything I can do to help with the development or testing, feel free to reach out.

Let me know if you have any questions regarding the solver, the examples, or the technical issues I’ve raised.

potentialMultiRegionFoam.tar.gz

[FoamScience]

Thanks a lot for this effort! I skimmed through the files and scheduled this up for the weekend if I get enough free time.
I'd also ask you to put these bits of code in a Git repo so you get credit for it. This will make it easier to track this issue.

[rpasolari]

I have moved the code and test cases to a dedicated repository as requested: https://github.com/rpasolari/potentialMultiRegionFoam

Please let me know if you need any further clarification or help with the setup!

[FoamScience]

Took a look at this, and it looks like I need deeper design decisions. Will pick this in a few more weeks If I get more free time.

So, currently this is on the backlog, but no immediate plans are quickly realizable