Unexpectedly High Interface Temperature in OpenFOAM-Code_Aster Heat Transfer Coupling

[buttersflg]

Dear all

I am working on the Flow over heated plate steady-state tutorial described here:
Flow over heated plate steady state | preCICE - The Coupling Library

Versions Used

• preCICE: 3.0.0
• OpenFOAM: v2312
• OpenFOAM preCICE Adapter: 1.3.0
• Code_Aster: 14.6
• Code_Aster preCICE Adapter: GitHub Repository

Problem description

The expected temperature should be close to 310 K at the solid domain and 300 K at the fluid domain like this figure：

However, I am observing extremely high temperatures at the interface, reaching values around 1e7 K, which is far above the expected physical range:

More details

The only modification I made was to change the exchange directory in precice-config.xml to an absolute path based on the advice given in The code_aster adapter | preCICE - The Coupling Library

After obtaining incorrect results, I tried to modify some parameters to identify the cause of the problem. For example, I tried to modify the initial temperature of the boundaries in fluid-openfoam/0/Tand solid-codeaster/def.comm. I even modified the time step in precice-config.xml. But these modifications have no impact on the results.

Finally, I found that the parameters that affect the interface temperature is the coefficients related to heat conduction in solid-codeaster/def.comm:：

    # Materials
    MAT = [None] * 1

    COND = DEFI_CONSTANTE(VALE=100)
    RHO_CP = DEFI_CONSTANTE(VALE=100)

    
    MAT[0] = DEFI_MATERIAU(THER=_F(LAMBDA=100, RHO_CP=100),);

I noticed that the interface temperature strongly depends on LAMBDA:

• LAMBDA = 100 → Interface temperature = 1e7 K
  LAMBDA = 0.5 → Interface temperature = 5e4 K
  LAMBDA = 0.0031 → Interface temperature is closer to expected values.

In a normal physical scenario, a high LAMBDA should increase heat transfer, but it shouldn’t cause extreme interface temperatures.Could OpenFOAM’s enthalpy-based calculation be affecting the temperature exchange with Code_Aster?

Questions

1. Why does changing LAMBDA (thermal conductivity) have such a strong impact on the interface temperature?
2. Could this be related to how OpenFOAM computes temperature when using buoyantSimpleFoam?
3. Is there any additional debugging step I should take to diagnose the issue?

Any suggestions or insights would be greatly appreciated!

Best regards
Butters

[Ray_Scarr]

I am only somewhat familiar with OpenFOAM and not at all familiar with Code_Aster, but I would expect this kind of behavior if the heat flux sign convention differs between the two codes. In other words, the two solvers are interpreting the temperature difference in

q = h*A*(T_2 - T_1)

in opposite ways, in which case a temperature difference that should cool the solid instead heats it. If this is the case, perhaps flipping the sign on LAMBDA will produce the right behavior.

[buttersflg]

Thanks for your reply @Ray_Scarr
However, after debugging, the problem did not lie in the direction of heat transfer or the sign of the coefficient.This problem is caused by the way Code_Aster writes data.

What was happening?

I printed out the content received by OpenFOAM, and the result shows that OpenFOAM was reading incorrect values:

• Sink-Temperature-Solid was receiving an unexpectedly high value (10000000 in my case).
• Heat-Transfer-Coefficient-Solid was receiving a reasonable temperature value (e.g., 300.058303).

This indicated that the two datasets were swapped in Code_Aster’s output. This also explains why the temperature on the interface is 10000000

Solution

The issue was caused by the incorrect order of writeDataNames in the Code_Aster adapter. Originally, the code was:

self.precice.write_data(self.nodesMeshName, self.writeDataNames[0], self.preciceNodeIndices, writeHCoeff)
self.precice.write_data(self.nodesMeshName, self.writeDataNames[1], self.preciceNodeIndices, writeTemp)

However, the correct order should be:

self.precice.write_data(self.nodesMeshName, self.writeDataNames[1], self.preciceNodeIndices, writeHCoeff)
self.precice.write_data(self.nodesMeshName, self.writeDataNames[0], self.preciceNodeIndices, writeTemp)

After making this change, OpenFOAM received the correct temperature and heat transfer coefficient values, and the results matched the official preCICE benchmark.

Final Thoughts

The main issue was that Code_Aster was writing the temperature and heat transfer coefficient with reversed names. Fixing this resolved the incorrect data exchange.

I hope this helps anyone facing similar issues!

[Makis]

Hi @buttersflg,

thanks a lot for the detailed updates, and good that you found a solution. You actually found a bug, which I documented in an issue: Wrong order of writing data · Issue #27 · precice/code_aster-adapter · GitHub

We have noone working on the code_aster adapter since a while, and it was always something extra that we needed to maintain, but could not easily test. If your work depends on this adapter, we would very much appreciate some help to keep it up-to-date and fix such issues.

The issue I opened now is very easy to contribute a fix for (and you already identified the fix). If you want, go ahead an open a pull request, otherwise I will add the fix later.

By the way, last time I checked, I had trouble installing code_aster 14.6 on newer systems (the release was from 2020, and code_aster 15 seems to be in testing mode since a long time). Do you maybe know what the status of code_aster is at the moment?

[buttersflg]

Hi @Makis,

Thank you for your response and for documenting this issue. I’m glad I could help identify the bug. However, I won’t be able to contribute a fix via a pull request, as my work with Code_Aster is limited to a course project. I mainly intended to explore Code_Aster for some case studies and demonstrations, and I don’t plan to work with it further in the future.

Regarding Code_Aster 14.6 installation, the only issue I encountered was when verifying the installation with:

as_run --vers=14.6 --test forma01a

The terminal output included:

--- DIAGNOSTIC JOB : <A>_ALARM

However, this did not affect my ability to perform fluid-structure coupling simulations. Unfortunately, I don’t have more insights into the current status of Code_Aster development.

Thanks again for your support!

Best regards,
Butters

[Makis]

Thank you very much, @buttersflg. Completely understandable, I will open a PR soon and try to revive this adapter at some point.

Keep writing here in case you need more help, or if you have any further insights.