Clarify field support for solvers in README by MakisH · Pull Request #392 · precice/openfoam-adapter

MakisH · 2026-01-29T15:41:03Z

Replaces the list of fields that the adapter can read/write, with more detailed tables (one per module). The tables clarify which field can be written/read on which mesh locations, and whether mesh connectivity is provided.

It also mentions fields added with #380.

The tables need to be cross-checked. I am, in particular, unsure about the support of mesh connectivity.

The CI is currently failing for unrelated reasons:

Building: See issue with OpenFOAM packages (solved)
Formatting: See action issue

Some fields are only supported by some types of solvers. For example, solid OpenFOAM solvers cannot write force, because that is computed assuming a flow solver. There are probably more like this, we need to check and document.

MakisH · 2026-01-30T13:06:59Z

Overall, it would be easier to add a table with fields as rows and as columns:

Points (column group)
- Read
- Write
Faces (column group)
- Read
- Write
Cells (column group)
- Read
- Write

and then have X or similar to mark what is supported, or Fluid/Solid if only one of them is possible.

We should then also add the missing documentation from #380.

vidulejs · 2026-02-17T16:01:54Z

In Adapter.C, line 178, it says FSI with meshConnectivity is unsupported and will throw an error.

    // If the FSI module is enabled, create it, read the
    // FSI-specific options and configure it.
    if (FSIenabled_)
    {
        // Check for unsupported FSI with meshConnectivity
        for (uint i = 0; i < interfacesConfig_.size(); i++)
        {
            if (interfacesConfig_.at(i).meshConnectivity == true)
            {
                adapterInfo(
                    "You have requested mesh connectivity (most probably for nearest-projection mapping) "
                    "and you have enabled the FSI module. "
                    "Mapping with connectivity information is not implemented for FSI, only for CHT-related fields. "
                    "error");
                return;
            }
        }

davidscn

I didnt check all the Cs in the FF module

davidscn · 2026-02-17T15:13:26Z

docs/config.md

 #### FF

-The fluid-fluid coupling module supports reading and writing `Pressure`, `Velocity`, `PressureGradient`, `VelocityGradient`, `FlowTemperature`, `FlowTemperatureGradient`, `Alpha`, `AlphaGradient` and the face flux `Phi`.
+The fluid-fluid coupling module supports reading and writing `Pressure`, `Velocity`, `PressureGradient` (surface-normal gradient), `PressureGradientFull` (full pressure gradient), `VelocityGradient`, `FlowTemperature`, `FlowTemperatureGradient`, `Alpha`, `AlphaGradient`, `Phi` (face flux), `DragForce`, `ExplicitMomentum`, `ImplicitMomentum`.


Maybe it would make sense to put the last three fields into the context of CFD-DEM, I am not sure how convenient such fields would be beyond that. Having them under fluid-fluid is also somewhat questionable.

docs/README.md

davidscn · 2026-02-17T15:46:50Z

docs/README.md

+| Heat flux | N*, F | N, F* | `Heat-Flux` |
+| Heat transfer coefficient | N*, F | N, F* | `Heat-Transfer-Coefficient` |
+| Sink temperature | N*, F | N, F* | `Sink-Temperature` |
+| Temperature | N*, F, C | N, F*, C | `Temperature` |


I know where the confusion here stems from: the connectivity element in the OpenFOAM adapter was initially added with nearest-projection mappings in mind, for the above data fields, the following holds

all these fields are mapped consistent

for a consistent mapping, the write side needs to provide connectivity

the fields in OpenFOAM itself live on the face centers, so one would read them on the face centers.

the adapter generally only allows the definition of connectivity between face nodes

That said, for reading data, connectivity is not relevant, one would configure the face centers and leave the connectivity definition to the writing side. Internally, we only support reading on F (and C) for reading data and not N. Putting the F* on the read side is pointless (the connectivity is never used), but also doesnt work in terms of the adapter.

So correct would be

| Heat flux | N*, F | F | `Heat-Flux` |

See also: https://github.com/precice/tutorials/tree/develop/flow-over-heated-plate-nearest-projection

Only saw your review now. I was also confused about mesh connectivity on F* on read side.

In Adapter.C, line 100, we allow mesh connectivity for faceNodes only.

if (interfaceConfig.meshConnectivity && (interfaceConfig.locationsType == "faceCenters" || interfaceConfig.locationsType == "volumeCenters" || interfaceConfig.locationsType == "volumeCentres")) { DEBUG(adapterInfo("Mesh connectivity is not supported for faceCenters or volumeCenters. \n" "Please configure the desired interface with the locationsType faceNodes. \n" "Have a look in the adapter documentation for detailed information.", "error")); return; }

Also in Interface.C we only do
precice_.setMeshTriangles(meshName_, triVertIDs); if location is faceNodes.

But then F* on write side is also impossible to configure.

davidscn · 2026-02-17T15:53:25Z

docs/README.md

+
+| Field | Write | Read | Config prefix |
+| --- | --- | --- | --- |
+| Displacement: absolute | N*, F* | N*, F* | `Displacement` |


davidscn · 2026-02-17T16:00:09Z

docs/README.md

+| Force | F* (flow) | F* | `Force` |
+| Stress | F* (flow) | F* | `Stress` |


What I want to emphasize is that writing forces for an OpenFOAM structure solver (e.g., solidDisplacementFoam or solids4Foam) is not supported.

davidscn · 2026-02-17T16:01:28Z

docs/README.md

+Displacement reading and writing is supported both for flow (compressible or incompressible) and structure solvers.
+Force and stress writing in only supported for flow solvers, reading for both.
+
+### Module: Fluid-fluid coupling


I think all F* in the following table need to be a F

davidscn · 2026-02-17T16:06:46Z

docs/README.md

+| Momentum: explicit | F*, C | F*, C | `ExplicitMomentum` |
+| Momentum: implicit | F*, C | F*, C | `ImplicitMomentum` |
+| Phase flux | F* | F* | `Phi` |
+| Phase fraction | F*, C | F*, C | `Alpha` |


davidscn · 2026-02-18T08:42:11Z

In Adapter.C, line 178, it says FSI with meshConnectivity is unsupported and will throw an error.

I think this has similar historical reasons: we started with conventional FSI, i.e., reading displacement and writing forces. In such cases, the solid solver needs to provide the connectivity, so there was no real point in conisdering this scenario. Since we now also have solid solvers in OpenFOAM, it could make sense to allow the displacement with connectivity case.

Co-authored-by: David Schneider <david.schneider@ipvs.uni-stuttgart.de>

vidulejs · 2026-02-19T14:08:56Z

I've created a new PR to fix the outdated mesh connectivity statements in all of the modules.

#393

MakisH · 2026-02-20T09:30:57Z

Self-reminder: Check and update the documentation with a clarification:

Mesh connectivity only makes sense for the writing side
If a field supports connectivity, this is only for the nodes
Temperature is available on the face centers, but if connectivity is requested (i.e., on the nodes only), we interpolate from the faces to the nodes

This is already there, but maybe we can make it easier/clearer earlier.

davidscn · 2026-02-20T09:33:31Z

Mesh connectivity only makes sense for the writing side

for consistent data, for coservative data, it makes only sense for the reading side

vidulejs · 2026-02-27T15:12:42Z

Let's wrap this PR up.

Mesh connectivity (*) is only relevant for the Write side currently. Even though we had allowed mesh connectivity on Read, there is actually no implementation on the adapter side (comment). We do not currently distinguish between read and write in isLocationTypeSupported either.
Mesh connectivity (*) is impossible for anything other than locations: faceNodes. There is a global block in Adapter.C, which will throw an error if it's anything other than Face Nodes. In Interface.C, we provide preCICE with the mesh connectivity data only in this case.
FSI now allows mesh connectivity since PR 393.

Clarify field support for solvers in README

2445838

Some fields are only supported by some types of solvers. For example, solid OpenFOAM solvers cannot write force, because that is computed assuming a flow solver. There are probably more like this, we need to check and document.

MakisH self-assigned this Jan 29, 2026

MakisH added 3 commits February 13, 2026 15:50

Add tables of supported fields

9d6584b

Add changelog entry

70ca04b

Document existence of CFD-DEM fields

6d19c43

MakisH marked this pull request as ready for review February 13, 2026 14:59

Move disclaimer up to fix rendering of footnotes

a0fbb27

MakisH requested a review from davidscn February 16, 2026 15:19

davidscn requested changes Feb 17, 2026

View reviewed changes

Update docs/README.md

9386747

Co-authored-by: David Schneider <david.schneider@ipvs.uni-stuttgart.de>

vidulejs mentioned this pull request Feb 19, 2026

Update meshConnectivity claims #393

Merged

2 tasks

	\| Displacement: absolute \| N, F \| N, F \| `Displacement` \|
	\| Displacement: absolute \| N, [F](https://github.com/precice/openfoam-adapter/issues/153) \| N, F \| `Displacement` \|

		\| Force \| F* (flow) \| F* \| `Force` \|
		\| Stress \| F* (flow) \| F* \| `Stress` \|

	\| Phase fraction \| F, C \| F, C \| `Alpha` \|
	\| Volume fraction \| F, C \| F, C \| `Alpha` \|

Uh oh!

Conversation

MakisH commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MakisH commented Jan 30, 2026

Uh oh!

vidulejs commented Feb 17, 2026

Uh oh!

davidscn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vidulejs Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidscn commented Feb 18, 2026

Uh oh!

vidulejs commented Feb 19, 2026

Uh oh!

MakisH commented Feb 20, 2026

Uh oh!

davidscn commented Feb 20, 2026

Uh oh!

vidulejs commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MakisH commented Jan 29, 2026 •

edited

Loading

vidulejs Feb 17, 2026 •

edited

Loading