Need help with icoReactingMul... solver

TEFEdotCC · August 28, 2020, 10:22am

New users can only take two links? wtf.

Issue to support incompressible multiphase: [#127]
Issue for the adapter changes: [#138]

preCICE version: 2.1.0
openfoam-adapter git commit: [c49b862]
OpenFOAM version: v2006

I try to setup an learning example to run an OpenFOAM heater case with three phases (air, water, vapor) with solid heating regions.

Solver for Fluid: icoReactingMultiphaseInterFoam
Solver for Heater[i]: laplacianFoam

I had setup an example case an pulished it under: cloud.thomas-enzinger.de
(Currently I’m not 100% sure if solid case is setup correctly. Fluid case works and create that problem bevor any solid case is running in preCICE)

Problem:
If I want to execute the fluid solver, the executions runs in a problem by the heat-flux initialisation.

---[preciceAdapter] [DEBUG] Creating interfaces...
---[preciceAdapter] [DEBUG] Number of face centres: 0
---[preciceAdapter] [DEBUG] Interface created on mesh Fluid-Mesh
---[preciceAdapter] [DEBUG] Adding coupling data writers...
---[preciceAdapter] [DEBUG] Added writer: Temperature.
---[preciceAdapter] [DEBUG] Adding coupling data readers...
--> FOAM Warning : 
    From void adapterInfo(std::string, std::string)
    in file Utilities.C at line 50
    e[31mError (deferred - will exit later) in the preCICE adapter: e[0m

    lookup of turbulenceProperties from objectRegistry region0 successful
    but it is not a compressibleTurbulenceModel, it is a kEpsilon

The error is produced by OpenFOAM in the adapter file KappaEffective.c, Line 17

mesh.lookupObject<compressible::turbulenceModel>(turbulenceModel::propertiesName)

Question
May be I do an wrong configuration in the prece-config.xml. Is someone here to take an look and do an check to all is configured correctly?

Discussion / Solution

Currently I’m not so deep in preCICE and OpenFOAM code base, but my basic thinking about the job of preCICE is to communicate with different solvers and transfer data between them.
The openfoam-adapter do also calculation steps, is interessted to turbulence models, … and so on. But why? I think it is not the job of preCICE and there adapters. Maybe to implement missing thinks, ok. But for generall purpose? I would say no as long as the solver also has possibilites to setup and calculate thinks.

For my problem OpenFOAM can calculate the wallHeatFlux out of the box.
[config file], [header] and [source]
So, the code should do the job on all offical shiped solvers with heat transfer support.
If I want to use this OpenFOAM feature, I need an general data field reader / writer

The implementation of an general data reader could be easy like the [CHT/Temperature] code. In preciceDict should also be possible to set up an mapping between openfoam fields and precice-data.

Expand precice-config.xml to introduce an type entry to data (–> clean code)

<data:scalar name="myShitNameForNothing" type="none|Temperature|Heat Flux|..." />

New module general in preCICEDict? Like

modules (GENERAL);

GENERAL
{
    mapping
    (
        ("data:name", "field name:OpenFOAM")
    );
}

Could be this way possible?

By the way

The mpi initialisation in the ubuntu container (podman) looks strange. It’s all correct?

---[preciceAdapter] [DEBUG] Creating the preCICE solver interface...
---[preciceAdapter] [DEBUG]   Number of processes: 10
---[preciceAdapter] [DEBUG]   MPI rank: 0
---[precice] e[0m 1
---[precice] e[0m 1
---[precice] e[0m 1
---[precice] e[0m 1
---[precice] e[0m 0
---[precice] e[0m This is preCICE version 2.1.0
---[precice] e[0m Revision info: no-info [Git failed/Not a repository]
---[precice] e[0m Configuring preCICE with configu(https://github.com/precice/openfoam-adapter/commit/c49b862aab4845ae79b8b7257a20e15ba5a0019c)ration "precice-config.xml"
---[precice] e[0m I am participant "Fluid"
---[precice] e[0m Connecting Master to 9 Slaves

TEFEdotCC · August 28, 2020, 9:05pm

Ok, I think I can solve the problem for the icoReactingMulti… solver by usage of the externalWallHeatFluxTemperature condition in constant flux operation mode insteady of fixedGradient at the wall of T field.

The boundary conditions also respect occur of radiation.
Should the heat flux treatment changed from fixedGradient to externalWallHeatFluxTemperature?

uekerman · September 1, 2020, 4:24pm

That’s the default value of Discourse (to safeguard against spam I guess) and indeed too low. I increased the value to 10.

Your config looks good:

Your discussion topic sounds interesting. Running out of time today. I will comment soon.

uekerman · September 1, 2020, 4:28pm

Small thing: You should also pack your temperature values into the acceleration as multi is by definition a parallel coupling scheme. Thus, all output is needed. Read more here.

        <acceleration:IQN-ILS>
            <data mesh="Fluid-Mesh" name="Heat-Flux1" />
            <data mesh="Fluid-Mesh" name="Heat-Flux2" />
            <data mesh="Fluid-Mesh" name="Heat-Flux3" />
            <data mesh="Fluid-Mesh" name="Heat-Flux4" />
            <data mesh="Fluid-Mesh" name="Temperature1" />
            <data mesh="Fluid-Mesh" name="Temperature2" />
            <data mesh="Fluid-Mesh" name="Temperature3" />
            <data mesh="Fluid-Mesh" name="Temperature4" />
            <preconditioner type="residual-sum"/>
            <initial-relaxation value="0.01" />
            <max-used-iterations value="100" />
            <time-windows-reused value="10" />
            <filter type="QR2" limit="1e-6" />
        </acceleration:IQN-ILS>

uekerman · September 3, 2020, 3:45pm

Concerning your discussion topic.

preCICE (the library itself) is responsible for the communication (including the logic how sends to whom when) and the “coupling numerics” (interpolation and acceleration). preCICE has no notion of physics, it does not know whether a data field is a temperature or a velocity.

The adapters, on the other hand, are responsible for what we typically refer to as “coupling physics”. They know about the physics. An adapter knows that e.g. it gets nodal temperature values from preCICE and how to apply them as boundary condition in the solver. Also, that it needs to return nodal heat fluxes to preCICE and how to extract them from the internal fields.

There are OpenFOAM solvers that do not yet know how to compute e.g. a heat flux, take laplacianFoam as an extreme example. The heat flux is only required for coupling. As a standalone solver laplacianFoam does not need to compute heat fluxes.

If your specific OpenFOAM solver, however, already knows how to compute heat fluxes (and maybe even computes better fluxes in some sense) it makes very much sense that we use those in the adapter. As far as I know the current OpenFOAM adapter does not yet support this (@Makis please correct me if I am wrong).
Interesting to know: for temperature values, we can already tell preCICE that they have a different name in your specific solver, read more in the wiki. I could imagine a similar thing for writing heat fluxes.
For that you would need to alter the preCICEDict (aka the adapter configuration). I don’t think that we need a new module. And you don’t need to modify the preCICE config.

Associated issue: https://github.com/precice/openfoam-adapter/issues/138

TEFEdotCC · September 7, 2020, 5:09pm

Hello @uekerman,
thank you very much for the detailed answer

The tip with the acceleration data is nice to know.
I think I had to delve more into the possibilities to get the heat fluxes by OpenFOAM. Hopefully in the next weeks, I do this in my free time.

TEFEdotCC · September 7, 2020, 8:54pm

OpenFOAM-Adapter set temperature → get heat flux
With the postProcessing-Function wallHeatFlux there is a way to calculate the heat flux for specifics wall. I do not check the code entirely, but it should be a good starting point for all solvers.
The function could be enabled in controllDict and executed every time step. So the heat flux should be available in every time step.

OpenFOAM-Adapter set heat flux → get temperature
In case of solid (laplacianFoam) the actually code and usage of T:fixedGradient looks good,
In case of fluid I think we should move the code from T:fixedGradient to T:externalWallHeatFlux with mode=" flux". This moves all calculation work to OpenFOAM and the adapter do not know anything about the case (e.g. compressible or incompressible).

I also not sure if the adapter should support other wall boundary conditions for special cases (htc + ambient temperature, wallHeatTransfer).

TEFEdotCC · September 7, 2020, 9:09pm

T:externalWallHeatFlux with KappaMethod=“solidThermo” should be also working for the laplacianSolver. Test follows … (other are welcome to do work)

Makis · September 9, 2020, 11:40am

@TEFEdotCC these ideas are very good. A few comments from my side.

The openfoam-adapter do also calculation steps, is interessted to turbulence models, … and so on. But why? I think it is not the job of preCICE and there adapters.

Indeed, we shouldn’t need to know anything about turbulent models etc. But OpenFOAM unfortunately does not have a general mechanism to access the kappaEff (needed to compute the heat fluxes). The underlying data structures are completely different for each of the three types of solvers we consider (compressible, incompressible, basic), thus the extensive code around this and the dependency on turbulence.

Note: This has changed (for a good reason) in OpenFOAM 8 and we may see a similar change in the ESI variant in the future. But all versions until today had this awkward dependency.

That would probably simplify the role of the adapter a lot and would be an interesting approach to extend also to problems (FSI etc). Every time we need to compute something, we could offload it to an external function object. If function objects exists for everything and across all the supported OpenFOAM versions, everything should be fine. If not, we could still implement them and get them merged upstream. This would then also solve some version compatibility issues through delegation.

This idea definitely deserves an issue.

My current short-term suggestion would be to just modify the adapter for your own needs. Or at least this is how other users currently approach this. But indeed, we can do better here.

I am afraid this is not so easy, but it could be doable as an additional option, with the responsibility for correct input falling onto the user. But I will continue the discussion about this in the respective issue.

TEFEdotCC · October 28, 2020, 3:05pm

Indeed, we shouldn’t need to know anything about turbulent models etc. But OpenFOAM unfortunately does not have a general mechanism to access the kappaEff

Only for notice please. With the class temperatureCoupledBase for an PatchScalarField OpenFOAM provides an general way to access the kappaEff.

Topic		Replies	Views
Issues on preCICE for CHT problem: icoReactingMultiphaseInterFoam and laplacianFoam Official adapters and tutorials openfoam	38	2331	April 6, 2022
3-phase multiphase compressible FSI coupling in preCICE + openFOAM Official adapters and tutorials openfoam	2	62	March 12, 2024
Fluid-solid CHT Multiphase coupling Community projects openfoam , multiphase , cht	2	80	November 29, 2023
OpenFOAM adapter configuration for two-phase CHT simulation Official adapters and tutorials openfoam , inactive , cht	5	591	September 29, 2020
OpenFOAM adapter: Issue with several modules Official adapters and tutorials openfoam , adapters	2	474	September 13, 2021

Need help with icoReactingMul... solver

Related Topics