CHT flow around a flap using rhocentralfoam

Build  : _66908158ae-20221220 OPENFOAM=2212 version=v2212
Arch   : "LSB;label=64;scalar=64"
Exec   : rhoCentralFoam
Date   : Aug 11 2023
Time   : 20:03:56
Host   : detonation
PID    : 8436
I/O    : uncollated
Case   : /home/detonation/Anup_Sanjeev_collaboration_023/detonation/FSI_cht_case/FSI_CHT_calculix/perpendicular_flap_rhoCentral/cht_only_rhocentralfoam/fluid-openfoam
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading thermophysical properties

Selecting thermodynamics package 
    type            hePsiThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState perfectGas;
    specie          specie;
    energy          sensibleInternalEnergy;

Reading field U

Creating turbulence model

Selecting turbulence model type laminar
Selecting laminar stress model Stokes
fluxScheme: Kurganov

Starting time loop

---[preciceAdapter] Loaded the OpenFOAM-preCICE adapter - v1.2.3.
---[preciceAdapter] Reading preciceDict...
---[precice]  This is preCICE version 2.3.0
---[precice]  Revision info: v2.3.0
---[precice]  Configuration: Release (Debug and Trace log unavailable)
---[precice]  Configuring preCICE with configuration "../precice-config.xml"
---[precice]  I am participant "Fluid"
---[precice]  Setting up master communication to coupling partner/s
---[precice]  Masters are connected
---[precice]  Setting up preliminary slaves communication to coupling partner/s
---[precice]  Prepare partition for mesh Fluid-Mesh
---[precice]  Gather mesh Fluid-Mesh
---[precice]  Send global mesh Fluid-Mesh
---[precice]  Receive global mesh Solid-Mesh
---[precice]  Receive global mesh Solid-Mesh-nodes
---[precice]  Setting up slaves communication to coupling partner/s
---[precice]  Slaves are connected
---[precice]  iteration: 1 of 10, time-window: 1, time: 0 of 5, time-window-size: 0.01, max-timestep-length: 0.01, ongoing: yes, time-window-complete: no, write-iteration-checkpoint
---[precice]  initializeData is skipped since no data has to be initialized.
---[preciceAdapter] preCICE was configured and initialized
#0  Foam::error::printStack(Foam::Ostream&) in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/lib/
#1  Foam::sigFpe::sigHandler(int) in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/lib/
#2  ? in /lib/x86_64-linux-gnu/
#3  preciceAdapter::CHT::HeatFlux::read(double*, unsigned int) in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#4  preciceAdapter::Interface::readCouplingData() in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#5  preciceAdapter::Adapter::readCouplingData() in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#6  preciceAdapter::Adapter::configure() in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#7  Foam::functionObjects::preciceAdapterFunctionObject::read(Foam::dictionary const&) in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#8  Foam::functionObjects::preciceAdapterFunctionObject::preciceAdapterFunctionObject(Foam::word const&, Foam::Time const&, Foam::dictionary const&) in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#9  Foam::functionObject::adddictionaryConstructorToTable<Foam::functionObjects::preciceAdapterFunctionObject>::New(Foam::word const&, Foam::Time const&, Foam::dictionary const&) in ~/OpenFOAM/detonation-v2212/platforms/linux64GccDPInt64Opt/lib/
#10  Foam::functionObject::New(Foam::word const&, Foam::Time const&, Foam::dictionary const&) in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/lib/
#11  Foam::functionObjectList::read() in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/lib/
#12  Foam::Time::run() const in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/lib/
#13  ? in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/bin/rhoCentralFoam
#14  __libc_start_main in /lib/x86_64-linux-gnu/
#15  ? in ~/OpenFOAM/OpenFOAM-v2212/platforms/linux64GccDPInt64Opt/bin/rhoCentralFoam
/home/detonation/OpenFOAM/tutorials/tools/ line 15:  8436 Floating point exception(core dumped) ${solver}

I was able to run same case with buoyantpimplefoam. And I can run same case using rhocentralfoam only (excluding coupling part)

I can imagine that at the moment the adapter is not compatible with rhoPimpleFoam. It looks like the solver is complaining about the way we are reading heat flux:

Could you please build the adapter with debug messages enabled (see the Allwmake script and add -DADAPTER_DEBUG_MODE to the ADAPTER_PREP_FLAGS) and run again? The output will be interesting.

Thanks @Makis I did compile including the adapter as you suggested. Yeah, it’s really helpful to know what’s going on in the setting. However, I still have some doubts regarding the problem regarding this error:

preciceAdapter::CHT::HeatFlux::read(double*, unsigned int)

in documentation, to read data for heat-flux we can only use faceCenters, and meshconnectivity is false. For this particular case i cannot use face-Nodes as it’s available for heat-flux to read data. Therefore, I tried using faceCenter location with mesh connectivity true. Adapter suggested to use that connectivity is only supported for 3D cases. but my case is 2D

So if i change dimension to 3 including z-dead=0 in RBF mapping does it computes the physically correct simulation. And also, when i do this it again shows this error

preciceAdapter::CHT::HeatFlux::read(double*, unsigned int)

can you provide a hint on what I should be looking at.
Thank you!

Can you please upload the new output? It should contain more information.

I do not understand this part. Can you please upload your system/preciceDict and your precice-config.xml?

precice-config.xml (2.4 KB)
preciceDict.nam (756 Bytes)

preciceDict file just renamed to .nam just to upload.

This is how your preCICE config looks like when visualized:

Besides the unused Solid-Mesh-nodes in the Fluid solver, the config looks fine. This also seems to be a CHT case, so I am wondering regarding the title of this thread (feel free to edit).

In the preciceDict, it looks like you have split the interface into two different ones, using the same mesh, and different locations:

    mesh              Fluid-Mesh;
    patches           (flap);
    locations        faceCenters;//faceNodes; 
    connectivity     false; //true; 

    mesh              Fluid-Mesh;
    patches           (flap);
    locations        faceNodes; //faceCenters;
    connectivity      true; //false;


I don’t know if using the same coupling mesh (Fluid-Mesh) in two different interfaces causes this issue, but it is definitely an issue. The adapter calls setMeshVertices() twice for the Fluid-Mesh, which should not even be allowed in preCICE (I need to check). The values you read should then be wrong.

Possible solutions:

  1. If your solid solver supports reading and writing temperatures/heat flux on the same locations (e.g., OpenFOAM), then remove the Interface2 and add Temperature to the writeData of Interface1. Example:
  2. If your solid solver has temperatures and heat fluxes on different meshes (e.g., CalculiX), then you still need OpenFOAM to just read/write on one interface with the same locations. Only CalculiX has to work with the two Solid meshes. Example:

Note that you don’t need the mesh connectivity, since you are using an RBF mapping. Connectivity is mainly required when you need a nearest-projection mapping - see Mapping configuration | preCICE - The Coupling Library

There seems to be some misunderstanding here. Where in the documentation did you read this?

It is definitely a cht case(typing error chat in title) for geometry similar to perpendicular flap tutorial. And for this case, I am using rhoCentralFoam rather then buoyantPimpleFoam or other heatTransfer solver available in openfoam. As per OpenFoam (OpenFOAM: User Guide: rhoCentralFoam) solver rhoCentralFoam is capable of heat transfer. And as per my necessity, i.e., observation of heatransfer between fluid and solid for cases having shockwaves. I cannot use buoyantPimpleFoam for the computation of fluid cases. With buoyantPimpleFoam for this case cht between solid and fluid was successfully observed.

  1. At first I had set the case as per the solution you referred to. i.e.,
    mesh              Fluid-Mesh;
    patches           (flap);

But error related to this term preciceAdapter::CHT::HeatFlux::read(double* buffer, const unsigned int dim) keeps presisting.
Then only after that, I tried the way with two interfaces.

  1. at first I was using nearest-point projection therefore using mesh connectivity. And for mesh connectivity, it has the following notes:
 // For cases with mesh connectivity, we support:
 // - face nodes, only for writing
 // - face centers, only for reading
 // However, since we do not distinguish between reading and writing in the code, we
 // always return true and offload the handling to the user.
  1. Yes, I am using calculix as a solid solver which reads temperature at the nodes and heat-flux at surface as,
        - nodes-mesh: Solid-Mesh-nodes
          patch: interface
          read-data: [Temperature]
        - faces-mesh: Solid-Mesh
          patch: surface
          write-data: [Heat-Flux]
precice-config-file: ../precice-config.xml
  1. Further to these, I set up a case with OpenFOAM solver for both fluid (buoyantPimpleFoam) and solid (laplacianFoam) it works well. However, for the same fluid case with changes and additions of boundary conditions, I run it with rhoCentralFoam. Error preciceAdapter::CHT::HeatFlux::read(double* buffer, const unsigned int dim) persist. Just for your information, I tried adding laplacian term in the energy equation in rhocentral foam solver i.e., -fvc:laplacian(kappaEff,T)

  2. So, my question is: To solve this issue shall I made changes to the adapter for rhoCentralFoam (I read in the thesis of Cheung it requires certain updates (its not mentioned in detail) for rhopimpleFoam). or just changes on the preciceDict and precice-config.xml file is enough.

My apologies for the confusion. If you still find it confusing regarding the issue please let me know.
@Makis Thanks!

I edited the title and your last answer to mark the code snippets. You can mark inline code using backticks, like this: `This should be displayed in code font in the same line` - This should be displayed in code font in the same line. You can mark several lines to be shown as a code block, with three backticks, like this:

int main(){
std::cout << “Hello!” << std::endl;

int main(){
  std::cout << "Hello!" << std::endl;

Where c++, you can also use xml, yaml, or just leave it empy. Please do use this feature, it makes error messages and code extremely easier to read.

Could you please try to find where in that function you get the error? You could try printing some information to the screen. You need to edit the code for that. And please upload the debug log then.

I would suggest to not look into nearest-projection and mesh connectivity yet. You could use it to optimize an already well-running case, but it is more complicated.

The thesis of Cheung is from 2016 and is describing how you could couple an OpenFOAM solver from scratch. A lot has changed since (see OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations | OpenFOAM® Journal). For most cases, changes in preciceDict and precice-config.xml are enough.

I would like to understand what exactly is failing in the heat flux reading. I assume it is related to the thermophysical model configured.