Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-11-25T08:05:19Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2638foamRestoreFields does not handle regions2022-11-25T08:05:19ZMark OLESENfoamRestoreFields does not handle regionscross-ref EP2048cross-ref EP2048Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2637motorBike: snappyHexMesh: increase in cell count2022-12-23T13:52:21ZKutalmış BerçinmotorBike: snappyHexMesh: increase in cell count`$FOAM_TUTORIALS/pisoFoam/LES/motorBike` produces a mesh of considerable difference in cell count when `snappyHexMesh` is executed with 3b0af86448 (develop) vs 76d719d1 (2206):
[log.checkMesh.2206.zip](/uploads/afcbc83f6a92304e6a9f3ac01...`$FOAM_TUTORIALS/pisoFoam/LES/motorBike` produces a mesh of considerable difference in cell count when `snappyHexMesh` is executed with 3b0af86448 (develop) vs 76d719d1 (2206):
[log.checkMesh.2206.zip](/uploads/afcbc83f6a92304e6a9f3ac0190886d8/log.checkMesh.2206.zip)
```
points: 3925080
faces: 10332611
internal faces: 9704338
cells: 3238121
faces per cell: 6.18783
boundary patches: 73 (74 79)
```
vs
[log.checkMesh.develop.zip](/uploads/1bc338633dd293ac732a1f0a0bd2f0be/log.checkMesh.develop.zip)
```
points: 4859321
faces: 12761976
internal faces: 11993902
cells: 3999062
faces per cell: 6.19042
boundary patches: 73 (74 78)
```
@Mattijs @mark @andy @Prashant
Some recent comments made for `snappyHexMesh`:
34d69cad234b2ef5215054205c4276c4f653e42c
f276366a050e99812c5f4fa7e3d0ef13be90c511
c418c28c66a091e3a047f6fd8cb553e1311f4589
5ea365a2be70e216d92fa86b2bb4bfccec887c29
27c3d0c23bbcd11cb1a91cb139dd78d96ec70b5dMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2636pointHistory functionObject creates processor0 directory, even when using col...2022-12-23T16:52:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compointHistory functionObject creates processor0 directory, even when using collated format### Functionality to add/problem to solve
pointHistory in parallel with collated format still creates an (empty) processor0 directory.### Functionality to add/problem to solve
pointHistory in parallel with collated format still creates an (empty) processor0 directory.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2635#eval and #calc rounding issues2024-01-11T12:19:46Zfranco otaola#eval and #calc rounding issues<!--
*** 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 re...<!--
*** 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 #eval function gives wrong results for small calculations. this can be highly troublesome as it is not something that one can 'see' easily.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
create a file with different eval commands and use foamDictionary to add an entry so it computes all the results.
### Example case
create a file with following variables
```
dp #eval{ sqrt(3./2.) *1e-3};
a #eval{ 2/sqrt(2.)*$dp };
A_square #eval{ $a*$a };
A_inlet #eval{ $A_square-2*degToRad(180)*$dp*$dp*0.25 };
Q $A_inlet;
Qerror #eval{$A_inlet};
e #eval{0.2526944494428081};
Uin #eval{ $Q/($A_square*$e) };
```
run `foamDictionary -entry edges -value file_test -set "( )"`
the evaluated file gives
```
dp 0.00122474;
a 0.00173241;
A_square 2.99982e-06;
A_inlet 6.42824e-07;
Q 6.42824e-07;
Qerror 1e-06;
e 0.252694;
Uin 1.31912;
edges ( );
```
which are not all correct (it looks like rounding issue)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206
- Operating system :centos
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2634faceReflecting radiationModel accesses unitialised data (valgrind)2022-11-18T15:03:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceReflecting radiationModel accesses unitialised data (valgrind)<!--
*** 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 re...<!--
*** 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 -->
`faceReflecting` radiationModel accesses uninitialised value.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up any case with faceReflecting.
### 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
-->
`tutorials/heatTransfer/buoyantSimpleFoam/simpleCarSolarPanel`
and run
`valgrind buoyantSimpleFoam`
### What is the current *bug* behaviour?
<!-- What actually happens -->
Tests uninitialised variable. The actual value will not get used though because of additional protection so the simulation proceeds correctly.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
### 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
-->
Initialise data to any value:
```
labelList refDirIndex(triangleIndex.size(), -1);
labelList refIndex(triangleIndex.size(), -1);
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2633improve control for openmp, and ccache2022-11-17T07:26:15ZMark OLESENimprove control for openmp, and ccacheFollowup on various exaFOAM discussions
- it would be useful to add tighter openmp integration. However, cannot be certain that it is installed on all systems.
- additional hooks for ccache, or equivalent. This would allow lifting of e...Followup on various exaFOAM discussions
- it would be useful to add tighter openmp integration. However, cannot be certain that it is installed on all systems.
- additional hooks for ccache, or equivalent. This would allow lifting of extra instrumentation (eg, TU-Darmstadt)
@sbna @skreutzerMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2631use atomic file creation and updates when writing sampled ensight data2022-11-26T19:06:21ZMark OLESENuse atomic file creation and updates when writing sampled ensight dataIssue raised on EP2007. If, for any reason, the simulation crashes while writing out ensight data, the resulting EnSight case file will very likely reference a truncated or corrupt file (does not make ensight happy).
First change requir...Issue raised on EP2007. If, for any reason, the simulation crashes while writing out ensight data, the resulting EnSight case file will very likely reference a truncated or corrupt file (does not make ensight happy).
First change required is to support an atomic OFstream option. This would create a file with a temporary name and only rename/move it to the final location after all writing is completed. If there is a crash during writing, there will be a few temporary files kicking about, but the expected output (in this case ensight) will not be corrupt.
The next changes would involve adjusting the management of ensight case updates to ensure that only consistent states exist. For the surface writing, this would mean attaching extra behaviour to the beginTime/endTime synchronization points.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2630solidBody motionSolver does not use optional sub dictionary2023-05-30T18:20:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolidBody motionSolver does not use optional sub dictionary<!--
*** 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 re...<!--
*** 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 -->
All motionSolvers should be able to either supply dictionaries inline or in a sub dictionary:
```
motionSolver solidBody;
solidBodyCoeffs
{
cellZone rotor;
solidBodyMotionFunction rotatingMotion;
origin (0 0 0);
axis (0 1 0);
omega 158; // rad/s
}
```
This does not work for solidBody anymore.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Attached case.
[testcase-zone-ignored.tgz](/uploads/4ff65b551b1a533d631152b9686bf182/testcase-zone-ignored.tgz)
### What is the current *bug* behaviour?
Does not read the selection of cells from the 'Coeffs' subdictionary. Instead applies motion to whole mesh.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Same behaviour, independent of dictionary supplied in-line or a a 'solidBodyCoeffs' subdictionary.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1912 .. v2206
- 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2629Tutorial on incompressible RAS eq. and lid-driven cavity not working as expected2023-05-30T18:21:55ZGiorgio GiorgianiTutorial on incompressible RAS eq. and lid-driven cavity not working as expectedRunning pisoFoam on the folder tutorials/incompressible/pisoFoam/RAS/cavity/ (with default input) is expected to run the simulation up to 10s achiving a Courant of ~0.2 max.
However, after time=2.5 the Courant number jumps to 1 and the ...Running pisoFoam on the folder tutorials/incompressible/pisoFoam/RAS/cavity/ (with default input) is expected to run the simulation up to 10s achiving a Courant of ~0.2 max.
However, after time=2.5 the Courant number jumps to 1 and the solution becomes meaningless.
![screens1](/uploads/bf213a5e6908c335ce3831807b355114/screens1.png)
![image](/uploads/f60f5e2348758910c233fffd1702089f/image.png)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2628Link to source files doesn't work2024-01-10T11:06:28ZTorquil SørensenLink to source files doesn't workWhen using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www....When using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www.openfoam.com/documentation/guides/latest/api/semiPermeableBaffleMassFractionFvPatchScalarField_8C.html
Under "Detailed Description", there is a link "semiPermeableBaffleMassFractionFvPatchScalarField.C" to https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/thermoTools/derivedFvPatchFields/semiPermeableBaffle/semiPermeableBaffleMassFraction/semiPermeableBaffleMassFractionFvPatchScalarField.C
But this link doesn't work. I am sent to a "404 page not found" error page.
The same happens when I click on any such link to a *.C-file on any of the documentation pages.
Thankfully, the link further up "Go to the source code of this file" does work.https://develop.openfoam.com/Development/openfoam/-/issues/2627cloud functionObjects not working with collated format2022-11-09T15:32:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcloud functionObjects not working with collated format### Functionality to add/problem to solve
In various bits of lagrangian functionObjects it uses a local check to decide if the file needs to be written. This means that processors that hold zero particles never get involved in the IO an...### Functionality to add/problem to solve
In various bits of lagrangian functionObjects it uses a local check to decide if the file needs to be written. This means that processors that hold zero particles never get involved in the IO and this causes problems when using e.g. 'collated' file format.
### Target audience
Lagrangian & parallel & collated file format
### Proposal
Replace checks for `if (c.size())` with a proper parallel decision:
```
const bool haveParticles = c.size();
if (c.time().writeTime() && returnReduce(haveParticles, orOp<bool>()))
{
Nu.write(haveParticles);
}
```
### What does success look like, and how can we measure that?
No hang
Attached a patch that makes the aachenBomb tutorial run through.
[collated_writing.patch](/uploads/857e5685955bec2b84b9ab47795b56a2/collated_writing.patch)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2626BUG: porousBafflePressure: fixedJump entries are not read2022-11-20T17:22:01ZKutalmış BerçinBUG: porousBafflePressure: fixedJump entries are not readSee the missing `dict` entry in the ctor: [porousBafflePressureFvPatchField.C#L59](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/porousBafflePressure/porousBaff...See the missing `dict` entry in the ctor: [porousBafflePressureFvPatchField.C#L59](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/porousBafflePressure/porousBafflePressureFvPatchField.C#L59)
The entries being not read by `porousBafflePressure` include (but not limited to):
```
jump
jump0
value
minJump
relax
```
```c
jump_(p.size(), Zero),
jump0_(p.size(), Zero),
minJump_(dict.getOrDefault<Type>("minJump", pTraits<Type>::min)),
relaxFactor_(dict.getOrDefault<scalar>("relax", -1)),
timeIndex_(this->db().time().timeIndex())
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2625argList option printing truncates incorrectly2022-11-18T20:24:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comargList option printing truncates incorrectly<!--
*** 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 re...<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`mapFieldsPar -help`
outputs
```
-mapMethod <word>
Specify the mapping method
(direct|mapNearest|cellVolumeWeight|correctedCellVolumeWeig
t)
```
(it left out the 'h' in correctedCellVolumeWeight at position 80)
### What is the current *bug* behaviour?
<!-- What actually happens -->
See above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system :
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2624expand the ListLoop macros2022-11-07T11:02:05ZMark OLESENexpand the ListLoop macrosFollowing discussions with Leopold and @sbna, makes sense to _unbox_ the List_FOR_ALL macro into its constituent parts.
As it stands, cannot place an loop pragmas in front, since there is an embedded initial looping parameter.
Cannot ea...Following discussions with Leopold and @sbna, makes sense to _unbox_ the List_FOR_ALL macro into its constituent parts.
As it stands, cannot place an loop pragmas in front, since there is an embedded initial looping parameter.
Cannot easily embed an `_Pragma()` within the macro since a macro paste token (`_n##i`) is used.
Main use case are the TFOR_ALL... macros in FieldM.H (used for various list/field operations). So replace there with explicit, identifiable loops.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2623direct reading with std::stream bypasses state checking2022-11-07T11:09:22ZMark OLESENdirect reading with std::stream bypasses state checkingAs noticed by @Mattijs with reading ensight files, the direct use of stdStream() for raw reading of strings means that failures are not properly noticed, since the IFstream wrapper state is not changed.
Needs visible `syncState()` metho...As noticed by @Mattijs with reading ensight files, the direct use of stdStream() for raw reading of strings means that failures are not properly noticed, since the IFstream wrapper state is not changed.
Needs visible `syncState()` method that can be called to ensure that the internal std::stream state and the OpenFOAM stream state match.
For ensight reading, this could be protected, but there are other locations using stdStream() that will need this too.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2622viewFactor not robust2022-11-25T08:05:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comviewFactor not robust<!--
*** 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 re...<!--
*** 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 -->
viewFactor smoothing fails if a face 'sees' zero other faces.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up case with only one patch, with only face in the viewFactor. This will (hopefully) generate a map which has zero entries for that face (since there are no other faces it can see)
### 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?
<!-- What actually happens -->
sigfpe from dividing by zero size.
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Protect division by zero.
<!--
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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2621limitTemperature option looks up thermo even if not active2022-11-30T08:26:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlimitTemperature option looks up thermo even if not active<!--
*** 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 re...<!--
*** 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 -->
Use limitTemperature in e.g. moveDynamicMesh with displacementLaplacian. displacementLaplacian constructs fvOptions. limitTemperature will fail since looks up thermo in constructor - even if not active.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
FatalError since cannot find thermo
### What is the expected *correct* behavior?
<!-- What you should see instead -->
At least obey 'active' flag
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Use isActive flag in constructor.
<!--
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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2620BUG: SpalartAllmarasDES: zero-valued subgrid-scale TKE field2022-11-15T15:27:54ZKutalmış BerçinBUG: SpalartAllmarasDES: zero-valued subgrid-scale TKE field### Summary
The DES models of `SpalartAllmaras` produce zero-valued `k` fields whenever requested (e.g. by `turbulenceFields`.) The `k` is computed in [SpalartAllmarasDES.C#L459](https://develop.openfoam.com/Development/openfoam/-/blob/...### Summary
The DES models of `SpalartAllmaras` produce zero-valued `k` fields whenever requested (e.g. by `turbulenceFields`.) The `k` is computed in [SpalartAllmarasDES.C#L459](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/DES/SpalartAllmarasDES/SpalartAllmarasDES.C#L459).
### Steps to reproduce
`./Allrun` the test case: [GL2619-test-case.zip](/uploads/3e596771d97bb743bedcd9e1a8705811/GL2619-test-case.zip), and inspect any `k` field.
### Environment information
3caeeb1f51998883efcca6020854c8c494e93b8a
### Possible fixes
- We need to understand why the current governing equations computing `k` field were used.
- We had introduced and validated estimation functions for `k`, `epsilon` and `omega` by c7357bd1c36c10f531444bb0a6272a6b9c434b94 for RANS SA model. Similar approximations can be used for DES SA model as well.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2619distributedTriSurfaceMesh in non-NFS mode2022-10-26T16:13:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistributedTriSurfaceMesh in non-NFS mode<!--
*** 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 re...<!--
*** 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 -->
distributedTriSurfaceMesh does not handle non-NFS mounted processors.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up case with distributedTriSurfaceMesh. decompose into two and move processor1 directory to new location. If case is called 'cavity':
```
decomposePar
mkdir -p machineB/cavity
mv processor1 machineB/cavity/
```
Change the decomposeParDict to switch on the distributed flag (or specify command-line options):
```
distributed yes;
roots ("<case>/machineB");
```
Run snappyHexMesh in parallel. The processor1 will fail.
### 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?
<!-- What actually happens -->
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206 and earlier
- 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2618BUG: functionObjectProperties: baseDict.findDict(objectName); interrupts func...2022-10-26T14:14:58ZKutalmış BerçinBUG: functionObjectProperties: baseDict.findDict(objectName); interrupts function object restarts### Summary
`./Allrun` the test case [GL2616-test-case.zip](/uploads/9875eb5b1df41f0da5bb35133dd6fbe8/GL2616-test-case.zip) with 0c3a938810. The restart with `pisoFoam` will throw the error below:
```
--> FOAM FATAL IO ERROR: (openfoa...### Summary
`./Allrun` the test case [GL2616-test-case.zip](/uploads/9875eb5b1df41f0da5bb35133dd6fbe8/GL2616-test-case.zip) with 0c3a938810. The restart with `pisoFoam` will throw the error below:
```
--> FOAM FATAL IO ERROR: (openfoam-2206 patch=220907)
Entry 'totalIter' not found in dictionary "
```
### Possible fixes
Change `objectName` in [functionObjectProperties.C#L140](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/OpenFOAM/db/functionObjects/functionObjectProperties/functionObjectProperties.C#L140) to `entryName`.Kutalmış BerçinKutalmış Berçin