Finite area: decomposePar generates incorrect processorPatch fields

Summary

Consider a two-face parallel finite-area simulation. Suppose the internal velocity field (areaVectorField) is (0 0 1) and (0 0 2) in serial mode. When decomposePar is executed, it is expected that the processorPatch values reflect the internal field values from the opposite side. However, it is observed that decomposePar generates incorrect processorPatch values. In contrast, this issue does not occur in finite-volume simulations, and for internally generated finite-area fields (e.g. faceNormals).

Steps to reproduce

• Use GL3271-test.zip.
• Execute Allrun-parallel.
• Compare 0.orig/finite-area/Us with processor{0,1}/0/finite-area/Us: procBoundary0to1 and procBoundary1to0 have unexpected values.

Environment information

• api = 2406
• HEAD = 791796c6
• version = v2406
• compiler = Clang (system) version 15.0.7
• mpi = SYSTEMOPENMPI = mpirun (Open MPI) 1.10.7.0.5e373bf1fd
• OS = Description: openSUSE Leap 15.5
• opts = linux64ClangDPInt32Opt

Possible fixes

@andy suggests that the issue stems from faFieldDecomposer.H where the algorithm is suitable to foam-extend's handling of processor fields, and is not to our handling of them.

FYI @Mattijs .

added bug label

added finiteArea label

changed the description

assigned to @Mattijs

mentioned in commit 86fda799

closed

mentioned in commit 45e7c4a0