Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-28T09:28:57Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1571Incorrect Nastran surface value export2020-05-14T16:02:42ZPrashant SonakarIncorrect Nastran surface value exportCross Ref : EP#1210
Indexing error in writing as discussed with @markCross Ref : EP#1210
Indexing error in writing as discussed with @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1572snappyHexMesh leak detection is prone to false positives2024-01-10T16:49:17ZJustin GraupmansnappyHexMesh leak detection is prone to false positives<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
snappyHexMesh leak detection using the locationsOutsideMesh keyword is highly prone to false positives. In other words, a detected leak often doesn't actually cause the mesh to leak when meshed.
### Steps to reproduce
I've attached a simple model to demonstrate this issue. The model is simply a block inside of another block. The inner block has a triangle removed which snappyHexMesh detects as a leak.
On the attached model run...
* blockMesh
* snappyHexMesh -overwrite
You should get an error and a leak path is exported. Now...
* remove the locationsOutsideMesh keyword in the snappyHexMeshDict
* re-run snappyHexMesh
* Review mesh, you'll see that there is no leak into the inner box
### Example case
[boxLeakBug.zip](/uploads/48fe8be4c572aefea8a29b2dcc218453/boxLeakBug.zip)
### What is the current *bug* behaviour?
snappyHexMesh detects a leak when there isn't one.
### What is the expected *correct* behavior?
snappyHexMesh should only detect a leak if there actually is one.
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL/Windows 10
- Hardware info : Intel
- Compiler : gcc/minGW
### Possible fixes
I suspect the leak detection code is not using the same method that is used to find regions and remove cells during the castellation phase. If possible, the same walking method used to find regions and remove cells should be used to find leaks between the two points. The current method produces way too many false positives to be useful on more complex geometry.v2012https://develop.openfoam.com/Development/openfoam/-/issues/1573Add support for automatically reading "fileName.orig" files if the correspond...2020-01-29T03:40:36ZAlberto PassalacquaAdd support for automatically reading "fileName.orig" files if the corresponding "fileName" is absentCurrently, .orig files are used to back files up before performing initialization with utilities such as setFields.
However, the .orig files either
1. Need to be rename with rm or a script
2. The utility foamRestoreFiles -method orig...Currently, .orig files are used to back files up before performing initialization with utilities such as setFields.
However, the .orig files either
1. Need to be rename with rm or a script
2. The utility foamRestoreFiles -method orig -withZero must be executed, which renames the .orig files on the 0 directory instead of renaming a copy of the same files, effectively destroying the .orig file
The .org version has implemented a feature to read the .orig files automatically if the corresponding "non .orig" file is missing: https://github.com/OpenFOAM/OpenFOAM-dev/commit/df6e2da2dd89227cee05c0bc0c1bf4f9b80849d5 This feature would make the process of preserving .orig files a lot simpler and transparent to the user.v2006https://develop.openfoam.com/Development/openfoam/-/issues/1574native reduce for solveScalar2020-04-15T08:53:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnative reduce for solveScalar### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel running### Functionality to add/problem to solve
Foam::reduce is specialised for summation of scalar but not solveScalar. Hence in SPDP mode it will fall back to non-native reduce (might be slower)
### Target audience
Parallel runninghttps://develop.openfoam.com/Development/openfoam/-/issues/1576coded FO does not support mesh changes2020-01-27T15:19:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoded FO does not support mesh changes### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify...### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify missing callbacks
- syntax inside codedFunctionObject to specify the missing code ('codeMovePoints'?)
- redirection callshttps://develop.openfoam.com/Development/openfoam/-/issues/1577typo in FULLDEBUG2020-04-22T20:57:59ZPer Jørgensentypo in FULLDEBUGsrc/OpenFOAM/expressions/exprResult/exprResultGlobals.C line 206
sortToc -> sortedTocsrc/OpenFOAM/expressions/exprResult/exprResultGlobals.C line 206
sortToc -> sortedTocMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1579improvements foamToEnsightParts2020-06-22T10:10:10ZMark OLESENimprovements foamToEnsightPartsCurrently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain ce...Currently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain cellZone information in parallel as well, which implies making foamToEnsightParts parallel-aware. Explore the possibility of merging some foamToEnsightParts aspects into ensightMesh (ie, foamToEnsight) and enabling/disabling on a switch.
Cross-ref: EP1109v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1580Not Really an Issue more of a question/suggestion2020-06-19T21:05:49ZCole MuellerNot Really an Issue more of a question/suggestionI have been working with CHTmultiregionfoam pretty heavily and I have noticed on all the mapped boundaries there is no way to relax them. This then forces them to rely on the relaxation of the neighboring systems to remain stable at high...I have been working with CHTmultiregionfoam pretty heavily and I have noticed on all the mapped boundaries there is no way to relax them. This then forces them to rely on the relaxation of the neighboring systems to remain stable at high CFL or you are limited by the CFL or you are forced to perform large numbers of iterations to ensure convergence. This is due to the explicit nature of the mapping procedure. I could be mistaken but I have built custom boundary conditions from Mappedflowrate and then the mapped condition and the BC's I created were unstable unless I added relaxation in. So after that long winded explanation, my question, "Is there relaxation features for the coupled boundaries themselves?" and if the answer is no, "Is there any plans to include them in the future?" and just to clarify my boundaries are relaxed independently from the main equations with entirely different relaxation and allow for much faster equation convergence without having to reduce my time steps. In some cases in improved stability drastically at large time steps.https://develop.openfoam.com/Development/openfoam/-/issues/1581transient solver with suitable ddtScheme2020-02-03T12:37:26ZPrashant Sonakartransient solver with suitable ddtScheme### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
###...### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
### Proposal
Would be nice to give a warning message. It still should be possible in general (e.g. to replace an outer loop with the time loop).
Cross Ref: EP#1204https://develop.openfoam.com/Development/openfoam/-/issues/1582source etc/cshrc fails when given with more than 1 argument2020-02-12T17:31:43ZDavid Ludlowsource etc/cshrc fails when given with more than 1 argument<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
A syntax error is returned if `etc/cshrc` is sourced with more than 1 argument.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
In a c-shell. running the command (for example):
`source ~/OpenFOAM/OpenFOAM-v1912/etc/cshrc WM_PRECISION_OPTION=DP WM_LABEL_SIZE=32`
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
N/A
### What is the current *bug* behaviour?
<!-- What actually happens -->
The shell returns:
`Syntax Error.`
and OpenFOAM environment variables aren't set as expected.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No error returned and the environment variables set as expected!
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
N/A
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1812, v1906, v1912
- Operating system : Centos6
- Hardware info : N/A
- Compiler : N/A
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
This bug appears to be related to the movement of some lines from `etc/cshrc` to `etc/config.csh/setup` and the way that the command-line arguments are passed and then interpreted. One way to fix this is by replacing the line:
`source "$WM_PROJECT_DIR/etc/config.csh/setup" "${*}"`
in `etc/cshrc` by:
`source "$WM_PROJECT_DIR/etc/config.csh/setup" $argv:q`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1583checkMesh : patch geometry : include flatness2020-02-05T13:34:26ZPrashant SonakarcheckMesh : patch geometry : include flatness### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w....### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w.r.t. average.
Q:
- how much deviation is non-flat
- report per patch-region (e.g. for lid-driven cavity tutorial where single patch has 3 different orientations)
Cross-ref : EP#1159https://develop.openfoam.com/Development/openfoam/-/issues/1584link to the verification of the tutorial case surfaceMounrtedCube2020-02-12T17:31:43ZSon Volink to the verification of the tutorial case surfaceMounrtedCubeThe link to the verification of the case surfaceMountedCube is stated here:
https://develop.openfoam.com/Development/openfoam/blob/develop/tutorials/incompressible/pimpleFoam/LES/surfaceMountedCube/README
The link is
openfoam.com/docu...The link to the verification of the case surfaceMountedCube is stated here:
https://develop.openfoam.com/Development/openfoam/blob/develop/tutorials/incompressible/pimpleFoam/LES/surfaceMountedCube/README
The link is
openfoam.com/documentation/cpp-guide/html/verification-validation-turbulent-surface-mounted-cube.html
but cannot be found in the internet.
Son.v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1585runTimePostProcessing : Failed closing "librunTimePostProcessing.so" when run...2021-07-06T17:02:45ZSimone BnarunTimePostProcessing : Failed closing "librunTimePostProcessing.so" when run finishesContinuation or re-opening of #354
- Test Case: tutorials/incompressible/simpleFoam/windAroundBuildings
- Version : v1912
- OS: CentOS 7.4
- VTK: 8.2.0 (compiled from VTK sources with Spack)
- MPI: intel-mpi@2019.6.154
- Compiler: int...Continuation or re-opening of #354
- Test Case: tutorials/incompressible/simpleFoam/windAroundBuildings
- Version : v1912
- OS: CentOS 7.4
- VTK: 8.2.0 (compiled from VTK sources with Spack)
- MPI: intel-mpi@2019.6.154
- Compiler: intel@19.0.5.281
- systemGCC: 4.8.5
I successful compiled OpenFOAM v1912 with the off-screen feature implemented in VTK.
VTK has been compiled from sources, version 8.2, using the Spack vtk recipe.
The vtk package of spack has been patched by adding
`-DModule_vtkRenderingParallel=ON`
otherwise OpenFOAM fails to compile the runTimePostProcessing module.
To test the software, I run the windAroundBuildings test case.
After finishing the run, the following message is thrown for both single processor and for multiprocessor. However the image file is dumped in normal way and is fine.
```
--> FOAM Warning :
From function void Foam::dlLibraryTable::clear(bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 164
Failed closing "librunTimePostProcessing.so" with handle 0x2c893e0
Finalising parallel run
simpleFoam: symbol lookup error: /galileo/home/userinternal/sbna0000/spack/opt/spack/linux-centos7-broadwell/gcc-8.3.0/vtk-8.2.0-5edsni3orkxikqdmrrlp7ghdqp6lowv4/lib64/libvtkCommonExecutionModel-8.2.so.1: undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
```
I run
```
nm -D /galileo/home/userinternal/sbna0000/spack/opt/spack/linux-centos7-broadwell/gcc-8.3.0/vtk-8.2.0-5edsni3orkxikqdmrrlp7ghdqp6lowv4/lib64/libvtkCommonExecutionModel-8.2.so.1 | grep _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
```
which returns _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv, so this function is there,
in the dynamic symbol table.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1587#include directive not working in snappyHexMeshDict with collated file handler2020-03-12T10:38:47ZMortesins#include directive not working in snappyHexMeshDict with collated file handler<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The #include directive does not work properly inside snappyHexMeshDict when running with the collated file handler. It throws the following error:
```
[1] --> FOAM FATAL ERROR:
[1] Not implemented
[1]
[1] From function virtual Foam::Istream& Foam::ITstream::readRaw(char*, std::streamsize)
[1] in file db/IOstreams/Tstreams/ITstream.C at line 344.
```
### Steps to reproduce
1) Starting from the motorbike tutorial, move the refinementSurfaces settings to an external file. So the snappyHexMeshDict will look like this:
```
refinementSurfaces
{
#include "motorBikeRefinementDict"
}
```
and a new file called motorBikeRefinementDict should contain the following:
```
motorBike
{
// Surface-wise min and max refinement level
level (5 6);
// Optional specification of patch type (default is wall). No
// constraint types (cyclic, symmetry) etc. are allowed.
patchInfo
{
type wall;
inGroups (motorBikeGroup);
}
}
```
2) Change the file handler to be collated. NOTE: there is no issue with the uncollated format.
### Example case
I've attached:
[snappyHexMeshDict](/uploads/aae5cbd4178b3b0b076b4c285ccd861e/snappyHexMeshDict)
[motorBikeRefinementDict](/uploads/bc4dd73eba353d2d54bbe59faa5eae4f/motorBikeRefinementDict)
[controlDict](/uploads/787b9b9bbd556a2bc335126f5861187c/controlDict)
### What is the current *bug* behaviour?
Snappy crashes.
### What is the expected *correct* behavior?
The #include directive should be correctly parsed.
### Relevant logs and/or images
```
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0
Read mesh in = 0 s
Overall mesh bounding box : (-5 -4 0) (15 4 8)
Relative tolerance : 1e-06
Absolute matching distance : 2.29783e-05
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Not implemented
[1]
[1] From function virtual Foam::Istream& Foam::ITstream::readRaw(char*, std::streamsize)
[1] in file db/IOstreams/Tstreams/ITstream.C at line 344.
[1]
FOAM parallel run aborting
[1]
[1] #0 Foam::error::printStack(Foam::Ostream&)Reading refinement surfaces.
Read refinement surfaces in = 0.33 s
Reading refinement shells.
Refinement level 4 for all cells inside refinementBox
Read refinement shells in = 0 s
Setting refinement level of surface to be consistent with shells.
at ??:?
[1] #1 Foam::error::abort() at ??:?
[1] #2 Foam::ITstream::readRaw(char*, long) at ??:?
[1] #3 Foam::readRawLabel(Foam::Istream&, int*, unsigned long) at ??:?
[1] #4 Foam::Istream& Foam::operator>><int, 2u>(Foam::Istream&, Foam::FixedList<int, 2u>&) at ??:?
[1] #5 Foam::refinementSurfaces::refinementSurfaces(Foam::searchableSurfaces const&, Foam::dictionary const&, int, bool) at ??:?
[1] #6 ? at ??:?
[1] #7 __libc_start_main in /lib64/libc.so.6
[1] #8 ? at ??:?
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
* OpenFOAM version : v1912
* Operating system : CentOS Linux 7
* Compiler : Gcc 4.8.5Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1588foamListTimes -processor -rm does not work for collated format2020-03-12T10:38:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamListTimes -processor -rm does not work for collated format### Functionality to add/problem to solve
`foamListTimes -processor` shows the current time directories. It also works with `-fileHandler collated`. However the additional `-rm` option does not delete the time directories.### Functionality to add/problem to solve
`foamListTimes -processor` shows the current time directories. It also works with `-fileHandler collated`. However the additional `-rm` option does not delete the time directories.https://develop.openfoam.com/Development/openfoam/-/issues/1589blockMesh with geometric point merging fails on high-aspect ratio cells2020-06-19T14:36:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comblockMesh with geometric point merging fails on high-aspect ratio cells<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Run a case with very high aspect ratio cells. Sometimes this can trigger the geometric point merging to merge points (because it thinks it is generating a wedge geometry)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
[blockMeshDict](/uploads/fa51249e298f11d29ef696696f8854ce/blockMeshDict)
run
```
blockMesh
checkMesh
```
and checkMesh reports 2 hexes. Now comment out the `fastMerge` and repeat. It will report two wedges.
This is a known problem of the geometric point merging - the topological `fastMerge` algorithm is also quicker to run.https://develop.openfoam.com/Development/openfoam/-/issues/1590SPDP always copies input List2020-04-15T08:53:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSPDP always copies input List### Functionality to add/problem to solve
In SPDP mode we make use of the PrecisionAdaptor class to automatically do the conversion. It converts both on construction and destruction.
### Proposal
Have constructor which does not conver...### Functionality to add/problem to solve
In SPDP mode we make use of the PrecisionAdaptor class to automatically do the conversion. It converts both on construction and destruction.
### Proposal
Have constructor which does not convert the input. This is e.g. useful in primitiveMeshCellCentresAndVols.C where we initialise the fields afterwards.https://develop.openfoam.com/Development/openfoam/-/issues/1591blockMesh face projection not robust2021-07-07T08:10:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comblockMesh face projection not robustblockMesh with a far-away surface gives a sigfpe since the residual stays zero.blockMesh with a far-away surface gives a sigfpe since the residual stays zero.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1592Proposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature ...2021-07-08T14:12:44ZRobin KamenickyProposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature iterationHello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there wa...Hello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there was a for loop to evaluate wall temperature Tw. The for loop was, however, not executed because of lagging (line 1124 // NOTE: lagging Tw update.).
Thus, the wall temperature was not evaluated after the calculation of the thermal turbulent diffusivity. This led to zero error between TsupPrev and TsupNew and so the for loop was not executed. The fix to that would be the evaluation of the maximum error from all CPUs. Thus
`scalar maxErr(gMax(mag(TsupPrev - TsupNew)));`
instead of
`scalar maxErr(max(mag(TsupPrev - TsupNew)));`
When the original version is used then each processor might evaluate the error if condition on the line 1260
if (maxErr < 1e-1) differently, which means that some processor exits the for loop and some processor loops again. In this manner, the processors enter different parts of the code. Once they encounter a mpi function which requests information also from the other processor, it waits (forever, deadlock). This exactly happens when alphatWallBoilingWallFunctionFvPatchScalarField.C is used together with the turbulentTemperatureCoupledBaffleMixedFvPatchScalarField.C
I propose that the for loop to find wall temperature is implemented (as it was removed from OF-v1912) and the lagging to be fixed in the manner I showed above. It is generally recommended by literature to do this looping. Its absence might not be a big issue for heat transfer which uses correlations (film boiling and transitional boiling) but might be an issue for more complicated nucleate boiling.
Thank you,
Kind regards,
RobinKutalmış BerçinKutalmış Berçin