Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-11-17T19:47:10Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2166fallback behaviour for distanceSurface proximity regions2021-11-17T19:47:10ZMark OLESENfallback behaviour for distanceSurface proximity regionsIn some cases filtering on proximity regions can result in no faces at all (eg, when the cut region is not closed?).
Could thus make sense to revert to filtering on proximity faces only for those cases.
cross-ref: EP1631In some cases filtering on proximity regions can result in no faces at all (eg, when the cut region is not closed?).
Could thus make sense to revert to filtering on proximity faces only for those cases.
cross-ref: EP1631https://develop.openfoam.com/Development/openfoam/-/issues/2165gmshToFoam failure2021-07-22T19:06:48ZOliver OxtobygmshToFoam failure<!--
*** 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 -->
gmshToFoam is unable to convert the example meshes in the source tree. This worked fine in v2012.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run Allrun in the attached minimal example. This is a example mesh from the source tree.
### 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
-->
[gmshToFoamBug.tgz](/uploads/43a7c21abea9a3a2859a31f96154ace3/gmshToFoamBug.tgz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
gmshToFoam exits with the error:
```
Wrong token type - expected word, found on line 0: variable "$MeshFormat"
file: input at line 0.
From Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::word&)
in file primitives/strings/word/wordIO.C at line 70.
FOAM exiting
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
(No error)
<!--
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|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : ubuntu
- Hardware info :
- Compiler : (OpenCFD binary package)
### 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
-->
In [gmshToFoam.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/mesh/conversion/gmshToFoam/gmshToFoam.C), replacing all occurrences of
```word tag(lineStr);```
with
```string tag(token(tagStr).stringToken());```
seems to do the trick.https://develop.openfoam.com/Development/openfoam/-/issues/2164Simulation hangs when sampling sets of type face.2021-12-20T12:18:01ZTom LauriksSimulation hangs when sampling sets of type face.I have an LES of a half open channel (empty atmospheric boundary layer). The domain is a cuboid. The mesh is built with blockMesh, without grading, and the cells are nearly uniform. I use the pimpleFoam solver. I'm using openfoam v2012. ...I have an LES of a half open channel (empty atmospheric boundary layer). The domain is a cuboid. The mesh is built with blockMesh, without grading, and the cells are nearly uniform. I use the pimpleFoam solver. I'm using openfoam v2012.
I'm trying to sample on a line in my domain, running from one side to the opposing side, somewhere though the middle of my domain and parallel with one of the coordinate axes. I'm using sets from libsampling.so. I'm trying to use the type face, which should sample at intersections of the specified line and mesh cell faces. As my mesh cells are evenly spaced, this is very convenient.
I've noticed that my simulation sometimes hangs and sometimes not. By hanging I mean, that the log file from calling pimpleFoam > log is created, and that the simulation doesn't stop, but simply gets stuck at a certain line in the log file. E.g. during the last simulation where I had this problem, the simulation stopped at the line containing "outlet":
```
Creating finite volume options from "constant/fvOptions"
No finite volume options present
Courant Number mean: 0.001365 max: 0.0013832
fieldAverage fieldAverage1:
Restarting averaging for fields:
U: starting averaging at time 0
turbulenceFields turbulenceFields1: storing fields:
turbulenceProperties:R
Reading set description:
buildings
inlet
outlet
```
I've furthermore noticed that when I adjust one of the coordinates of the line, then the simulation sometimes doesn't hang anymore and sometimes it still hangs.
This seems like a bug in the sampling application.https://develop.openfoam.com/Development/openfoam/-/issues/2163BUG: boundary data sampling is incorrect when no fields are sampled2021-07-20T15:13:09ZPrashant SonakarBUG: boundary data sampling is incorrect when no fields are sampledCross reference: EP#1606
---------------
When no fields are sampled, the boundary data exports points of faces instead of face center.Cross reference: EP#1606
---------------
When no fields are sampled, the boundary data exports points of faces instead of face center.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2162error in rotatingFanInRoom tutorial for pimpleFoam2021-08-04T13:32:32ZMatej Formanerror in rotatingFanInRoom tutorial for pimpleFoamSmall bug in the `incompressible/pimpleFoam/RAS/rotatingFanInRoom` tutorial (version 2106)
`snappyHexMeshDict` needs change in locationInMesh location. The original location points into a face.
Suggested fix is:
`
locationInMesh (...Small bug in the `incompressible/pimpleFoam/RAS/rotatingFanInRoom` tutorial (version 2106)
`snappyHexMeshDict` needs change in locationInMesh location. The original location points into a face.
Suggested fix is:
`
locationInMesh (0.1001 0.001 0.0101);
`
in `<system>/snappyHexMeshDict`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2161Potential wrong behavior of particles in MPPICInterFoam when using MRF2021-12-17T14:59:00ZRiccardo RossiPotential wrong behavior of particles in MPPICInterFoam when using MRFI'm opening this ticket as a follow up to #1941 after running the same test with MPPICInterFoam as requested by @Sergio.
As you can see from the two video attached, the standard MPPICInterFoam solver behaves essentially in the same way ...I'm opening this ticket as a follow up to #1941 after running the same test with MPPICInterFoam as requested by @Sergio.
As you can see from the two video attached, the standard MPPICInterFoam solver behaves essentially in the same way as my custom solver, i.e. water phase is convected by relative velocity in the MRF region of the standard mixerVessel tutorial used here whereas the particles are not.
If one switches to drag force given by relative velocity in the MRF region as I did in my modified custom solver, then the particles behaves correctly when looking at the reference AMI based simulation, where the MRF region is replaced by the actually moving mesh.
Looking forward to hearing your thoughts.
[mixerVesselWater.avi](/uploads/af4eb236f4797d81f9ba941b91bd1587/mixerVesselWater.avi)
[mixerVesselParticles.wmv](/uploads/5a00e673f191b794fe67d1d0c6cca1b0/mixerVesselParticles.wmv)https://develop.openfoam.com/Development/openfoam/-/issues/2160wordIO has problem with string input2021-07-22T19:00:00ZMark OLESENwordIO has problem with string inputIn 2106 changed the lazy input conversion of string to word to test (tok.isQuotedString()) - this was done to avoid verbatim strings and expression strings from being considered. Should also allow isVariable() too.In 2106 changed the lazy input conversion of string to word to test (tok.isQuotedString()) - this was done to avoid verbatim strings and expression strings from being considered. Should also allow isVariable() too.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2159transform / scale support for blockMesh2021-07-28T16:26:45ZMark OLESENtransform / scale support for blockMesh- can be useful to specify an offset/rotation for repositioning a blockMesh (in addition to scale)
- also need to fix scaling/location of write-vtk, write-obj output. They currently do not account for scaling.
TBD: support separate x/y...- can be useful to specify an offset/rotation for repositioning a blockMesh (in addition to scale)
- also need to fix scaling/location of write-vtk, write-obj output. They currently do not account for scaling.
TBD: support separate x/y/z stretch factors.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2158potential blocking with overlapping communicators2021-12-16T13:47:50ZMark OLESENpotential blocking with overlapping communicators- noticed during mapped-patch handling- noticed during mapped-patch handlingMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2157momentum FO does not calculate boundary values2021-11-01T12:28:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commomentum FO does not calculate boundary values<!--
*** 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 -->
momentum FO does not calculate boundary values for angularVelocity
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run momentum FO on any case with e.g. swirl inlet velocity field. Check momentum:angularVelocity components.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Values on bcs are zero.
### What is the expected *correct* behavior?
Values on bcs should reflect the actual velocity.
<!-- 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 : v2106
-->
- OpenFOAM version : v2106
### Possible fixes
in momentum.C : it only calculates
`angularVel.primitiveFieldRef()
<!--
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/2156waveMethod called from inverseDistanceCellCellStencil returns error for empty...2021-11-19T15:20:54ZLouiswaveMethod called from inverseDistanceCellCellStencil returns error for empty source processors
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
...
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
changedFaces,
changedFacesInfo,
faceData,
cellData,
src.globalData().nTotalCells(), // max iterations
td
);
which will return an error when src.globalData().nTotalCells() is 0.
A solution is to add 1 (works for me) or maybe, more logical, make a max(1,src.globalData().nTotalCells())
### What is the current *bug* behaviour?
returns error
> Maximum number of iterations reached. Increase maxIter.
### What is the expected *correct* behavior?
overset runs
### Environment information
I think hierarchical is particularly sensible to this issue.
### Possible fixes
mentioned above
PS: I'm not sure I can get this error for the "standard" code, as I haven't tested if empty src is possible. I'm using a modified B-box inverseDistance scheme...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2154Directional waves from multi boundaries (src/../waveModel.C)2021-10-15T08:33:42ZSaeed Barzegar ValikchaliDirectional waves from multi boundaries (src/../waveModel.C)When you have two wave generation lines (e.g., one line parallel to the x-axis, and the other one parallel to the y-axis), the simulation crashes even with regular waves. After trying different cases and digging up every single line in t...When you have two wave generation lines (e.g., one line parallel to the x-axis, and the other one parallel to the y-axis), the simulation crashes even with regular waves. After trying different cases and digging up every single line in the wave codes and my model setup, I noticed that something is wrong when I wanted to generate waves perpendicular/directional to the y-axis although everything was fine when it was perpendicular/directional to the x-axis. The piece of information on my log file (e.g. Transformation from local to the global system: (-0 1 -0 -1 -0 -0 -0 -0 1)) gave me the idea that my model was generating waves going in the opposite direction (i.e. going outwards instead of coming inside the domain). This issue, I believe, relies on a typo in the waveModel.C code (src/waveModels/waveModel/waveModel.C, lines 67:69). These three lines are:
// Rotation from global<->local about global origin
Rlg_ = tensor(x, y, z);
Rgl_ = Rlg_.T();
Which should be changed to below in order to fix the problem.
// Rotation from global<->local about global origin
Rgl_ = tensor(x, y, z);
Rlg_ = Rgl_.T();
I have attached an example with two generation lines for the propagation of a directional wave (i.e. 30 deg) which does not work (crashes) with the original code but workes perfectly with the suggested modification. Please note that I have already tested this example with other configurations of incoming waves from different boundaries and it works correctly (i.e. this modification is not limited to this example).
[DirectionalWave_Example.zip](/uploads/de751bab2fd519ccf34aa140d40bbc9e/DirectionalWave_Example.zip)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/2152BUG: makeFaMesh fails with the random decomposition method2021-11-08T18:29:43ZKutalmış BerçinBUG: makeFaMesh fails with the random decomposition method### Summary
`makeFaMesh` fails when the `random` decomposition method is used.
### Steps to reproduce
- cd `$FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder`
- change `method simple;` to `method random;` in `system/decomp...### Summary
`makeFaMesh` fails when the `random` decomposition method is used.
### Steps to reproduce
- cd `$FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder`
- change `method simple;` to `method random;` in `system/decomposeParDict`
- `./Allrun-parallel`
### What is the current *bug* behaviour?
Floating point exception.
### Environment information
```
base1 = develop
api = 2106
patch = 0
HEAD = 70c697fdcb
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2151decomposePar -fileHandler uncollated2021-08-06T11:48:50ZLouisdecomposePar -fileHandler uncollated@mark [suggested](https://www.cfd-online.com/Forums/openfoam-pre-processing/237172-decomposepar-latesttime-fields-filehandler-uncollated.html#post807551) I test with v2106 and open an issue, so here it is.
### Summary
decomposePar doe...@mark [suggested](https://www.cfd-online.com/Forums/openfoam-pre-processing/237172-decomposepar-latesttime-fields-filehandler-uncollated.html#post807551) I test with v2106 and open an issue, so here it is.
### Summary
decomposePar does not respect the uncollated filehandler request
### Steps to reproduce
as an example, I've tested it with the _ellipsekkLOmega_ tutorial:
run the tutorial, but add this at the end of the controlDict:
```
OptimisationSwitches
{
fileHandler collated;
maxThreadFileBufferSize 1e9;
}
```
then run `decomposePar -fileHandler uncollated`
it will still decompose into a single directory, namely processors8, as for collated
### Environment information
- OpenFOAM version : v2106
### Possible fixesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2150Feature: CFL number2021-07-06T11:17:28ZPrashant SonakarFeature: CFL numberIt is useful to analyze CFL number for compressible cases which takes acoustic speed into account.
@andyIt is useful to analyze CFL number for compressible cases which takes acoustic speed into account.
@andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2149phiGas is not updated in reactingOneDim pyrolysis model2021-07-08T20:55:38ZCaelan LapointephiGas is not updated in reactingOneDim pyrolysis modelIn the reactingOneDim pyrolysis model the update of gas fluxes (via the updatePhiGas() member function) has been commented out, with the following description: "Commented out as the sensible gas energy is included in energy eq." I think ...In the reactingOneDim pyrolysis model the update of gas fluxes (via the updatePhiGas() member function) has been commented out, with the following description: "Commented out as the sensible gas energy is included in energy eq." I think the goal was to remove the update of phiHsGas and its use in the energy equation. However, this also removes the update to phiGas which is used for mapping to phi in a gaseous domain. The fireFoam oppositeBurningPanels tutorial, for example, thus does not work as intended (or as it used to) -- this can be observed by running the tutorial and then examining velocity on the coupled patches, which remains zero even when the surface is charring.https://develop.openfoam.com/Development/openfoam/-/issues/2148Stochastic dispersion model not working since OpenFOAM 20062021-08-13T19:07:15ZSandeepStochastic dispersion model not working since OpenFOAM 2006This dispersion model was available in previous versions, we implemented it in Visual-CFD and now suddenly its not available in OpenFOAM
Please add it to the compiling list as with a library it works.
__Selecting distribution model un...This dispersion model was available in previous versions, we implemented it in Visual-CFD and now suddenly its not available in OpenFOAM
Please add it to the compiling list as with a library it works.
__Selecting distribution model uniform
Selecting dispersion model stochasticDispersionRAS
[1]
--> FOAM FATAL IO ERROR:
--> FOAM FATAL IO ERROR:
[0]
Unknown dispersionModel type stochasticDispersionRAS
Valid dispersionModel types :
1(none)
Unknown dispersionModel type stochasticDispersionRAS__Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2147Compilation - linker issue2022-06-24T13:19:22ZVojtech BetakCompilation - linker issueDear developers,
I observe some compilation - linker issue when I am compiling OpenFOAM-v2106 on openSUSE Tumbelweed. The src directory is compiled without significant problems but the applications directory is not possible to compile a...Dear developers,
I observe some compilation - linker issue when I am compiling OpenFOAM-v2106 on openSUSE Tumbelweed. The src directory is compiled without significant problems but the applications directory is not possible to compile and end with the following error message
```
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libcompressibleTurbulenceModels.so: undefined reference to `Foam::fv::convectionScheme<Foam::SymmTensor<double> >::IstreamConstructorTablePtr_[abi:cxx11]'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so: undefined reference to `Foam::pointPatchField<Foam::SphericalTensor<double> >::dictionaryConstructorTablePtr_[abi:cxx11]'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libreactionThermophysicalModels.so: undefined reference to `Foam::Reaction<Foam::polynomialTransport<Foam::species::thermo<Foam::hPolynomialThermo<Foam::icoPolynomial<Foam::specie, 8>, 8>, Foam::sensibleEnthalpy>, 8> >::dictionaryConstructorTablePtr_[abi:cxx11]'
```
To verify this issue, I have tried to compile an older version of OpenFOAM(OpenFOAM-v2012) and this compilation was successful
Thank a lot
With regards
Vojtech BetakMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2146Compilation of meshTools/searchableSurfaces/searchableSphere/searchableSphere...2021-07-23T09:39:23ZPhilip CardiffCompilation of meshTools/searchableSurfaces/searchableSphere/searchableSphere.C needs "#include <array>" with clang 12.0.5 (macOS)<!--
*** 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 -->
On OpenFOAM-v2012, ${FOAM_SRC}/meshTools/searchableSurfaces/searchableSphere/searchableSphere.C requires that the "#include \<array\>" header is added to the top of the file when compiling with clang 12.0.5 (macOS 11.4, arm).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Try compile OpenFOAM-v2012 on a case-sensitive partition on macOS 11.4 (arm) using Clang, Apple clang version 12.0.5 (clang-1205.0.22.9).
### 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 -->
Compilation error.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It compiles :)
### 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 : v2012
- Operating system : macOS 11.4 (arm)
- Hardware info : Apple m1 arm CPU
- Compiler : Apple clang version 12.0.5 (clang-1205.0.22.9), with target arm64-apple-darwin20.5.0
### 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
-->
Line 528 in searchableSphere.C causes the error:
```
std::array<uint8_t, 3> idx{0, 1, 2};
```
A quick fix is to add the array header at the top of the file:
```
#include "searchableSphere.H"
#include "addToRunTimeSelectionTable.H"
#include <array>
```