Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-02-02T08:48:01Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2791snappyHexMesh: motorBike tutorial error/hangs with Scotch with default (-DSCO...2024-02-02T08:48:01ZGabriel GerlerosnappyHexMesh: motorBike tutorial error/hangs with Scotch with default (-DSCOTCH_PTHREAD[_MPI]) flags<!--
*** 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 -->
snappyHexMesh doesn't work properly when OpenFOAM is linked against a Scotch library built with default options
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Start with Scotch (latest from major version 6 or 7) built **without removing** the default `-DSCOTCH_PTHREAD` (major version 6) or `-DSCOTCH_PTHREAD_MPI` (major version 7) compilation flag (for reference, [link to the official explanation of these flags](https://gitlab.inria.fr/scotch/scotch/-/blob/b43864123e820e3ca541bfecd3738aed385a4c47/INSTALL.txt#L543-L585))
- Compile OpenFOAM against that Scotch
- Run the `$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBike` case
### 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 -->
snappyHexMesh fails or gets stuck and doesn't make any progress.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`motorBike` case successfully runs to completion.
### Relevant logs and/or images
Possible failure modes:
```
...
Refined mesh in = 0.01 s
After refinement surface refinement iteration 0 : cells:1308 faces:4332 points:1758
Cells per refinement level:
0 1276
1 32
Skipping balancing since max unbalance 0.0674847 is less than allowable 0.1
Surface refinement iteration 1
------------------------------
Marked for refinement due to surface intersection : 21 cells.
Marked for refinement due to curvature/regions : 0 cells.
Determined cells to refine in = 0 s
Selected for refinement : 26 cells (out of 1308)
Edge intersection testing:
Number of edges : 4992
Number of edges to retest : 917
Number of intersected edges : 110
Refined mesh in = 0.01 s
After refinement surface refinement iteration 1 : cells:1490 faces:4992 points:2069
Cells per refinement level:
0 1267
1 87
2 136
[warn] event_base_loop: reentrant invocation. Only one event_base_loop can run on each event_base at once.
```
Or (copied from [here](https://github.com/gerlero/openfoam-app/issues/7#issuecomment-1043711443)—thanks to @xuegy):
```
Cells per refinement level:
0 1267
1 87
2 136
(4): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(5): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(6): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(7): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(0): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(1): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(2): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
(3): ERROR: SCOTCH_dgraphInit: Scotch compiled with SCOTCH_PTHREAD and program not launched with MPI_THREAD_MULTIPLE
```
<!--
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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212|v2112 (v2206 not tested, but I expect the same)
- Operating system : macOS
- Hardware info : arm64
- Compiler : clang
### Possible fixes
- One could remove the `-DSCOTCH_PTHREAD` (major version 6) or `-DSCOTCH_PTHREAD_MPI` (major version 7) flags before compiling Scotch.
- Unfortunately, this doesn't work for those using Scotch from a package manager. I note that [Scotch maintainers recommend keeping those flags enabled](https://gitlab.inria.fr/scotch/scotch/-/blob/b43864123e820e3ca541bfecd3738aed385a4c47/INSTALL.txt#L867-L887), a recommendation that at least some packagers seem to be honoring (e.g. [Debian](https://www.mail-archive.com/debian-devel-changes@lists.debian.org/msg733635.html), [Homebrew](https://formulae.brew.sh/formula/scotch#default)). [`easy_build` is also currently dealing with this issue with OpenFOAM](https://github.com/easybuilders/easybuild-easyconfigs/issues/15907).
- A workaround I found that seems to fix the problem is to change [these lines of `UPstream.C`](https://develop.openfoam.com/Development/openfoam/-/blob/868d6dd77875772f81fb4277359ecd32e99cdd2a/src/Pstream/mpi/UPstream.C#L226-L230) so as to force the call to `MPI_Init_thread()` to always use the `MPI_THREAD_MULTIPLE` option.
- The error messages in the second (i.e. @xuegy's) log appear to point more directly at this being the cause.
<!--
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
-->
EDIT: add link to `easy_build` issuehttps://develop.openfoam.com/Development/openfoam/-/issues/2790OpenFOAM cannot be compiled with gcc 132023-06-12T14:32:26ZÅsmund ErvikOpenFOAM cannot be compiled with gcc 13### Summary
From gcc version 13 and onwards, it is required to `#include <cstdint>` to have access to types such as `uint64_t`.
OpenFOAM and third-party libraries needs to be patched to allow compilation with gcc 13.
This applies to a ...### Summary
From gcc version 13 and onwards, it is required to `#include <cstdint>` to have access to types such as `uint64_t`.
OpenFOAM and third-party libraries needs to be patched to allow compilation with gcc 13.
This applies to a lot of projects, for example here is the corresponding issue for [VTK](https://gitlab.kitware.com/vtk/vtk/-/issues/18782).
This is described also in the [gcc 13 porting guide](https://gcc.gnu.org/gcc-13/porting_to.html) .
### Steps to reproduce
Trying to compile OpenFOAM v2212 with gcc 13 on my Arch Linux box results in the following error, already in third party libraries (kahip):
`error: ‘uint64_t’ in namespace ‘std’ does not name a type; did you mean ‘wint_t’?`
### Workarounds
I have tried setting the C++ standard by exporting `FOAM_EXTRA_CXXFLAGS=--std=c++11`, and can confirm this is picked up by the compiler, but this does not address the issue.
So far I have only been able to compile using an older gcc version, e.g. by setting "version=12" in the `WM_COMPILE_CONTROL` variable in etc/bashrc before sourcing.https://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/2783forced interpolation from coupled boundaries introduces problems2023-06-01T09:01:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comforced interpolation from coupled boundaries introduces problems<!--
*** 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 e.g. `cyclic` boundaries the value always has to be the interpolate of the two neighbouring cell values (except for geometry). For some field operations this can give unexpected results, e.g. `sign` of a volScalarField. It is quite easy to have +1 in one cell and -1 in its coupled cell, resulting in a nonsensical 0 interpolated value on the coupled boundary. In `ObukhovLength` functionObject it divides by this resulting in a sigfpe.
The general issue is that non-scalar indicator fields should not have boundary conditions.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run below tutorial in https://develop.openfoam.com/Development/openfoam/-/tree/feature-evaluation-check
### Example case
```
tutorials/verificationAndValidation/atmosphericModels/atmForestStability/results/veryStable
```
<!--
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 since sign(B) interpolates +1 and -1 resulting in 0 which is used to divide by in ObukhovLength functionObject.
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :`feature-evaluation-check` branch
### Possible fixes
Relax the requirement that coupled cyclic faces have the same value on either side. Or have a different field type to disallow sign (an indicator field) to be interpolated.
<!--
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/2782decomposePar not handling uniformDimensionedFIelds?2023-12-21T16:00:57ZMark OLESENdecomposePar not handling uniformDimensionedFIelds?needs verification : @Thibault or @orgogozoneeds verification : @Thibault or @orgogozohttps://develop.openfoam.com/Development/openfoam/-/issues/2781Many spurious warnings in createBaffles2023-06-13T12:03:09ZMark OLESENMany spurious warnings in createBafflesAs reported by @Prashant - createBaffles with internalFacesOnly = true generates many warnings about processor boundaries.
Since coupled patches are treated distinctly and independently of internalFacesOnly, it makes little sense to rep...As reported by @Prashant - createBaffles with internalFacesOnly = true generates many warnings about processor boundaries.
Since coupled patches are treated distinctly and independently of internalFacesOnly, it makes little sense to report them with a warning about turning off boundary faces (which would not work anyhow).Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2780BUG: PrimitivePatch::nInternalEdges includes non-manifold edges2023-05-15T15:18:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: PrimitivePatch::nInternalEdges includes non-manifold edges<!--
*** 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 PrimitivePatch edge sorting should put internal edges (= edges connected to 2 faces) first, followed by boundary edges (= edges connected to 1 face). It also seems to order/include any edges with >2 faces into the nInternalEdges slice.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See below.
### 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
-->
[cavity.tgz](/uploads/39298bb461c3b51188ed1d53b9fd03b7/cavity.tgz)
- use ./Allrun to construct
- is a 2x2 cavity blockMesh with bottom left and top-right cell removed
### What is the current *bug* behaviour?
<!-- What actually happens -->
The non-manifold edge with 4 patch faces gets reported as an internal edge.
See attached checkMesh hack
[checkTopology.C](/uploads/297943004793eed52da2421284f490b3/checkTopology.C)
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
### 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
-->
Might have side effects for
- snappyHexMesh
- patch extrusion
so not to be fixed before v2306.
### See also:
https://develop.openfoam.com/Development/openfoam/-/issues/2771Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2779OpenFOAM overset restart not working2024-02-28T12:15:17ZGabriel Barajasbarajasg@unican.esOpenFOAM overset restart not working**Summary**
Dear all,
If I run the floating Object tutorials with the deforming mesh approach, either with the _rigidBodyMeshMotion_ library or the _sixDoFRigidBodyMotion_ library, I can stop and restart the simulation and everything w...**Summary**
Dear all,
If I run the floating Object tutorials with the deforming mesh approach, either with the _rigidBodyMeshMotion_ library or the _sixDoFRigidBodyMotion_ library, I can stop and restart the simulation and everything works correctly. I enclose figures of both cases: in purple a simulation starting in 0.0s and ending in 6.0s, and in green a simulation starting in 1.0s (copied from the previous case) and ending in 6.0s.
Deforming Mesh + rigidBodyMeshMotion:
![deforming_rigidBodyMotion_1.5s](/uploads/b2c69cea59114aff9b1f196bbbdb1877/deforming_rigidBodyMotion_1.5s.png)
![deforming_rigidBodyMotion_4.5s](/uploads/3d020d36c5a95cd92e2d892010b62468/deforming_rigidBodyMotion_4.5s.png)
Deforming Mesh + sixDoFRigidBodyMotion:
![deformingMesh_6DoF_1.5s](/uploads/b1d6691d5153372a7ce7d841d08afd17/deformingMesh_6DoF_1.5s.png)
![deformingMesh_6DoF_4.5s](/uploads/e3a0bd519467085eb62955b598b1d1a9/deformingMesh_6DoF_4.5s.png)
But, when I I try to the same within the overset framework, it does not work:
![overset_6DoF_1.2s](/uploads/b5977f8947a31015ff67dea697abe711/overset_6DoF_1.2s.png)
I believe that the code is not reading correctly all the variables and probably using some default values that normally are zero, as if it was starting from a rest position.
**Steps to reproduce**
I enclose the case to reproduce the issue. First run the case normally, afterwards try to re-run it starting from the time t=1.0s.
Check the motion of the floating body in both cases.
**Example case**
[floatingBody.tar.xz](/uploads/6a915eca6e10f51ee77e9f99e38e2015/floatingBody.tar.xz)
Thanks,
Gabihttps://develop.openfoam.com/Development/openfoam/-/issues/2777ambigous conversion for autoPtr<bool>2023-06-13T13:24:14ZMark OLESENambigous conversion for autoPtr<bool>The `autoPtr` currently has different casting types. Eg,
```
explicit operator bool() const noexcept;
operator const T&() const;
```
Consider the following:
```
autoPtr<bool> something;
if (something) ...
```
This may *either* imply th...The `autoPtr` currently has different casting types. Eg,
```
explicit operator bool() const noexcept;
operator const T&() const;
```
Consider the following:
```
autoPtr<bool> something;
if (something) ...
```
This may *either* imply that the `operator bool` is invoked (testing for existence of the pointer), or the `operator const T&` is invoked (returning the value of the pointer).
The casting to type is not particularly desirable, but still supported with `#define Foam_autoPtr_castOperator` in order to handle legacy code.
Current best fix is to replace with `Switch`.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2775non-blocking AMI patches2023-12-21T16:01:16ZMark OLESENnon-blocking AMI patchescross-ref EP2149cross-ref EP2149https://develop.openfoam.com/Development/openfoam/-/issues/2774Intel MPI sometimes hangs on exit with FatalError2023-06-22T07:56:23ZMark OLESENIntel MPI sometimes hangs on exit with FatalErrorcross-ref EP2164
Hanging on finalize is a [known occurrence with Intel MPI](https://community.intel.com/t5/Intel-oneAPI-HPC-Toolkit/MPI-program-hangs-in-quot-MPI-Finalize-quot/m-p/1158477)cross-ref EP2164
Hanging on finalize is a [known occurrence with Intel MPI](https://community.intel.com/t5/Intel-oneAPI-HPC-Toolkit/MPI-program-hangs-in-quot-MPI-Finalize-quot/m-p/1158477)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2773writePointSet fails in parallel2023-05-05T14:12:08ZPrashant SonakarwritePointSet fails in parallelExample to reproduce: Any mesh where pointSet e.g. nonManifoldPoints are written
Try foamToVTK -pointSet <> in parallel and it fails with `unallocated autoPtr of type N4Foam3vtk9formatterE`Example to reproduce: Any mesh where pointSet e.g. nonManifoldPoints are written
Try foamToVTK -pointSet <> in parallel and it fails with `unallocated autoPtr of type N4Foam3vtk9formatterE`https://develop.openfoam.com/Development/openfoam/-/issues/2771finite-area issues with multiply connected edges2023-06-14T12:08:54ZMark OLESENfinite-area issues with multiply connected edgescross-ref EP2148
- multiply-connected edges can arise at the centre of a "star"
connection or because the patch faces are actually baffles.
- In the serial case these internal edges are also rather dubious in
terms of modelling...cross-ref EP2148
- multiply-connected edges can arise at the centre of a "star"
connection or because the patch faces are actually baffles.
- In the serial case these internal edges are also rather dubious in
terms of modelling. However, when they are split across multiple
processors there can only be a single processor-to-processor
connectivity.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2769externalWallHeatFluxTemperature and PatchFunction12023-06-13T13:25:33ZVojtech BetakexternalWallHeatFluxTemperature and PatchFunction1
### Summary
If is used a combination of boundary condition externalWallHeatFluxTemperature with PatchFunction1 then there is a problem with writing the boundary condition during the calculation. I have used a combination of PatchFuncti...
### Summary
If is used a combination of boundary condition externalWallHeatFluxTemperature with PatchFunction1 then there is a problem with writing the boundary condition during the calculation. I have used a combination of PatchFunction1 and coded as is shown below
type externalWallHeatFluxTemperature;
mode flux;
q coded;
kappaMethod fluidThermo;
value $internalField;
name heatFluxVerticalProfile;
code
#{
...
#};
During the calculation, the boundary condition is written as
type externalWallHeatFluxTemperature;
mode flux;
kappaMethod fluidThermo;
q
{
type externalWallHeatFluxTemperature;
mode flux;
q coded;
name heatFluxVerticalProfile;
code
#{
...
#};
kappaMethod fluidThermo;
value uniform 873;
}
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212
Operating system : openSUSE
Hardware info : any info that may help?
Compiler : gcc
### Possible fixes
Necessary to check how is the boundary condition written.https://develop.openfoam.com/Development/openfoam/-/issues/2764Function1/CSV/CSV.C: Need to move explicit template specializations to a sep...2023-05-05T14:10:24ZMartin BeaudoinFunction1/CSV/CSV.C: Need to move explicit template specializations to a separate file (ex: CSVTemplates.C)<!--
*** 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 file src/OpenFOAM/primitives/functions/Function1/CSV/CSV.C contains 2 explicit template specializations for the member function ::readValue(). Those will be reported as multiply-defined by the linker when the corresponding file CSV.H gets included in the source code of a custom-build library depending on the core library libOpenFOAM.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Simply add the statement "#include CSV.H" in the source code of any custom-made library depending on the libOpenFOAM library.
Since the file CSV.C is included at the bottom of the file CSV.H, the 2 explicit template specializations will be reported as multiply-defined by the linker.
<!-- How one can reproduce the issue - this is very important -->
### Example case
This is a compilation issue.
<!--
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?
The custom-build library fails to link.
An error message is written at the console stating that 2 instances of the template specialized member function ::readValue() are multiply-defined, and are first defined at lines 72 and 82 of src/OpenFOAM/primitives/functions/Function1/CSV/CSV.C
<!-- What actually happens -->
### What is the expected *correct* behaviour?
Proper linking of the custom-made library when using the class Foam::Function1Types::CSV.
<!-- 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : probably all versions of OpenFOAM since the files CSV.[CH] were introduced.
- Operating system : Fedora 33
- Hardware info :
- Compiler : gcc 10.3.1
### Possible fixes
Move the following 2 explicit template specializations to a separate file like src/OpenFOAM/primitives/functions/Function1/CSV/CSVTemplates.C
Add the file CSVTemplates.C to the file src/OpenFOAM/Make/files.
From src/OpenFOAM/primitives/functions/Function1/CSV/CSV.C
```
65 // * * * * * * * * * * * * * Private Member Functions * * * * * * * * * * * //
66
67 template<>
68 Foam::label Foam::Function1Types::CSV<Foam::label>::readValue
69 (
70 const List<string>& strings
71 ) const
72 {
73 return readLabel(strings[componentColumns_[0]]);
74 }
75
76
77 template<>
78 Foam::scalar Foam::Function1Types::CSV<Foam::scalar>::readValue
79 (
80 const List<string>& strings
81 ) const
82 {
83 return readScalar(strings[componentColumns_[0]]);
84 }
```
<!--
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/2762nonSphereDragForce: Typo in equation in documentation2023-04-16T19:55:18ZFranz DnonSphereDragForce: Typo in equation in documentation<!--
*** 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
not a typo, only convoluted... Closing this.
### Steps to reproduce
n/a.
### Example case
n/a
### What is the current *bug* behaviour?
### What is the expected *correct* behavior?
### Relevant logs and/or images
### Environment information
- OpenFOAM version : v2212
### Possible fixes
Code: `src/lagrangian/intermediate/submodels/Kinematic/ParticleForces/Drag/NonSphereDrag/NonSphereDragForce.C`
Doc: `src/lagrangian/intermediate/submodels/Kinematic/ParticleForces/Drag/NonSphereDrag/NonSphereDragForce.H`https://develop.openfoam.com/Development/openfoam/-/issues/2761wmake: command not found2023-05-09T13:03:40ZMichael Jehan Pangestuwmake: command not foundI am trying to install a custom utility for openFOAM in macos, I cannot use the wmake function even though I have installed xcode command line tools and have "make" in the /usr/bin folderI am trying to install a custom utility for openFOAM in macos, I cannot use the wmake function even though I have installed xcode command line tools and have "make" in the /usr/bin folderhttps://develop.openfoam.com/Development/openfoam/-/issues/2760LESRegion computed wrongly when using kOmegaSSTIDDES turbulence model2023-10-17T15:06:11ZWojciech SadowskiLESRegion computed wrongly when using kOmegaSSTIDDES turbulence model### Functionality to add/problem to solve
The `LESRegion()` function in the `kOmegaSSTIDDES` turbulence model is not implemented.
Instead the implementation from the base class `kOmegaSSTDES` is used:
```cpp
template<class BasicTurbulen...### Functionality to add/problem to solve
The `LESRegion()` function in the `kOmegaSSTIDDES` turbulence model is not implemented.
Instead the implementation from the base class `kOmegaSSTDES` is used:
```cpp
template<class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTDES<BasicTurbulenceModel>::LESRegion() const
{
const volScalarField& k = this->k_;
const volScalarField& omega = this->omega_;
const volVectorField& U = this->U_;
const volScalarField CDkOmega
(
(2*this->alphaOmega2_)*(fvc::grad(k) & fvc::grad(omega))/omega
);
const volScalarField F1(this->F1(CDkOmega));
return tmp<volScalarField>::New
(
IOobject::scopedName("DES", "LESRegion"),
neg(dTilda(mag(fvc::grad(U)), CDES(F1)) - lengthScaleRAS())
);
}
```
leading to LES region indicator computed with
different equation than the one actually used in the model:
```cpp
template<class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::dTilda
(
const volScalarField& magGradU,
const volScalarField& CDES
) const
{
const volScalarField lRAS(this->lengthScaleRAS());
const volScalarField lLES(this->lengthScaleLES(CDES));
const volScalarField alpha(this->alpha());
const volScalarField expTerm(exp(sqr(alpha)));
tmp<volScalarField> fB = min(2*pow(expTerm, -9.0), scalar(1));
const volScalarField fdTilda(max(1 - fdt(magGradU), fB));
if (fe_)
{
/*
...
*/
}
// Simplified formulation from Gritskevich et al. paper (2011) where fe = 0
return max
(
fdTilda*lRAS + (1 - fdTilda)*lLES,
dimensionedScalar(dimLength, SMALL)
);
}
```
While writing this issue, I became aware that outputting `fd` is also possible now, as of v2212.
It seems that for IDDES model it is actually equivalent to the way `fdTilda` is computed in the code,
and `1-fdTilda` multiplies the LES length scale in both versions of blending, so it serves the same purpose (as far as I understand it).
Perhaps one option to resolve this would be implementing a virtual `LESRegion()` that throws `FatalError` telling the user to
output `fd` instead and subtract it from 1?
### Target audience
Target audience are the users of hybrid RANS/LES turbulence models.
Proper indication in which region the model works in a LES mode is important for
debugging and setting up cases with those models properly.
### Proposal
I have made a quick solution for myself in an out-of-repository copy of kOmegaSSTIDDES.
1. Added a protected member function, to refactor computation of `fdTilda`.
Header:
```cpp
//- Return the fdTilda function (moved to a function for
// LESRegions function)
tmp<volScalarField> fdTilda
(
const volScalarField &magGradU,
const volScalarField &expTerm
) const;
```
Implementation:
```cpp
template <class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::fdTilda
(
const volScalarField &magGradU,
const volScalarField &expTerm
) const
{
tmp<volScalarField> fB = min(2 * pow(expTerm, -9.0), scalar(1));
return max(1 - fdt(magGradU), fB);
}
```
2. Added the `LESRegion()`:
Header:
```cpp
//- Return the LES field indicator
virtual tmp<volScalarField> LESRegion() const;
```
Implementation:
```cpp
template <class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::LESRegion() const
{
const volScalarField magGradU(mag(fvc::grad(this->U_)));
const volScalarField expTerm(exp(sqr(this->alpha())));
tmp<volScalarField> tLESRegion
(
new volScalarField
(
IOobject::scopedName("IDDES", "LESRegion"),
1 - this->fdTilda(magGradU, expTerm)
)
);
// Solver is in RANS mode next to the wall.
// i have no clue if this can cause problems
tLESRegion.ref().boundaryFieldRef() == 0.0;
return tLESRegion;
}
```
### What does success look like, and how can we measure that?
The LES region computed with unchanged code from a sample test case:
![obraz](/uploads/a22e4dfdec687fb767946f36a9d49de9/obraz.png)
The LES region computed with the code above, using `fdTilda` as it is computed in `dTilda` function:
![obraz](/uploads/38fd2950b035e2469c5353acd245a400/obraz.png)
### Links / references
Reference from KOmegaSSTIDDES model:
Gritskevich, M.S., Garbaruk, A.V., Schuetze, J., Menter, F.R. (2011)
Development of DDES and IDDES Formulations for the k-omega
Shear Stress Transport Model, Flow, Turbulence and Combustion,
pp. 1-19Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2759Unable to install openfoam2023-04-14T10:32:47ZSaurav ChaudhariUnable to install openfoamI am unable to install OpenFOAM CFD Module on my Windows. It's showing some error at line 47.
![OpenFOAM](/uploads/ef7b5578c108aa4ca39db7c73fac4c7f/OpenFOAM.jpg)I am unable to install OpenFOAM CFD Module on my Windows. It's showing some error at line 47.
![OpenFOAM](/uploads/ef7b5578c108aa4ca39db7c73fac4c7f/OpenFOAM.jpg)https://develop.openfoam.com/Development/openfoam/-/issues/2758explicit calculations for triSurface fields2023-04-21T07:43:21ZMark OLESENexplicit calculations for triSurface fieldsThe triSurface fields are a slightly dodgy construct, they use triSurface for mesh sizes/relationship but the fields cannot be registered on triSurface. Instead, some other source of objectRegistry is used (in some cases this is whatever...The triSurface fields are a slightly dodgy construct, they use triSurface for mesh sizes/relationship but the fields cannot be registered on triSurface. Instead, some other source of objectRegistry is used (in some cases this is whatever the IOobject provides).
As a result, the relationship `field.mesh().thisDb()` does not work.
In places using triSurface fields, they should be expanded out (ie, expressed as calculations of the primitive fields) to ensure that none of the `mesh().thisDb()` code is used.Mark OLESENMark OLESEN