Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-09-08T07:15:18Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2573throw FatalIOerror instead of FatalError in timeActivateFileUpdate2022-09-08T07:15:18ZMark OLESENthrow FatalIOerror instead of FatalError in timeActivateFileUpdateIn timeActivateFileUpdate, the filechecks emit a FatalError if any of the source files are missing on startup. By default this throw/catch is downgraded to a warning unless the user specifies a different error handling.
However, since th...In timeActivateFileUpdate, the filechecks emit a FatalError if any of the source files are missing on startup. By default this throw/catch is downgraded to a warning unless the user specifies a different error handling.
However, since this functionObject is intended as a control mechanism (similar to system/controlDict, for example), it makes more sense for a missing file to be really fatal. Elevating to an IOerror will do this for the default error handling.
cross-ref EP1968Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2572Error while building OpenFOAM from source2022-12-23T16:54:19ZAshish PathakError while building OpenFOAM from source I am trying to install openfoam from source on RHEL 8.3. As I do not have access to root privileges, I installed the required packages such as bison and flex from source as well. Before invoking ./Allwmake -s -l, I added the path to fle... I am trying to install openfoam from source on RHEL 8.3. As I do not have access to root privileges, I installed the required packages such as bison and flex from source as well. Before invoking ./Allwmake -s -l, I added the path to flex and bison binaries to `$PATH` environment variable and path to flex lib to `$LD_LIBRARY_PATH`. I also populated `$FOAM_EXTRA_CFLAGS` and `$FOAM_EXTRA_CXX_FLAGS` to "-I/\<path to flex include\>" and `$FOAM_EXTRA_LDFLAGS` to "-L/\<path to flex lib\> -lfl". Now when I invoke ./Allwmake -s -l, the installation fails (while building applications) with a message that says: "flex-2.6.4-install/lib/libfl.so.2: undefined reference to `yylex`". How to fix this problem to do a successful openfoam installation from source?https://develop.openfoam.com/Development/openfoam/-/issues/2571refPtr does not do assignment from autoPtr2022-10-26T07:19:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrefPtr does not do assignment from autoPtr### Functionality to add/problem to solve
Assign autoPtr to a refPtr is not defined. Following code produces a sigsegv:
```
autoPtr<labelList> ptr(new labelList(1, 1234));
refPtr<labelList> ref;
//- Does not wo...### Functionality to add/problem to solve
Assign autoPtr to a refPtr is not defined. Following code produces a sigsegv:
```
autoPtr<labelList> ptr(new labelList(1, 1234));
refPtr<labelList> ref;
//- Does not work
ref = ptr;
////- Works
//ref = refPtr<labelList>(std::move(ptr));
DebugVar(ptr.valid());
DebugVar(ref.valid());
DebugVar(ref());
```
### Proposal
Have (stealing?) assignment from autoPtrMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2570foamDictionary does not allow wildcards as key2022-08-22T09:58:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamDictionary does not allow wildcards as key### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
...### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
Have each entry expanded into multiple keys by default. Optionally disable with `-literalRE` similar to `changeDictionary` so you could add a wildcard entry to a dictionary.
You could have inbetween where we expand some wildcards but not others but that might be overkill.
### What does success look like, and how can we measure that?
See if we can do above replacement.
### Links / references
### Fundinghttps://develop.openfoam.com/Development/openfoam/-/issues/2569native MPI reduce not triggered2022-10-26T07:19:41ZMark OLESENnative MPI reduce not triggeredReported by @Mattijs
in symmetryPlanePolyPatch.C there is a
```
if (returnReduce(size(), sumOp<label>()))
{
```
This does not seem to trigger the native Foam::reduce with `sumOp<label>` in mpi/UPstreamReduce.C ? I was checking all inv...Reported by @Mattijs
in symmetryPlanePolyPatch.C there is a
```
if (returnReduce(size(), sumOp<label>()))
{
```
This does not seem to trigger the native Foam::reduce with `sumOp<label>` in mpi/UPstreamReduce.C ? I was checking all invocations of MPI_Send/MPI_Recv.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2568wrong type in valueAverageBaseTemplates2022-09-07T14:33:08ZMarkus Towarawrong type in valueAverageBaseTemplatesI think [this](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/functionObjects/valueAverageBase/valueAverageBaseTemplates.C#L121) should be declared as Type2:
```Type valueOld(pTraits<Type2>::zero);```
...I think [this](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/functionObjects/valueAverageBase/valueAverageBaseTemplates.C#L121) should be declared as Type2:
```Type valueOld(pTraits<Type2>::zero);```
As Type can be instantiated as label, there might be unintended truncation going on.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2567Wrong Viscous force when using "density variable" in turbulenceProperties2022-08-19T12:43:12ZMyo Zin AungWrong Viscous force when using "density variable" in turbulencePropertiesA new "density variable" feature in turbulenceProperties was introduced in v2012. ([Release Notes](https://www.openfoam.com/news/main-news/openfoam-v20-12/solver-and-physics))
When I was testing the DTCHullMoving tutorial with "kEpsilon"...A new "density variable" feature in turbulenceProperties was introduced in v2012. ([Release Notes](https://www.openfoam.com/news/main-news/openfoam-v20-12/solver-and-physics))
When I was testing the DTCHullMoving tutorial with "kEpsilon" and "realizableKEpsilon" models and "density variable" in the constant/turbulenceProperites, the viscous component of the forces are too much underpredicted (over 7 times samller compared to the original settings). But the pressure component is almost the same as original result. The results are comparable with the original tutorial when running without "density variable" option. I believe there is a problem with that new feature.https://develop.openfoam.com/Development/openfoam/-/issues/2566BUG: incorrect order for output scaling (transformPoints, ...)2022-08-18T11:57:47ZMark OLESENBUG: incorrect order for output scaling (transformPoints, ...)Noticed while working on #2565, the output write scaling should be applied *after* undoing the effects of the specified rotation centre. Currently the scaling applied before undoing the rotation centre, which means the resulting output w...Noticed while working on #2565, the output write scaling should be applied *after* undoing the effects of the specified rotation centre. Currently the scaling applied before undoing the rotation centre, which means the resulting output would be entirely wrong if rotation centre *and* output scaling are combined!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2565extend surface writer transforms to include centre of rotation specification2022-10-04T14:34:21ZMark OLESENextend surface writer transforms to include centre of rotation specificationTopic raised in EP1961 - it can be useful to specify the centre of rotation instead of a local coordinate system origin/rotation for handling similar to transformPoints/surfaceTransformPoints.
As part of the change, it would be reasonab...Topic raised in EP1961 - it can be useful to specify the centre of rotation instead of a local coordinate system origin/rotation for handling similar to transformPoints/surfaceTransformPoints.
As part of the change, it would be reasonable to accept _-centre_ or `-rotation-centre` etc for the command-line options, since the use of `-origin` can be ambiguous. In these cases, would still accept `-origin` as aliased option.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2564Proposal to change optimization option of the default Fujitsu ARM64 compiler2022-11-17T07:27:58ZAkira AzamiProposal to change optimization option of the default Fujitsu ARM64 compiler### Functionality to add/problem to solve
I'm trying to install by spack and run OpenFOAM on Supercomputer Fugaku by Fujitsu compiler.
I would like to request a change in the default level of optimization, as I have experienced
problems...### Functionality to add/problem to solve
I'm trying to install by spack and run OpenFOAM on Supercomputer Fugaku by Fujitsu compiler.
I would like to request a change in the default level of optimization, as I have experienced
problems with side effects of optimization in Fugaku when running snappyHexMesh.
(User reported snappyHexMesh going to endless loop.)
Especially "-ffp-contract=fast" was particularly impactful.
I would like to see the level lowered to the safer side.
wmake/rules/linuxARM64Fujitsu/c++Opt
c++OPT = -ffp-contract=fast -ffast-math -O3 -funsafe-math-optimizations
-->
c++OPT = -O3
This may be related to this issue.
https://develop.openfoam.com/Development/openfoam/-/issues/2537
### Target audience
Fugaku Users
### Proposal
I suggest lowering the optimization level.
I have confirmed that it can be done with the -O3 option as following version.
OpenFOAM version: v2012, v2106, v2206
Fujitsu compiler version: 1.2.35Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2563rotatingCylinders tutorial is missing2023-01-13T00:16:16ZHasan CelikrotatingCylinders tutorial is missingHello,
The link of rotatingCylinders tutorial is broken, or the tutorial is missing, somehow. The link for `$FOAM_TUTORIALS/incompressible/simpleFoam/rotatingCylinders` on OpenFOAM User Guide rotatingCylinders tutorial [page](https://ww...Hello,
The link of rotatingCylinders tutorial is broken, or the tutorial is missing, somehow. The link for `$FOAM_TUTORIALS/incompressible/simpleFoam/rotatingCylinders` on OpenFOAM User Guide rotatingCylinders tutorial [page](https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-rotating-cylinders-2d.html) is not working and says:
`"tutorials/incompressible/simpleFoam/rotatingCylinders" did not exist on "master"`https://develop.openfoam.com/Development/openfoam/-/issues/2562Implementation errors in createBoxTurb utility2022-12-23T15:51:27ZMario HermesImplementation errors in createBoxTurb utilityDear ESI-OpenFOAM development team,
I use the OpenFOAM version 2112 and stumbled upon two implementation errors in the utility "createBoxTurb" which is used to initialize a homogeneous isotropic turbulent flow field based on the method...Dear ESI-OpenFOAM development team,
I use the OpenFOAM version 2112 and stumbled upon two implementation errors in the utility "createBoxTurb" which is used to initialize a homogeneous isotropic turbulent flow field based on the method published by Saad et al.
The first error is to be found here: /applications/utilities/preProcessing/createBoxTurb.C on the lines 63 and 64. In these lines, a random sample point on a unit sphere is created using spherical coordinates (s. Figure below).
![Bug_Report_image1](/uploads/0b97f48695035e16095c28681cf02e5d/Bug_Report_image1.PNG)
However, the spherical coordinates provided here are wrong since they say
vector = (sin(thetam * cos(phim)), sin(thetam * sin(phim)), cos(thetam))
However, the correct spherical coordinates should be (also according to the original publication of Saad et al., equation 10):
vector = (sin(theta)*cos(phim), sin(thetam)*sin(phim), cos(thetam))
So it seems the brackets have been accidentally put into the wrong positions here.
The second error is to be found in the same file on line 155. Here, the vector sigmaHatm is to be normalized (s. Figure below)
![Bug_Report_image2](/uploads/260fdc8d67a94017040470f60868da47/Bug_Report_image2.PNG)
Hence, the vector sigmaHatm is created via the equation:
sigmaHatm = zetaHatm^kappaTildem/(mag(kappaTildem))
However, the correct normalization equation also provided by Saad et al. in equation 9 of the original publication would be:
sigmaHatm = zetaHatm^kappaTildem/(mag(zetaHatm^kappaTildem))
It would be great if the errors could be removed in a future release.
Furthermore, I have a suggestion for the further development of this utility. The method published by Saad et al. is specifically formulated for a staggered grid arrangement of the variables in the mesh in order to meet the the zero divergence criterion in a finite difference formulation. Hence, the vector kappaTildem is created from the vector kappaHatm in lines 144 to 148 of the code. However, since the velocity vectors U are initialized in the cell centres corresponding to a collocated grid arrangement, the formulation of the vector kappaTildem is not meaningful for the grid arrangement of OpenFOAM as far as I would say. Hence, I would suggest to simply delete the lines 144 to 148 in the code and replace all subsequent "kappaTildem" with "kappaHatm".
This is my first bug report and contribution to the OpenFOAM community so I am not quite firm in best practices for bug reporting. I hope that my bug report provides useful information and of course I am happy to respond if I have left anything unclear. Furthermore, I am very grateful for the utility createBoxTurb since it helps me a great deal with my research.
Best regards
Mario HermesKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2561Update value on codedFixedValue2022-09-28T07:18:06Zt RockUpdate value on codedFixedValue<!--
*** 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
I have found what appears to be a bug with the `codedFixedValue` boundary condition.
It appears that the BC does not update the field values when it is initialized.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
As an example you can take the pitzDaily on `$FOAM_TUTORIALS/basic/scalarTransportFoam/pitzDaily/`.
Run the case as is.
Afterwards, change the U boundary condition to:
```
type codedFixedValue;
value uniform (0 0 0);
name U_tst;
code
#{
vectorField field (patch().Cf());
forAll(field, faceI)
{
field[faceI] = vector (10, 0, 0) ;
}
operator==(field);
#};
}
```
The results will not be the same because of the flux calculation. This happens because of the value given in the entry `value uniform (0 0 0); `
### Environment information
- OpenFOAM version : v2106
- Operating system : WSL
- Hardware info :
- Compiler : GCC 9.4
### Possible fixes
Since this is a fixed value condition, it should evaluate the field values once it is initialized. However, I do not know where is the best to place a fix. (U.correctBoundaryConditions() seems to do the trick, but it is not a good solution for this case as the BC itself should run the `updateCoeffs()` function when it is created.)https://develop.openfoam.com/Development/openfoam/-/issues/2560BUG: viewFactor-2D is silently deprecated2022-11-08T10:11:28ZKutalmış BerçinBUG: viewFactor-2D is silently deprecated!551 - 457979a silently deprecated the two-dimensional viewFactor calculations.
Compare [master:viewFactorsGen.C#L681](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/preProcessing/viewFactorsGen/v...!551 - 457979a silently deprecated the two-dimensional viewFactor calculations.
Compare [master:viewFactorsGen.C#L681](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/preProcessing/viewFactorsGen/viewFactorsGen.C#L681) vs [develop:viewFactorsGen.C#L1091](https://develop.openfoam.com/Development/openfoam/-/blob/develop/applications/utilities/preProcessing/viewFactorsGen/viewFactorsGen.C#L1091).Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2559GAMG for overset cases2022-12-23T14:57:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG for overset cases<!--
*** 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 -->
Solving overset with GAMG does not work since GAMGInterface is not agglomerated so stays zero size. Mapping to zero size is not supported.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use any overset case. Switch on GAMG (needs algebraicPair as agglomerator). There will be error in GAMGSolverAgglomerateMatrix when trying to restrict the solution to the coarser level (since it has zero 'faces').
### 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 -->
Out of bounds indexing.
### 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 : feature-overset-coupledPatch branch
### 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
-->
Agglomerate GAMGInterface as e.g. cyclicAMIGAMGInterface.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2558faceAgglomerate assumes viewFactorsDict entries are all patch names2022-08-11T13:44:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceAgglomerate assumes viewFactorsDict entries are all patch names### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a p...### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a patch has the same name as one of the settings needed by `viewFactorsGen`.
### Target audience
Users of view factor radiation.
### Proposal
Put the patch information in `viewFactorsDict` in a sub dictionary:
```
writeViewFactorMatrix true;
writeFacesAgglomeration true;
writePatchViewFactors false;
//- Debug option
debug 1;
//- Dump connectivity rays
dumpRays false;
//- Optional per-patch agglomeration if faceAgglomerate is used
patchAgglomeration
{
".*"
{
nFacesInCoarsestLevel 100; // increase to get more radiation patches (coarse faces)
featureAngle 30; // 0: one radiation patch (coarse face) over one cell face
}
}
//- Maximum length for dynamicList. See /applications/utilities/preProcessing/viewFactorsGen/shootRays.H
maxDynListLength 1000000000;
```
### What does success look like, and how can we measure that?
- be backwards compatible
- use the patchAgglomeration subdictionary if it is thereMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2557Be able to choose the order of eigenvalues2022-08-11T07:26:55Zt RockBe able to choose the order of eigenvaluesCurrently the eigenvalue calculation returns the values in ascending order.
For several applications it is not uncommon to use them in descending order, which will require an additional operation to reverse the order.
If possible, I ...Currently the eigenvalue calculation returns the values in ascending order.
For several applications it is not uncommon to use them in descending order, which will require an additional operation to reverse the order.
If possible, I would like to request the possibility of selecting the order of the output.
Something like:
```
#include <iostream>
#include <vector>
#include <algorithm>
enum sortType{ascending, descending};
template<sortType S=ascending>
void sort (std::vector<double>& v)
{
std::sort(v.begin(), v.end());
}
template <>
void sort<descending> (std::vector<double>& v)
{
std::sort(v.begin(), v.end(), std::greater<>());
}
template<sortType S=ascending>
void foo(const std::vector<double>& v)
{
std::vector<double> v2 (v);
sort<S>(v2);
for (int i = 0; i< v.size(); i++)
{
std::cout << v2[i] << std::endl;
}
}
int main()
{
std::vector<double> tst = {1,3,4,2,5};
foo(tst);
foo<descending>(tst);
return 0;
}
```
This will keep the current code running as is, but with the flexibility of letting the user choose the order of the output.
It would also be nice to have the eigen vectors come out as column vectors. Currently they are row vectors. This would bring more similarity to other libraries, e.g., numpy, matlab
Best RegardsKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/65Incorrect download links for METIS during compilation2022-08-04T14:44:02ZDanyal MohaddesIncorrect download links for METIS during compilation# Summary
The download links for METIS provided during ThirdParty compilation are out of date.
# Steps to Reproduce
1. Download the latest version of ThirdParty (v2206)
2. `./Allwmake`
# Current Behavior
When METIS compilation is reach...# Summary
The download links for METIS provided during ThirdParty compilation are out of date.
# Steps to Reproduce
1. Download the latest version of ThirdParty (v2206)
2. `./Allwmake`
# Current Behavior
When METIS compilation is reached (and skipped), the links provided to download METIS are to [this link](http://glaros.dtc.umn.edu/gkhome/metis/metis/overview) and [this link](http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz). These links are out of date; the package has since moved.
# Correct Behavior
The link provided to download METIS should be [this one](https://github.com/KarypisLab/METIS).
# Possible fix
Update the links in `BUILD.md`https://develop.openfoam.com/Development/openfoam/-/issues/2555Small fixes for macOS2023-06-13T21:29:59ZAlexey MatveichevSmall fixes for macOS### Functionality to add/problem to solve
Fixes for small issues during compilation and execution of OpenFOAM v2206 on macOS
### Target audience
macOS OpenFOAM users willing to recompile software from sources.
### Proposal
Currentl...### Functionality to add/problem to solve
Fixes for small issues during compilation and execution of OpenFOAM v2206 on macOS
### Target audience
macOS OpenFOAM users willing to recompile software from sources.
### Proposal
Currently there are two main problems:
- `src/meshTools/triSurface/triSurfaceTools/geompack/geompack.C` causes segfault during compilation.
- Configuration scripts add unnecessary variable `LD_LIBRARY_PATH` for environment.
- `foamCleanPath` script operates on `DYLD_LIBRARY_PATH`, which is empty upon invocation of the script.
The patch solves these problems:
- `-ftrapping-math` is switched off using `#pragma`. This is enough to compile `geompack.C` without segfault.
- Configuration scripts operate on backup `FOAM_DYLD_LIBRARY_PATH`, which is then copied to `DYLD_LIBRARY_PATH`.
### What does success look like, and how can we measure that?
- Successful compilation of the software on macOS.
- Successful execution of cases with `Allrun` scripts (or any other).
Compilation and execution is tested on
```
$ sw_vers
ProductName: macOS
ProductVersion: 12.5
BuildVersion: 21G72
```
with
```
$ clang++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
```
Patch: [OpenFOAM-v2206-e1da9617.patch](/uploads/51326bb6d1ecb4a2fbb189966e9c287f/OpenFOAM-v2206-e1da9617.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2554holding reference to copy2022-09-09T12:10:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comholding reference to copy<!--
*** 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 -->
Holding reference to e.g. HashTable<>::sortedToc
### 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
-->
Do not hold reference.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com