Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-13T12:03:09Zhttps://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/2778IOstreams: Clang ambiguity errors (develop branch, macOS)2024-01-22T08:23:14ZGabriel GerleroIOstreams: Clang ambiguity errors (develop branch, 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 -->
Compilation of the current `develop` branch of OpenFOAM on macOS fails with ambiguity errors as reported by Clang
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Attempt to compile the `develop` branch on macOS with Clang
### 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 -->
#### Ambiguity error @ `PstreamExchange.C`
```
PstreamExchange.C:181:32: error: call to 'max' is ambiguous
maxCount = max(maxCount, count);
^~~
```
### Ambiguity error @ `ISstream.C`
```
ISstream.C:1042:35: error: use of overloaded operator '+' is ambiguous (with operand types 'std::basic_istream<char>::pos_type' (aka 'fpos<__mbstate_t>') and 'std::streamsize' (aka 'long'))
is_.seekg(is_.tellg() + count);
~~~~~~~~~~~ ^ ~~~~~
```
### 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.
-->
#### Ambiguity error @ `PstreamExchange.C`
```
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/PstreamExchange.C:181:32: error: call to 'max' is ambiguous
maxCount = max(maxCount, count);
^~~
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/PstreamExchange.C:564:28: note: in instantiation of function template specialization 'Foam::PstreamDetail::exchangeChunkedBuf<int>' requested here
PstreamDetail::exchangeChunkedBuf<Type>
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/PstreamExchange.C:959:5: note: in instantiation of function template specialization 'Foam::Pstream::exchange<Foam::List<int>, int>' requested here
exchange<Container, Type>(sendBufs, recvSizes, recvBufs, tag, comm, wait);
^
regionSplit/regionSplit.C:774:14: note: in instantiation of function template specialization 'Foam::Pstream::exchange<Foam::List<int>, int>' requested here
Pstream::exchange<labelList, label>
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:65:1: note: candidate function
MAXMIN(int8_t, int8_t, int8_t)
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:59:16: note: expanded from macro 'MAXMIN'
inline RetType max(const Type1 s1, const Type2 s2) \
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:66:1: note: candidate function
MAXMIN(int16_t, int16_t, int16_t)
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:59:16: note: expanded from macro 'MAXMIN'
inline RetType max(const Type1 s1, const Type2 s2) \
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:68:1: note: candidate function
MAXMIN(int32_t, int32_t, int32_t)
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:59:16: note: expanded from macro 'MAXMIN'
inline RetType max(const Type1 s1, const Type2 s2) \
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:69:1: note: candidate function
MAXMIN(int64_t, int64_t, int32_t)
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:59:16: note: expanded from macro 'MAXMIN'
inline RetType max(const Type1 s1, const Type2 s2) \
^
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/int.H:70:1: note: candidate function
MAXMIN(int64_t, int32_t, int64_t)
[[[[ NOTE: many other lines removed for brevity ]]]]
/Volumes/OpenFOAM-develop/src/OpenFOAM/lnInclude/uint.H:60:16: note: expanded from macro '\
MAXMIN'
inline RetType max(const Type1 s1, const Type2 s2) \
^
1 error generated.
make[1]: *** [/Volumes/OpenFOAM-develop/build/darwin64ClangDPInt32Opt/src/meshTools/regionSplit/regionSplit.o] Error 1
```
#### Ambiguity error @ `ISstream.C`
```
db/IOstreams/Sstreams/ISstream.C:1042:35: error: use of overloaded operator '+' is ambiguous (with operand types 'std::basic_istream<char>::pos_type' (aka 'fpos<__mbstate_t>') and 'std::streamsize' (aka 'long'))
is_.seekg(is_.tellg() + count);
~~~~~~~~~~~ ^ ~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__ios/fpos.h:41:30: note: candidate function
_LIBCPP_HIDE_FROM_ABI fpos operator+(streamoff __off) const {
^
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, long)
is_.seekg(is_.tellg() + count);
^
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(float, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(double, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long double, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(int, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, float)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, double)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, long double)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, int)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, long long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, __int128)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, unsigned int)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, unsigned long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, unsigned long long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(long long, unsigned __int128)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(__int128, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(unsigned int, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(unsigned long, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(unsigned long long, long)
db/IOstreams/Sstreams/ISstream.C:1042:35: note: built-in candidate operator+(unsigned __int128, long)
1 error generated.
make[1]: *** [/Volumes/OpenFOAM-develop/build/darwin64ClangDPInt32Opt/src/OpenFOAM/db/IOstreams/Sstreams/ISstream.o] Error 1
```
### 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 : develop branch
- Operating system : macOS (Darwin)
- Hardware info : x86_64 and arm64
- Compiler : clang
### Possible fixes
#### Ambiguity error @ `PstreamExchange.C`
At https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/OpenFOAM/db/IOstreams/Pstreams/PstreamExchange.C#L181, maybe rewrite the enclosing `if` to avoid calling `max`, i.e.:
```
if (proci != myProci && count > maxCount)
{
maxCount = count;
}
```
#### Ambiguity error @ `ISStream.C`
At https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/OpenFOAM/db/IOstreams/Sstreams/ISstream.C#L1042, disambiguate the `operator+` call, e.g.:
```
// Forward seek
is_.seekg(is_.tellg() + std::istream::pos_type(count));
```
<!--
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
-->v2306Mark OLESENMark OLESENhttps://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/2776Error in the documentation2023-05-11T15:37:00ZGiorgio GiorgianiError in the documentationNot sure this is the place to post this. In the Programmer's Guide (Version v2206) the formula for the tensor divergence is wrong.
I am referring to formula 3.5 at page 30, the expansion in the right.
Now it looks like:
$$
\begin{pmat...Not sure this is the place to post this. In the Programmer's Guide (Version v2206) the formula for the tensor divergence is wrong.
I am referring to formula 3.5 at page 30, the expansion in the right.
Now it looks like:
$$
\begin{pmatrix}
\partial T_{11}/\partial x_{1} + \partial T_{21}/\partial x_{1} +\partial T_{31}/\partial x_{1} \\
\partial T_{12}/\partial x_{2} + \partial T_{22}/\partial x_{2} +\partial T_{32}/\partial x_{2} \\
\partial T_{13}/\partial x_{3} + \partial T_{23}/\partial x_{3} +\partial T_{33}/\partial x_{3}
\end{pmatrix}
$$
should be
$$
\begin{pmatrix}
\partial T_{11}/\partial x_{1} + \partial T_{21}/\partial x_{2} +\partial T_{31}/\partial x_{3} \\
\partial T_{12}/\partial x_{1} + \partial T_{22}/\partial x_{2} +\partial T_{32}/\partial x_{3} \\
\partial T_{13}/\partial x_{1} + \partial T_{23}/\partial x_{2} +\partial T_{33}/\partial x_{3}
\end{pmatrix}
$$https://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/2772BUG: effectivenessTable: wrong sign2023-05-09T07:28:57ZKutalmış BerçinBUG: effectivenessTable: wrong signIn [effectivenessTable.C#L324](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/heatExchangerSource/heatExchangerModels/effectivenessTable/effectivenessTable.C#L324):
const scalar seconda...In [effectivenessTable.C#L324](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/heatExchangerSource/heatExchangerModels/effectivenessTable/effectivenessTable.C#L324):
const scalar secondaryOutletT =
Qt_/(secondaryMassFlowRate_*secondaryCp) + secondaryInletT_;
When the value of `Qt` is positive, heat is lost from the secondary flow which causes a decrease in its temperature. However, in the given expression, the resulting outlet temperature is reported to be higher than the inlet temperature.
For neg/pos `Qt`, the expression should be as follows:
const scalar secondaryOutletT =
secondaryInletT_ - Qt_/(secondaryMassFlowRate_*secondaryCp);
This bug is merely a report issue, and as such, simulation results should remain unaffected.Kutalmış BerçinKutalmış Berçinhttps://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/2770Error in implementation of blending wall functions in nutkWallFunction and nu...2023-12-08T11:46:50ZLuca CornoltiError in implementation of blending wall functions in nutkWallFunction and nutUWallFunction<!--
*** 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 the blending weights are applied to turbulent wall function to find the effective turbulent viscosity at the wall (like in nutkWallFunction or nutkWallFunction classes), the final result is not coherent with the one reported in the reference papers (for example, see eq. 33 in Popovac, M., & Hanjalić, K. (2007), "Compound wall treatment for RANS computation of complex turbulent flows and heat transfer" or eq. 34 in Knopp, T., Alrutz, T., & Schwamborn, D. (2006) "A grid and flow adaptive wall-function method for RANS turbulence modelling"). This is because of incorrect implementation of the equations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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?
The blending weights are applied to relative viscosities (nu - nu_molecular, in the code: nutVis = 0, nutLog = nuEff - nuw) instead of effective viscosities of the sub-regions. This works well only with the STEPWISE and MAX methods, while with the other methods (BINOMIAL, EXPONENTIAL and TANH) the contribution of the viscous sub-layer and of the log-law layer are not weighted as expected.
### 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 : v2212
- Operating system : Mint 21.1
- Hardware info :
- Compiler :
### Possible fixes
The blending weights should be applied to effective viscosities of the viscous sub-layer and of the log-law layer. Then, the molecular viscosity should be removed from the result of the weighting process before returning the final value of nutw. In this way, the expected effective viscosity at the wall is correctly recovered.v2312Kutalmış BerçinKutalmış Berçinhttps://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/2767Let user define the output field name in the wallShearStress FO2023-04-27T08:13:12ZTimofey MukhaLet user define the output field name in the wallShearStress FO### Functionality to add/problem to solve
Would it be OK to extend the functionality of the `wallShearStress` FO to support other output field names rather than `wallShearStress`?
The latter would still be the default, thus not braking ...### Functionality to add/problem to solve
Would it be OK to extend the functionality of the `wallShearStress` FO to support other output field names rather than `wallShearStress`?
The latter would still be the default, thus not braking any workflows or tutorials.
I realize that not a lot of people will need that, but I guess it cannot hurt? The reason I want this implemented is that my WMLES library also uses `wallShearStress`, and if one also uses the FO, there is a name collision, which leads to a nasty looking crash, as discovered by Tobias.
### Proposal
Add an optional `field` or `fieldName` keyword for the user to set, and use that in the constructor, which allocates the `volVectorField`.
### Funding
I am reasonably sure I can implement this myself without any help. Impact on code maintenance should be negligible.https://develop.openfoam.com/Development/openfoam/-/issues/2766Wrong literature reference in kOmega model2023-04-29T17:21:33ZSantiago Marquez DamianWrong literature reference in kOmega modelHello, reference for kOmega model in kOmega.H does not correspond to the actual implementation,
References:
\verbatim
Wilcox, D. C. (1998).
Turbulence modeling for CFD
(Vol. 2, pp. 103-217). La Canad...Hello, reference for kOmega model in kOmega.H does not correspond to the actual implementation,
References:
\verbatim
Wilcox, D. C. (1998).
Turbulence modeling for CFD
(Vol. 2, pp. 103-217). La Canada, CA: DCW industries.
\endverbatim
it should read,
Wilcox, D.C. (1988), "Re-assessment of the scale-determining equation for advanced turbulence models", AIAA Journal, vol. 26, no. 11, pp. 1299-1310.
The model presented in cited pages of Wilcox book corresponds to modified kOmega
https://www.cfd-online.com/Wiki/Wilcox%27s_modified_k-omega_model
which is later improved in the same chapter of the book to manage low Reynolds effects by means of alpha* function.
We hope to contribute this modified kOmega model with optional Low Reynolds treatment soon.
Regards.https://develop.openfoam.com/Development/openfoam/-/issues/2765humidityTemperatureCoupledMixedFvPatchScalarField documentation2023-04-25T19:58:49ZDaan JongeriushumidityTemperatureCoupledMixedFvPatchScalarField documentationDocumentation of "humidityTemperatureCoupledMixedFvPatchScalarField Class Reference" possibly wrong.
myInterfacePatchName
{
type thermalHumidityCoupledMixed; _**-> should be humidityTemperatureCoupledMixed;**_...Documentation of "humidityTemperatureCoupledMixedFvPatchScalarField Class Reference" possibly wrong.
myInterfacePatchName
{
type thermalHumidityCoupledMixed; _**-> should be humidityTemperatureCoupledMixed;**_
kappaMethod fluidThermo;
kappa none;
// Modes of operation: inert, condensation, vaporization, condEvap
mode condEvap;_ **-> should be condensationAndEvaporation;**_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çin