openfoam-adapter icon indicating copy to clipboard operation
openfoam-adapter copied to clipboard

Support an general data exchange (read/write) for field datas

Open TEFEdotCC opened this issue 4 years ago • 4 comments

Issue to support incompressible multiphase: #127 Extracted from my actually problem: precice.discourse.group

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

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. That could be also nice to transfer thinks from own coeded field data in openfoam. e.g passiv scalar field.

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")
    );
}

EDIT: Or do all the shit in preCICEDict

modules (GENERAL);

GENERAL
{
    mapping
    (
        ("data:name", "type: none|Temperature|Heat Flux|...", "field name:OpenFOAM")
    );
}

Could be this way possible?

TEFEdotCC avatar Aug 28 '20 10:08 TEFEdotCC

  • I recognise there are a lot of boundary conditions, there are not set the field data over value property. One more information for the mapping is needed.
  • the type of mapping data does no matters --> removed

("data:name", "field name:OpenFOAM", "property name of field")

(patches are set by the interface definition)

Looks not 100% accurate. Perhaps to move that into interface definition looks better for me.

TEFEdotCC avatar Aug 28 '20 21:08 TEFEdotCC

Possible example with externalWallHeatFluxTemperature insteady of fixedGradient.

interfaces
{
  InterfaceHeater1
  {
    mesh              Fluid-Mesh;
    patches           (InterfaceHeater1);
    locations         faceCenters;

    readData
    (
      ("MyShityNameforTemp", "T", "value")
    );

    writeData
    (
      ("MyShityNameforFlux", "T", "q")
    );
  };
};

TEFEdotCC avatar Aug 28 '20 21:08 TEFEdotCC

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/need-help-with-icoreactingmul-solver/307/5

precice-bot avatar Sep 03 '20 15:09 precice-bot

This is a nice idea! We could indeed add a generic coupling data reader/writer. I am not sure about all the details at the moment, but I think it is doable.

Note that this alone would not be able to replace the existing, physics-specific modules.

MakisH avatar Sep 09 '20 14:09 MakisH