[yvesc]

Hi all.

I am experimenting with chtMultiRegionFoam and have noted a jump in temperature at the interface between regions.

In order to see what is going on, I have made the following test case:
- pure conductive heat transfer
- 1D slab in two equal size regions with conductivity 1 and 2
- very crude (10x10) mesh.
- transient simulation until steady state is obtained.

The coupling between the two regions is a boundary patch: compressible::turbulentTemperatureCoupledBaffleMix ed.

The case is attached, just do

./Allclean
./Allrun

The results (plotoverline, attached) show that correct temperatures are obtained everywhere, except at the interface boundary; on each side of this boundary (thus on cell faces) it seems that the temperature is defined as that of the cell center; whereas from a physical point of view, there should only be one temperature at the inter-region boundary.


This may or may not be the same problem as met by others, for instance here; if it is, then I think the answers didn't quite address the question. For instance, here, it's heat conduction in solids, no jump is expected.

This may be the expected behaviour of compressible::turbulentTemperatureCoupledBaffleMix ed; I wonder however what will happen when I try to process quantities defined at the boundary.

Anyone who understands these interface BC can tell me what I did wrong, or else if there are other ways to do it?

[Dozer_94]

Hi yvesc!

Old thread, but I am curious as I am experiencing a similar issue. Did you manage to find a solution?

[pan]

Hi yvesc,

I also experience this problem now, do you know how to solve this problem now?

[SonnyD]

Hi guys,
I'm experiencing the same issue. It looks like this isn't really an error, this seems to be intended in the programming. When you look into the T-file of any written time step of your simulations you might notice, that for the interface patches of each domain (i.e. solid/fluid) two different columns of temperature values (one is called refValue, the other one just value are written for each cell of those patches. If you compare this to your post processing, you might see, one represents the fluid-side patch and one represents the solid-side patch.
In some solver descriptions I found the condition, that Tfluid=Tsolid for the interface. Well this is not true as we can see. But the condition (kappa*dT/dx)fluid=(kappa*dT/dx)solid can still be obtained I guess. So the heat fluxes are set to be equal. This does not necessarily indicate, that the temperatures at the wall are equal aswell. If you set i.e. kappaSolid>>kappaFluid=const. and dxSolid=dxFluid=const. for mesh independency. dTFluid needs to be unequal to dTSolid, where the upper and the lower temperature limits of your system are pre-defined by your BCs, so the maximum dT of every side is strictly limited.

That is the only way I can explain to myself, why there are two solutions.
Maybe anyone else has a better and more reliable explanation for this.


And as an anwer to the original thread: I don't think, that this is an user induced mistake and initially I don't see any solution to this problem. I'm struggeling with this myself in relation to physical correctness. But the temperatures at the fluid-side patch hit the experimental data (which I used for validation) much better than the solid-side patch. Even though the different temperatures can't be correct.

[pan]

Hi,

Do you check the grids indenpendence? I checked that, but when the grids number reaches some value, with the increase of the grids, the error also increases. I don't know where is wrong, have you ever checked that?

[SonnyD]

Thanks for your quick answer!


Yes, I have the same mesh resolution on both sides of the interface. I also tried coarser and finer mesh resolutions. Now my mesh resolution leads to y+ < 1. With a coarser mesh, the discontinuity did not dissappear aswell.
I cannot explain to myself why this issue hasn't been fixed already, because this seems to be a problem for a long time.



Maybe anyone already asked the OF-support?