openfoam-adapter
openfoam-adapter copied to clipboard
Support an general data exchange (read/write) for field datas
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?
- 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.
Possible example with externalWallHeatFluxTemperature insteady of fixedGradient.
interfaces
{
InterfaceHeater1
{
mesh Fluid-Mesh;
patches (InterfaceHeater1);
locations faceCenters;
readData
(
("MyShityNameforTemp", "T", "value")
);
writeData
(
("MyShityNameforFlux", "T", "q")
);
};
};
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
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.