CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Bugs

externalWallHeatFluxTemperature zeros h value if patch is out of processor

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 12, 2022, 17:21
Default externalWallHeatFluxTemperature zeros h value if patch is out of processor
  #1
Member
 
Julio Pieri
Join Date: Sep 2017
Posts: 75
Rep Power: 7
JulioPieri is on a distinguished road
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:
Code:
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
Code:
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:
Code:
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.
JulioPieri is offline   Reply With Quote

Old   January 13, 2022, 12:02
Default
  #2
Senior Member
 
Mark Olesen
Join Date: Mar 2009
Location: https://olesenm.github.io/
Posts: 1,503
Rep Power: 35
olesen will become famous soon enougholesen will become famous soon enough
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)
olesen is offline   Reply With Quote

Old   January 13, 2022, 13:08
Default
  #3
Member
 
Julio Pieri
Join Date: Sep 2017
Posts: 75
Rep Power: 7
JulioPieri is on a distinguished road
That's great, Mark! Thanks. I'll try that.
JulioPieri is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Other] Can't Shake Erros: patch type 'patch' not constraint type 'empty' BrendaEM OpenFOAM Meshing & Mesh Conversion 12 April 3, 2022 19:32
Foam-Extend 4.0 simpleFoam motorbike parallel error? EternalSeekerX OpenFOAM Running, Solving & CFD 0 May 10, 2021 05:55
[snappyHexMesh] Error snappyhexmesh - Multiple outside loops avinashjagdale OpenFOAM Meshing & Mesh Conversion 53 March 8, 2019 10:42
parallel run OpenFoam Srinath Reddy OpenFOAM Running, Solving & CFD 13 February 27, 2019 10:15
Possible Bug in pimpleFoam (or createPatch) (or fluent3DMeshToFoam) cfdonline2mohsen OpenFOAM 3 October 21, 2013 10:28


All times are GMT -4. The time now is 21:33.