externalWallHeatFluxTemperature zeros h value if patch is out of processor
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:
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 processor0/anyTStep/T Code:
BC-1 (OUT OF PROCESSOR-0) processor3/anyTStep/T: Code:
BC-1 (IN PROCESSOR-3) 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. |
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) |
That's great, Mark! Thanks. I'll try that.
|
All times are GMT -4. The time now is 16:46. |