Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-11-30T17:56:13Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3038SRFModel tmp early release2023-11-30T17:56:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSRFModel tmp early release<!--
*** 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 -->
SRFModel illegal tmp use
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run SRFPimpleFoam tutorial:
```
--> FOAM FATAL ERROR: (openfoam-2309)
tmp<N4Foam14GeometricFieldINS_6VectorIdEENS_12fvPatchFieldENS_7volMeshEEE> deallocated
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2308
### 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
-->
Introduced in !628Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2978BUG: runTimeModifiable crashes with collated in rhoPimpleFoam2023-11-23T15:51:12ZAlberto ceschinBUG: runTimeModifiable crashes with collated in rhoPimpleFoam### Summary
It is not possible to modify i.e. `endTime` during run time in tutorial `compressible/rhoPimpleFoam/RAS/aerofoilNACA0012` in parallel with `-fileHandler collated` and `runTimeModifiable true`. On the contrary, other solvers ...### Summary
It is not possible to modify i.e. `endTime` during run time in tutorial `compressible/rhoPimpleFoam/RAS/aerofoilNACA0012` in parallel with `-fileHandler collated` and `runTimeModifiable true`. On the contrary, other solvers behaeve as expected.
### Steps to reproduce
copy tutorial
`OpenFOAM-v2306/tutorials/compressible/rhoPimpleFoam/RAS/aerofoilNACA0012`
into run folder;
`foamGetDict decomposeParDict`;
Reduce number of cores to 4 and eliminate what is after scotch from the dictionary;
Increase `endTime` to `100`;
`./Allrun` but in parallel with
`runApplication decomposePar -fileHandler collated`;
`runParallel rhoPimpleFoam -fileHandler collated`;
at the end.
Change `endTime` to `101` during run time;
### What is the current *bug* behaviour?
```ExecutionTime = 13.52 s ClockTime = 13 s
From virtual bool Foam::regIOobject::readIfModified()
in file db/regIOobject/regIOobjectRead.C at line 271
Re-reading object controlDict from file "/home/username/OpenFOAM/username-v2306/run/FOAM_RUN/system/controlDict"
[0]
[0]
[0] --> FOAM FATAL IO ERROR: (openfoam-2306)
[0] Cannot find file "/home/username/OpenFOAM/username-v2306/run/FOAM_RUN/processor0/system/controlDict" fileHandler : comm:0 ioRanks:4(0 1 2 3)
[0]
[0] From static Foam::autoPtr<Foam::ISstream> Foam::fileOperations::masterUncollatedFileOperation::read(Foam::IOobject&, Foam::label, bool, const fileNameList&, const boolUList&)
[0] in file global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.C at line 526.
[0]
FOAM exiting
[0]
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[8529,1],0]
Exit code: 1
-------------------------------------------------------------------------
```
### Environment information
OpenFOAM version : v2306
Operating system : ubuntu 22https://develop.openfoam.com/Development/openfoam/-/issues/3009Nastran parser does not handle newer ANSA conventions2023-11-21T22:57:31ZMark OLESENNastran parser does not handle newer ANSA conventionsAlthough the Nastran format does not support names for shells etc, both Hypermesh and ANSA have their own conventions for using/misusing comments to convey that extra information. The nastran parser needs an update to handle the newer AN...Although the Nastran format does not support names for shells etc, both Hypermesh and ANSA have their own conventions for using/misusing comments to convey that extra information. The nastran parser needs an update to handle the newer ANSA conventions that are now circulating. The benefit is that this will allow more direct use of Nastran surface files elsewhere (eg, snappy).
cross-ref EP2299
@martin.lichtmes
Some notes (courtesy Martin Lichtmes)
---
### Type 1 - ANSA 19.0.1:
Region names contained in comment line immediately above respective PSHELL line.
- Header info: <br>
ANSA version
Output format specification [MSC|NX|AUTODESK] (no effect on file content detected)
- Footer info: <br>
$ANSA_NAME_COMMENTS etc. but not relevant for region naming
PSHELL info: Region names in commentary line immediately above (single string)
### Type 2 - ANSA 23.1.0:
Region names contained in footer section as part of $ANSA_NAME_COMMENT (fourth semicolon-separated entry).
- Header info: <br>
ANSA version
Output format specification [MSC|NX|AUTODESK] (no effect on file content detected)
- Footer info: <br>
$ANSA_NAME_COMMENT relevant for region naming
PSHELL info: No relevant/commentary information for region naming
### Type 3 - Possibly ANSA/unknown:
Region names contained in comment line immediately above respective PSHELL line.
- Header info: None
- Footer info: None
PSHELL info: Region names in commentary line immediately above (single string)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3028non-orthogonal faces to set nonOrthoFaces2023-11-16T15:22:11ZFarshad Ansarinon-orthogonal faces to set nonOrthoFacesHello,
When I import my data.unv with the ideasUnvToFoam command, everything is ok. But after meshCheck I get this error:
*Number of severely non-orthogonal (> 70 degrees) faces: 612.
Non-orthogonality check OK.
<<Writing 612 no...Hello,
When I import my data.unv with the ideasUnvToFoam command, everything is ok. But after meshCheck I get this error:
*Number of severely non-orthogonal (> 70 degrees) faces: 612.
Non-orthogonality check OK.
<<Writing 612 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 1.23757 OK.
Coupled point location match (average 0) OK.
Failed 1 mesh checks.
what should I do?
thankshttps://develop.openfoam.com/Development/openfoam/-/issues/2998Lagrangian ConeInjection model fails to restart smoothly2023-11-14T18:53:27ZAndrew HeatherLagrangian ConeInjection model fails to restart smoothlyWhen restarting cases with the ConeInjection injector model parcels typically fail to be injected/incorrect counts recorded.
Cross ref: EP2280When restarting cases with the ConeInjection injector model parcels typically fail to be injected/incorrect counts recorded.
Cross ref: EP2280v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2989surfaceFieldValue: Not all patches in 'names' list are reported in Info stream2023-11-09T23:23:29ZMartin LichtmessurfaceFieldValue: Not all patches in 'names' list are reported in Info stream<!--
*** 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
When evaluating multiple patches in surfaceFieldValue FO using 'names' keyword, not all patch names seem to be reported back in Info stream, whereas the numerical value appears to be correct - only first patch name in list? - May cause confusion as to which patches contribute to the evaluation.
### Steps to reproduce
1. Set up surfaceFieldValue FO using list of patches (e.g. 'names (inlet, outlet)' in pitzDaily) and apply 'sum' operation
2. Run case and monitor info stream/solver output regarding surfaceFieldValue evaluation
### Example case
$FOAM_TUTORIALS/incompressible/pisoFoam/LES/pitzDaily
### What is the current *bug* behaviour?
Log snippet for three FOs (1. 'name inlet', sum(phi); 2. 'name outlet', sum(phi); 3. 'names (inlet outlet), sum(phi)):
```
surfaceFieldValue namesTest_inlet write:
sum(inlet) of phi = -0.000253241
surfaceFieldValue namesTest_outlet write:
sum(outlet) of phi = 0.000253241
surfaceFieldValue namesTest_inlet_outlet write:
sum(inlet) of phi = 2.09431e-11
```
### What is the expected *correct* behavior?
```
surfaceFieldValue namesTest_inlet_outlet write:
sum(inlet, outlet) of phi = 2.09431e-11
```
### 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
- OpenFOAM version : v2306
- Operating system : Ubuntu WSL/RedHat 8
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/3007IOobject requires global path and object methods2023-11-09T23:20:57ZMark OLESENIOobject requires global path and object methodsAs part of integration efforts (@Serge and @gregorweiss) we need convenient access to both global path names (ie, the serial paths) as well as the processor paths. Need to propagate through some values from Time/TimePaths.As part of integration efforts (@Serge and @gregorweiss) we need convenient access to both global path names (ie, the serial paths) as well as the processor paths. Need to propagate through some values from Time/TimePaths.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3016Paraview, OpenFoam Error.2023-11-09T10:59:00ZMathew DevaParaview, OpenFoam Error.I installed OpenFoam 2306 and paraview 5.11 from official sites. initaly i got the error as :
Invalid $PV_PLUGIN_PATH and -plugin-path= not defined
No supplementary ParaView/OpenFOAM reader modules
Using builtin reader: paraFoam -vtk
C...I installed OpenFoam 2306 and paraview 5.11 from official sites. initaly i got the error as :
Invalid $PV_PLUGIN_PATH and -plugin-path= not defined
No supplementary ParaView/OpenFOAM reader modules
Using builtin reader: paraFoam -vtk
Created temporary 'pitzDaily.foam'
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: xcb.
But after i executed sudo apt-get install libqt5x11extras5, now i am getting this error:
Invalid $PV_PLUGIN_PATH and -plugin-path= not defined
No supplementary ParaView/OpenFOAM reader modules
Using builtin reader: paraFoam -vtk
Created temporary 'pitzDaily.foam'
Help me with this. I'm a newbie to OpenFoam.https://develop.openfoam.com/Development/openfoam/-/issues/3025stringOps::split with keep empty accidentally ignores non-empty trailing element2023-11-09T10:57:48ZMark OLESENstringOps::split with keep empty accidentally ignores non-empty trailing elementMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3019decompositionMethod calcCellCells with weighting looks odd2023-11-07T22:12:39ZMark OLESENdecompositionMethod calcCellCells with weighting looks oddIn calcCellCells, the weighting per cell is done by using the face area of some attached face. Eg,
// For internal faces is just offsetted owner and neighbour
for (label facei = 0; facei < mesh.nInternalFaces(); ++facei)
{
...In calcCellCells, the weighting per cell is done by using the face area of some attached face. Eg,
// For internal faces is just offsetted owner and neighbour
for (label facei = 0; facei < mesh.nInternalFaces(); ++facei)
{
const label own = agglom[faceOwner[facei]];
const label nei = agglom[faceNeighbour[facei]];
const label ownIndex = offsets[own] + nFacesPerCell[own]++;
const label neiIndex = offsets[nei] + nFacesPerCell[nei]++;
m[ownIndex] = globalAgglom.toGlobal(nei);
w[ownIndex] = mag(mesh.faceAreas()[facei]);
m[neiIndex] = globalAgglom.toGlobal(own);
w[ownIndex] = mag(mesh.faceAreas()[facei]);
}
The fact that `w[ownIndex]` is specified twice (not `w[neiIndex]`) looks weird, but seems to have been in there forever.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3023object registry filtered objects uses derived name2023-11-07T21:01:55ZMark OLESENobject registry filtered objects uses derived nameAffects the implementation of csorted etc.
It checks the name from the cast pointer
```
matchName(ptr->name())
```
instead of from the object pointer
```
matchName(obj->name())
```
This only seems to affect finite-area directly, since t...Affects the implementation of csorted etc.
It checks the name from the cast pointer
```
matchName(ptr->name())
```
instead of from the object pointer
```
matchName(obj->name())
```
This only seems to affect finite-area directly, since the cast pointer will have "region0" as its name, whereas the object is actually registered as "faMesh". Cross-ref EP2297
Regression introduced with 95e2a2e887d but was not exposed until 129b738136f (develop branch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2796Pstream listCombineGather etc blocks on INTELMPI with PMI-2 (slurm)2023-11-07T10:32:23ZMark OLESENPstream listCombineGather etc blocks on INTELMPI with PMI-2 (slurm)- reported by @Prashant, currently under investigation.- reported by @Prashant, currently under investigation.https://develop.openfoam.com/Development/openfoam/-/issues/2153Tutorial - irregularMultiDirection2023-11-06T18:33:35ZSaeed Barzegar ValikchaliTutorial - irregularMultiDirectionFor any directional wave generation (i.e. not perpendicular to the generation line), the number of paddles in the generation line must be greater than 1. However, in the irregularMultiDirection tutorial, nPaddle=1, which would not give p...For any directional wave generation (i.e. not perpendicular to the generation line), the number of paddles in the generation line must be greater than 1. However, in the irregularMultiDirection tutorial, nPaddle=1, which would not give proper results. I have attached an example (irregularMultiDirection_Tutorial_Extended_3D) of that tutorial with an extended domain (to have a better observation of the wave propagation) and nPaddle=50. Please note that nPaddle can be defined in constant/waveProperties. Please run this case with nPaddle=1 and nPaddle=50 for comparison.[irregularMultiDirection_Tutorial_Extended_3D.zip](/uploads/39cbea3417daa2d6e6d66777cfbc95c9/irregularMultiDirection_Tutorial_Extended_3D.zip)https://develop.openfoam.com/Development/openfoam/-/issues/3015label 64 compilation failing2023-11-06T12:03:54ZPawan Ghildiyallabel 64 compilation failingHello,
While compiling the branch update-redistributePar with 64 label size, I encountered following error messagess
`M_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof...Hello,
While compiling the branch update-redistributePar with 64 label size, I encountered following error messagess
`M_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -I/home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/build/linux64Gcc85DPInt64Opt/src/OpenFOAM -DHAVE_LIBZ -iquote. -IlnInclude -I/home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/src/OpenFOAM/lnInclude -I/home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/src/OSspecific/POSIX/lnInclude -fPIC -c primitives/chars/lists/charList.C -o /home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/build/linux64Gcc85DPInt64Opt/src/OpenFOAM/primitives/chars/lists/charList.o
global/fileOperations/fileOperation/fileOperation.C:83:47: error: conflicting declaration 'Foam::label Foam::fileOperation::nProcsFilter_'
Foam::label Foam::fileOperation::nProcsFilter_(-1);
^
In file included from global/fileOperations/fileOperation/fileOperation.C:29:
global/fileOperations/fileOperation/fileOperation.H:158:20: note: previous declaration as 'int Foam::fileOperation::nProcsFilter_'
static int nProcsFilter_;
^~~~~~~~~~~~~`v2306Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2820foamMeshToFluent delivers meshes that are non-conformal with specifications a...2023-11-03T16:28:56ZDavefoamMeshToFluent delivers meshes that are non-conformal with specifications and that are incompatible with Fluent utility tmerge### Summary
When a mesh is exported from OpenFoam in Fluent format using `foamMeshToFluent`, a msh is generated that consists of several sections with a defined structure, see e.g. [here](http://www.eureka.im/302.html) or [here](https:/...### Summary
When a mesh is exported from OpenFoam in Fluent format using `foamMeshToFluent`, a msh is generated that consists of several sections with a defined structure, see e.g. [here](http://www.eureka.im/302.html) or [here](https://romeo.univ-reims.fr/documents/fluent/tgrid/ug/appb.pdf).
The exported mesh can be read into Ansys Fluent and ICEM without any problems. However, if the officially shipped Ansys utility `tmerge` is used for merging two or more msh files into one, the merged mesh shows artifacts when loaded into Fluent. The same occurs, when `tmerge` is only given one msh file and writes it to new msh file that should in theory have an identical content as the input file (unless of some differences in formatting). However, this is not the case. `tmerge` writes a wrong number of points into the point section header:
| original msh file | after `tmerge` |
| ------ | ------ |
| ![grafik](/uploads/e6f7126197aab55fd13eff817c054d25/grafik.png) | ![grafik](/uploads/0f8b15f4cb5ce3ac30df5d1e80dd615b/grafik.png) |
As a consequence, Fluent does not import all nodes of the new msh file but only a few, while all other nodes fall down to (0,0,0), which creates the artifacts after import. After some trial and error, the reason seems to be the id that `foamMeshToFluent` writes in the node header. While Ansys assigns id 3 per default (e.g. when exporting a mesh from Ansys Meshing to msh file), `foamMeshToFluent`writes id 1. This interferes with id 1, which is also used for the cell header. When manually changing the node header id from 1 to 3, `tmerge` does the correct job and all artifacts are gone.
### Steps to reproduce
1. Export an arbitrary blockMesh with `foamMeshToFluent`:
2. Load this msh file in Fluent and display mesh -> everything looks fine.
3. Take the same msh file, let it run through `tmerge` and write it to a new msh file:
Windows: `"C:\Program Files\ANSYS Inc\v231\fluent\fluent23.1.0\utility\tmerge\win64\tm3d.exe" case.msh case_new.msh`
Linux: `./mnt/software/ansys_inc/v231/fluent/fluent23.1.0/utility/tmerge/lnamd64/tmerge_3d case.msh case_new.msh`
4. Load this new msh file in Fluent and display mesh -> mesh has artifacts.
### What is the current *bug* behaviour?
`foamMeshToFluent` defines the node section in a msh file under id 1 (see last line):
```
(0 "FOAM to Fluent Mesh File")
(0 "Dimension:")
(2 3)
(0 "Grid dimensions:")
(10 (0 1 163c 0 3))
(12 (0 1 efa 0 0))
(13 (0 1 339c 0 0))
(10 (1 1 163c 1 3)
...
```
### What is the expected *correct* behavior?
Ansys always defined the node section in a msh file with id 3 as per default (see last line):
```
(0 grid written by ANSYS Meshing
nodes: (10 (id start end type) (x y z ...))
faces: (13 (id start end type elemType)
(v-0 v-1 .. v-n right-cell left-cell ...))
cells: (12 (id start end type elemtype))
parent-face: (59 (start end parent child) (nchilds child0 child1 ...))
)
(2 3)
(10 (0 1 c 0))
(13 (0 1 b 0))
(12 (0 1 2 0))
(10 (3 1 c 1 3)(
...
```
### Relevant logs and/or images
![grafik](/uploads/83086801a4a1452f1e2a2078e1ee18f3/grafik.png)
### Environment information
- OpenFOAM version : v2212, 10 and all previous
- Operating system : Ubuntu 2204 LTS @ WSL2.0 and all other systems
### Possible fixes
In `/usr/lib/openfoam/openfoam2212/applications/utilities/mesh/conversion/foamMeshToFluent/fluentFvMesh.C`, the first `1` after `(10 (` in line 104 should simply be replaced by a `3` (see last line):
```
// Writing points
fluentMeshFile
<< "(10 (3 1 ";
fluentMeshFile.setf(ios::hex, ios::basefield);
fluentMeshFile
<< nPoints() << " 1 3)"
<< std::endl << "(" << std::endl;
```
There will be no negative consequences/ interference as `foamMeshToFluent` specifies
- the internal faces under id 2 ff.: `<< "(13 (2 1 ..."` (ll. 135 f.),
- boundary faces starting from id 10 (hex a): `<< "(13 (" << patchi + 10 << ...` (ll. 71 f.) and
- cells under id 1: `<< "(12 (1 1 " << ...` (ll. 221 f.)
Hence, ids 3 to 9 are unused and may be used for node header id. To be consistent with Ansys, I would choose id 3 as suggested above.v2312Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3004face class have 'find(const edge&)' which returns the index of the edge on th...2023-11-01T13:15:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comface class have 'find(const edge&)' which returns the index of the edge on the face### Functionality to add/problem to solve
Extend face class with searching for an edge. Is basically already in the edgeDirection routine.### Functionality to add/problem to solve
Extend face class with searching for an edge. Is basically already in the edgeDirection routine.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2648wallDist is called every iteration when using vanDriest delta function in tur...2023-10-30T15:50:48ZFlavio GaleazzowallDist is called every iteration when using vanDriest delta function in turbulenceProperties<!--
*** 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 -->
The function `wallDist` is called every iteration when using `vanDriest` delta function in `turbulenceProperties`, even if explicitly setting the parameters in fvSchemes, e.g.
```
wallDist
{
method meshWave;
// Optional entry enabling the calculation
// of the normal-to-wall field
nRequired true;
// Optional entry delaying wall distance update to every n steps
// Default is 1 (update every step)
updateInterval 100000;
}
```
This behavior hurts the performance especially in large-scale simulations, using a large number of cores. In some tests we have conducted, almost 50% of the computing time is spent in the `meshWave` function when using more than 1500 cores.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
It happens when `vanDriest` is selected as `delta` function in `turbulenceProperties`.
### 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
-->
Tutorial case: tutorials/incompressible/pimpleFoam/LES/vortexShed
The calculation of `wallDist` in every time step can be visualized using the corresponding debug switch in `controlDict`
```
DebugSwitches
{
FaceCellWave 1;
}
```
### What is the current *bug* behaviour?
<!-- What actually happens -->
The `wallDist` is called every time step, regardless of the parameters set in the `fvSchemes`, e.g.
```
wallDist
{
method meshWave;
nRequired true;
updateInterval 1000000;
}
```
The behavior does not change if setting `nRequired` to true or false, or changing the `updateInterval` to 0, 5 or 1000000
### What is the expected *correct* behavior?
<!-- What you should see instead -->
I would expect that when setting `updateInterval` to a value greater than 1, that the `wallDist` calculation would be performed only in this interval.
### 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 : CentOS/Rocky 8
- Hardware info : AMD EPYC
- Compiler : GCC 10.2
### 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
-->v2306Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3001problem installing openfoam on fedora 382023-10-29T21:36:14ZFady Azerproblem installing openfoam on fedora 38I am a student doing my masters and I was introduced to openfoam. I am new to linux and to openfoam.I have fedora 38 since a couple of months( I didn't like Ubuntu)
I tried running the commands mentioned on the website to download openf...I am a student doing my masters and I was introduced to openfoam. I am new to linux and to openfoam.I have fedora 38 since a couple of months( I didn't like Ubuntu)
I tried running the commands mentioned on the website to download openfoam for redhat derivatives like fedora, without success, I was asked by the support team to open an issue here, I hope it is the right place.
I saved the outputs in the attached log file. I tried to separate the outputs of different commands with line of "%" symbols for better readability.
If there is any solution that doesn't include running a VM or a container or changing the OS, I will be very grateful
[OF2306_log.txt](/uploads/14cb38ad6466e2af1f60db3992abefb6/OF2306_log.txt)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2784Updates for missing library linkage (mingw, gold etc)2023-10-28T14:03:15ZMark OLESENUpdates for missing library linkage (mingw, gold etc)v2306Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2961OpenFOAM v2306 gives YY_BUF_SIZE declare in scope error2023-10-28T14:01:38ZAziz ÖğütlüOpenFOAM v2306 gives YY_BUF_SIZE declare in scope errorI'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)I'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)