Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:18:11Zhttps://develop.openfoam.com/Development/openfoam/-/issues/830compilation with IntelMPI failed2019-12-09T22:18:11ZPawan Ghildiyalcompilation with IntelMPI failedUsing ThirdParty compiler Gcc64 and pointing to MPI_ROOT path to intelMPI
complain about mpi.h not found during compilation of src/Pstream and src/parallel/decompose/ptscotchDecomp
"sinclude $(GENERAL_RULES)/mplib$(WM_MPLIB)"
"sin...Using ThirdParty compiler Gcc64 and pointing to MPI_ROOT path to intelMPI
complain about mpi.h not found during compilation of src/Pstream and src/parallel/decompose/ptscotchDecomp
"sinclude $(GENERAL_RULES)/mplib$(WM_MPLIB)"
"sinclude $(RULES)/mplib$(WM_MPLIB)"
Solution: **Mark** pointed out following need to be added to fix this issue
"sinclude $(DEFAULT_RULES)/mplib$(WM_MPLIB)"
Regards
PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1234add wmake rules for PGI compiler2019-04-26T08:09:16ZMark OLESENadd wmake rules for PGI compilerMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1044Add lagrangianTools functionality to develop branch2018-11-24T14:58:40ZRoger AlmenarAdd lagrangianTools functionality to develop branchIs it possible to add the functionality available under lagrangianTools to the develop branch, towards release with v1812?Is it possible to add the functionality available under lagrangianTools to the develop branch, towards release with v1812?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/525ENH: moving average with exact terms in window2018-03-07T14:55:05ZPrashant SonakarENH: moving average with exact terms in windowRefer EP#430Refer EP#430v1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/585paraview reader module only handles information from first cloud2017-09-12T13:58:38ZMark OLESENparaview reader module only handles information from first cloud@andy @andy v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/614runnning with dummy Pstream library does not have pthread dependency2020-04-06T10:37:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrunnning with dummy Pstream library does not have pthread dependencyFor now add it to dummy/Pstream dependency (since libOSspecific is not a shared library)For now add it to dummy/Pstream dependency (since libOSspecific is not a shared library)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/586paraview reader attempts to shallow copy nullptr2017-09-12T13:58:30ZMark OLESENparaview reader attempts to shallow copy nullptrCan occur if the selected geometry does not actually exist, but treat as a non-critical bug since paraview catches this anyhow and just emits a warning message.Can occur if the selected geometry does not actually exist, but treat as a non-critical bug since paraview catches this anyhow and just emits a warning message.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/564mismatch in send/receive sizes of int32/int642021-07-06T12:05:23ZMark OLESENmismatch in send/receive sizes of int32/int64I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LAB...I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LABEL_SIZE). It would seem to be the same for int64, but we probably haven't been sending those about too much in that form.
@andy @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1011odd behaviour in bash completions2018-09-19T19:00:25ZMark OLESENodd behaviour in bash completionsCould be a bash bug or something else. With a local copy of foamToVTK with a `-legacy` option, the completion function triggers a syntax error.
```
foamToVTK -le<TAB>
```
Results in
```
foamToVTK -lebash: [: -n: integer expression expec...Could be a bash bug or something else. With a local copy of foamToVTK with a `-legacy` option, the completion function triggers a syntax error.
```
foamToVTK -le<TAB>
```
Results in
```
foamToVTK -lebash: [: -n: integer expression expected
gacy
```
The offending line is this one in bash_completion:
```
elif [ -n "$cur" -a "${cur#-}" = "${cur}" ]
then
# Already started a (non-empty) word that isn't an option
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/367BUG: fieldAveraging write conflict with timeEnd2019-12-09T21:29:27ZPrashant SonakarBUG: fieldAveraging write conflict with timeEndAttached example illustrating the issue.
- The end time written from solver doesn't contain pMean field
- If we try commenting timeEnd entry from averaging FO, the field is written well.
[pitzDaily_averageFields_pimpleFoam.tgz](/uploa...Attached example illustrating the issue.
- The end time written from solver doesn't contain pMean field
- If we try commenting timeEnd entry from averaging FO, the field is written well.
[pitzDaily_averageFields_pimpleFoam.tgz](/uploads/3448d7e0d4738368f79fac7e05929290/pitzDaily_averageFields_pimpleFoam.tgz)
@mark @MattijsVersion v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/517reduce the size of the environment2020-05-06T07:59:51ZMark OLESENreduce the size of the environmentMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/345dictionary variable expansion broken?2021-07-06T10:55:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdictionary variable expansion broken?Trying to do fancy things:
[dynamicMeshDict](/uploads/546b7109c94f93c4ebf1340698f6da81/dynamicMeshDict)
behaves different in v1606+ and plus.develop.Trying to do fancy things:
[dynamicMeshDict](/uploads/546b7109c94f93c4ebf1340698f6da81/dynamicMeshDict)
behaves different in v1606+ and plus.develop.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/427topoSet: nearestToCell, nearestToPoint return nearest on each processor inste...2018-05-03T18:08:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtopoSet: nearestToCell, nearestToPoint return nearest on each processor instead of overall nearestMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/547bad range check for foamHelp (SEGFAULT)2019-12-09T22:11:26ZMark OLESENbad range check for foamHelp (SEGFAULT)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/6Missing documentation: porosity in force/coefficient FO2023-08-19T21:13:19ZPrashant SonakarMissing documentation: porosity in force/coefficient FO@andy @Mattijs
Add details about porosity in Header files in $src/postProcessing/functionObjects/forces@andy @Mattijs
Add details about porosity in Header files in $src/postProcessing/functionObjects/forcesFunctionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/256remove unneeded lines in list binary output.2017-07-03T07:20:58ZMark OLESENremove unneeded lines in list binary output.Writing an empty list in binary results in unnecessary newlines.Writing an empty list in binary results in unnecessary newlines.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/503DOCU: inconsistent documentation for pressure FO2017-06-19T19:42:59ZPrashant SonakarDOCU: inconsistent documentation for pressure FOHeader file mentions keywords pRef optional with default value = 0.
However, this becomes compulsory with dictLookup entry.
Should either be modified to make it consistent (or state conditions when it is required)?
```
Property | ...Header file mentions keywords pRef optional with default value = 0.
However, this becomes compulsory with dictLookup entry.
Should either be modified to make it consistent (or state conditions when it is required)?
```
Property | Description | Required | Default value
pRef | Reference pressure | for total pressure | 0
pInf | Freestream pressure | for coefficient calculation |
```Version v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/217Missing bracket closure in "doc/Doxygen/css/doxyMod.css" leads to broken code...2019-12-09T22:04:10ZAdminMissing bracket closure in "doc/Doxygen/css/doxyMod.css" leads to broken code flow in DoxygenThe missing bracket closure in , for which a fix is provided in the patch below, will fix the current issue that occurs in the included source code files that are rendered with Doxygen.
For example, [this page for `temperatureCoupledB...The missing bracket closure in , for which a fix is provided in the patch below, will fix the current issue that occurs in the included source code files that are rendered with Doxygen.
For example, [this page for `temperatureCoupledBase.C`](http://openfoam.com/documentation/cpp-guide/html/a11262_source.html), as we can also see in the image below (left is the current result for the unfixed file, on the right when the fix is implemented), is not using the correct format for ensuring the verbatim render for the source code lines:
![Before_vs_after](/uploads/c951efe7dfc4406cf086283784f4fb72/Before_vs_after.png)
The patch for fixing this is as follows:
```
diff --git a/doc/Doxygen/css/doxyMod.css b/doc/Doxygen/css/doxyMod.css
index 46ac2df..fbb968f 100644
--- a/doc/Doxygen/css/doxyMod.css
+++ b/doc/Doxygen/css/doxyMod.css
@@ -118,6 +118,8 @@ tr.memlist
.OFPlainTable tr td {
height: 20px;
padding-left: 5px;
+}
+
div.line,
span.comment,
span.keyword,
```
In addition, this can easily be used to fix the current file that is located at http://openfoam.com/documentation/cpp-guide/css/doxyMod.cssAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1143reconstructPar crashes with cyclicAMI2020-11-13T09:25:15ZAdminreconstructPar crashes with cyclicAMIIn a case using cyclicAMI to make the grid periodic across two patches, the simulation runs successfully but crashes when trying to reconstruct the solution at the end of the parallel run, giving the following error:
AMI: Creating addre...In a case using cyclicAMI to make the grid periodic across two patches, the simulation runs successfully but crashes when trying to reconstruct the solution at the end of the parallel run, giving the following error:
AMI: Creating addressing and weights between 66 source faces and 45 target faces
--> FOAM Warning :
From function void Foam::AMIMethod<SourcePatch, TargetPatch>::checkPatches() const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double>> &, Foam::Vector<double>>, TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double>> &, Foam::Vector<double>>]
in file lnInclude/AMIMethod.C at line 57
Source and target patch bounding boxes are not similar
source box span : (0.05 0 0.001)
target box span : (0.0449116 0 0.001)
source box : (-0.05 -0.00965 -0.0015) (1.92091e-11 -0.00965 -0.0005)
target box : (-0.05 -0.00965 -0.0015) (-0.00508841 -0.00965 -0.0005)
inflated target box : (-0.0522461 -0.0118961 -0.00374614) (-0.00284227 -0.00740386 0.00174614)
The same case works fine with an older grid differing only by few cells in the total count.
Please also note this issue has been reported but not solved here:
https://bugs.openfoam.org/view.php?id=1234
and discussed here on CFD online:
https://www.cfd-online.com/Forums/openfoam-solving/100325-problems-using-reconstructpar-case-involving-ami.html
The issue has been tested and rises with both the v1806 and v1606 releases.
\## Reattaching the author to the issue ticket: @Ricky\-11 ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1006foamNewSource missing libraries in Make/options2019-12-09T22:22:46ZAdminfoamNewSource missing libraries in Make/optionsThe following will fail:
```
cd $WM_PROJECT_USER_DIR
mkdir -p applications/solvers/electromagnetics/rodFoam
cd applications/solvers/electromagnetics/rodFoam
foamNewSource App rodFoam
sed -i s/FOAM_APPBIN/FOAM_USER_APPBIN/g Make/files
wma...The following will fail:
```
cd $WM_PROJECT_USER_DIR
mkdir -p applications/solvers/electromagnetics/rodFoam
cd applications/solvers/electromagnetics/rodFoam
foamNewSource App rodFoam
sed -i s/FOAM_APPBIN/FOAM_USER_APPBIN/g Make/files
wmake
```
Error message:
```
$FOAM_SRC/finiteVolume/lnInclude/cyclicAMIFvPatch.H:39:10: fatal error: cyclicAMILduInterface.H: No such file or directory
#include "cyclicAMILduInterface.H"
^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
It will compile if I manually add meshTools in Make/options. However, I think it would be nice of the template is at a state that allows it to be compiled without manual modifications.