[JulioPieri]

Hi all,

I'm facing a possible bug with the externalWallHeatFluxTemperature BC in parallel, OF v2012, WSL in win10. I'll be as detailed as I can be. This is what is happening:

• Start a parallel case with externalWallHeatFluxTemperature BC in which not all patches have cells in every processor;
• Stop and reconstruct the case at any tStep.
• Resuming the simulation (single processor) or re-decomposing and running it, causes it to crash in the energy equation. However, if I just restart the case before decomposition, it resumes ok! Also, all reconstructed data is correctly read in paraview.

I investigated it a little bit further and noticed that whenever there is no patch cell on the processor, it zeros the h value. Since I have many BCs and many processors, there are a lot of zeroed h in the processor/T files. When reconstructPar takes place, it zeroes all h values on every patch in the new T file! If I resume it that way, I get floating point exception (since h is used inversed in of the thermal resistance calculation). If I manually edit the h back to non-zero values, it works. Also, if I restart the parallel simulation, it also works, as the h values are not zeroed where they are needed.

More detailed example:

Original BC config:

BC-1
{
    type            externalWallHeatFluxTemperature;
    mode            coefficient;
    qr              qr;
    qrRelaxation    0.001;
    emissivity      0.9;
    Ta              constant 723.0;
    h               constant 111.0;
    kappaMethod     fluidThermo;
    value           $internalField;
}

BC-2
{ ... and so on

When I decompose the case and start to run it works, but when that patch is not on the processor's domain, h becomes zero:

processor0/anyTStep/T

BC-1 (OUT OF PROCESSOR-0)
{
    type            externalWallHeatFluxTemperature;
    mode            coefficient;
    kappaMethod     fluidThermo;
    kappa           none;
    alphaAni        none;
    alpha           none;
    h               constant 0;
    Ta              constant 723;
    emissivity      0.9;
    qr              qr;
    qrRelaxation    0.005;
    qrPrevious      nonuniform List<scalar> 0(0);
    refValue        nonuniform List<scalar> 0(0);
    refGradient     uniform 0;
    valueFraction   nonuniform List<scalar> 0(0);
    value           nonuniform List<scalar> 0(0);
}

But if the processor has same cells of that patch, the h is preserved.

processor3/anyTStep/T:

BC-1 (IN PROCESSOR-3)
{
    type            externalWallHeatFluxTemperature;
    mode            coefficient;
    kappaMethod     fluidThermo;
    kappa           none;
    alphaAni        none;
    alpha           none;
    h               constant 111;
    Ta              constant 723;
    emissivity      0.9;
    qr              qr;
    qrRelaxation    0.005;
    qrPrevious      nonuniform List<scalar> 1883(...);
    refValue        nonuniform List<scalar> 1883(...);
    refGradient     uniform 0;
    valueFraction   nonuniform List<scalar> 1883(...);
    value           nonuniform List<scalar> 1883(...);
}

When reconstructing, all h are zeroed. I believe it does some kind of average and sees that in the majority of the processors, that particular patch has h=0 (because of this bug). Then it reconstructs with h=0... and that for all patches.

I tried to dig into the code, and I believe this is related to the BC write() stage or something, and not with the decompose/reconstruct step. The h might be "updated, else kept as initialized" somewhere in the code. I also believe this might happen for q (flux) and Q (power) modes as well, because the way the code is written. Note that Ta is always preserved, pointing at the direction of how to solve this.

The palliative solution is to run mapFields from a clean BC configuration (i.e., with all correct h entries) whenever I need to reconstruct it. This will overwrite the BCs with fresh working ones, and keep the patch values.

[olesen]

Sounds like it might be this one: https://develop.openfoam.com/Develop.../-/issues/2101

with these changes: https://develop.openfoam.com/Develop...e77bdc8f220e95


If you are using WSL, try with openfoam2112 (can be installed without collisions)

[JulioPieri]

That's great, Mark! Thanks. I'll try that.