Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:18:10Zhttps://develop.openfoam.com/Development/openfoam/-/issues/695COMP: incorrect executable path2019-12-09T22:18:10ZPrashant SonakarCOMP: incorrect executable pathhttps://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/applications/solvers/finiteArea/sphereSurfactantFoam/Make/files points to USER area and not standard APPBIN
@andy @markhttps://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/applications/solvers/finiteArea/sphereSurfactantFoam/Make/files points to USER area and not standard APPBIN
@andy @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/694Improvements to turbulence decay control2019-12-09T22:18:09ZAdminImprovements to turbulence decay controlAs noted here: https://develop.openfoam.com/Development/OpenFOAM-plus/commit/82a4b88c2fc06b9c45f0d21ca3da265acc8790f8#note_5497 by @hikassem the decay control code could benefit from a couple of updatesAs noted here: https://develop.openfoam.com/Development/OpenFOAM-plus/commit/82a4b88c2fc06b9c45f0d21ca3da265acc8790f8#note_5497 by @hikassem the decay control code could benefit from a couple of updatesAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/693incorrect implementation of jumpCyclic BC2018-03-14T17:24:39ZAdminincorrect implementation of jumpCyclic BCbegin at line 94 of jumpCyclicFvPatchField.C
```c++
template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
const Field<Type>& iField = this->primitiveField();
const lab...begin at line 94 of jumpCyclicFvPatchField.C
```c++
template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
const Field<Type>& iField = this->primitiveField();
const labelUList& nbrFaceCells =
this->cyclicPatch().neighbFvPatch().faceCells();
tmp<Field<Type>> tpnf(new Field<Type>(this->size()));
Field<Type>& pnf = tpnf.ref();
Field<Type> jf(this->jump());
if (!this->cyclicPatch().owner())
{
jf *= -1.0;
}
if (this->doTransform())
{
forAll(*this, facei)
{
pnf[facei] = transform
(
this->forwardT()[0], iField[nbrFaceCells[facei]]
) - jf[facei];
}
}
else
{
forAll(*this, facei)
{
pnf[facei] = iField[nbrFaceCells[facei]] - jf[facei];
}
}
return tpnf;
}
```
Mathematically, jumpCyclic BC must enforce the jump condition between patch faces. However, in the implementation, it seems that the jump condition are enforced between the inner cell and neighbour cells, which is obviously incorrect.https://develop.openfoam.com/Development/openfoam/-/issues/692add additional information in header of decomposedBlockData2024-01-10T16:23:36ZMark OLESENadd additional information in header of decomposedBlockDataWe already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
...We already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
format binary;
class decomposedBlockData;
blocks 4;
object U;
dataClass volVectorField;
}
At the moment it is a bit of a pain to get at this information.
Would it be useful to have this dataClass information present as `IOobject::headerDataClassName()` with it being identical to `IOobject::headerClassName()` when `dataClass` isn't present?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/691A truer warning statement in oversetFvPatchField.C2018-01-22T16:16:40ZKutalmış BerçinA truer warning statement in oversetFvPatchField.CHi,
Consider the following code fragment under `oversetFvPatchField.C`:
```
161 else if
162 (
163 !fvSchemes.found("oversetInterpolation")
164 || !fvSchemes.found("oversetInterpolationRequired")...Hi,
Consider the following code fragment under `oversetFvPatchField.C`:
```
161 else if
162 (
163 !fvSchemes.found("oversetInterpolation")
164 || !fvSchemes.found("oversetInterpolationRequired")
165 )
166 {
167 IOWarningInFunction(fvSchemes)
168 << "Missing required dictionary entries"
169 << " 'oversetInterpolation' and 'oversetInterpolationRequired'"
170 << ". Skipping overset interpolation for field "
171 << fldName << endl;
172 }
```
IMHO, "**and**" in line 169 needs to be changed to "**or**", considering "**||**" in line 164.
Many thankshttps://develop.openfoam.com/Development/openfoam/-/issues/690Bug: Missing crystal-clear warning for the requirement of bash >= 4.2 to enab...2019-01-08T17:20:22ZKutalmış BerçinBug: Missing crystal-clear warning for the requirement of bash >= 4.2 to enable bash shell completionHi,
Thanks to @wyldckat's insight in the following communication: https://www.cfd-online.com/Forums/openfoam-bugs/197310-possible-missing-tab-completion-ofv1712.html , it seems that a user, who uses **bash --version** below 4.2, may exp...Hi,
Thanks to @wyldckat's insight in the following communication: https://www.cfd-online.com/Forums/openfoam-bugs/197310-possible-missing-tab-completion-ofv1712.html , it seems that a user, who uses **bash --version** below 4.2, may experience the lack of bash shell completion functionality for the **options** of OpenFOAM commands in version 1712 (yet not the completion for after OF commands, such as `transformPoints -help > **system/log** (the bold part seems to be tab-completed)`. Moreover, this requirement was not stated in https://openfoam.com/documentation/system-requirements.php .
Quoting @wyldckat, under **etc/config.sh/bash_completion**, the following piece of code is leading to the alleged issue:
```
[...]
# Bash version is too old.
## echo "No bash completions - requires bash >= 4.2" 1>&2
unset -f foamAddCompletion 2>/dev/null
foamAddCompletion()
{
echo "foamAddCompletion disabled - requires bash >= 4.2" 1>&2
}
unset -f _of_complete_ 2>/dev/null
fi
```
Directly quoting @wyldckat:
> It's a bug in this part of the script and they forgot to document about this limitation. They left the line "No bash completions - requires bash >= 4.2" commented out, which means that there is no visual indication that your bash version 4.1.2 is not supported.
Many thanks for your excellent work.
PS: IMHO, This might be important for those who use OpenFOAM in a cluster whilst they may not able to update bash version due to inavailable root access.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/689overPimpleDyMFoam with pressure reference2018-06-08T23:51:12ZAdminoverPimpleDyMFoam with pressure referenceWhile running the tutorial case simpleRotor I noticed an issue with the pressure reference for closed domains. It is clearly visible which point is chosen as the reference point. A velocity which should not exist appears in that corner. ...While running the tutorial case simpleRotor I noticed an issue with the pressure reference for closed domains. It is clearly visible which point is chosen as the reference point. A velocity which should not exist appears in that corner. Also the pressure fluctuates like crazy. Turning on adjustPhi or oversetAdjustPhi did not help. Tested with v1706 and v1712.https://develop.openfoam.com/Development/openfoam/-/issues/688cfMesh : tutorial failing2018-01-08T15:20:10ZPawan GhildiyalcfMesh : tutorial failingHi Mark
@andy @Prashant @Mattijs
I noticed that cfMesh tutorial is failing with latest dev branch . It is happening for all tutorial
i tested. Prashant mentioned that commit of Dec 18 is working fine but with Dec 21
commit, he is...Hi Mark
@andy @Prashant @Mattijs
I noticed that cfMesh tutorial is failing with latest dev branch . It is happening for all tutorial
i tested. Prashant mentioned that commit of Dec 18 is working fine but with Dec 21
commit, he is also seeing this issue.
See log below for this case
cartesianMesh/asmoOctree
>
> Current cell 53393
> --> FOAM FATAL ERROR:
> 0Face 138577 appears in more than 2 cells!!0Face 140334 appears in more than 2 cells!!
> From function --> FOAM FATAL ERROR:
> virtual void Foam::Module::polyMeshGenCells::calculateOwnersAndNeighbours() const
> 0Face 138577 appears in more than 2 cells!!0Face 140334 appears in more than 2 cells!!
> in file utilities/meshes/polyMeshGen/polyMeshGenCells.C at line 147.
>
> FOAM aborting
>
> From function
> virtual void Foam::Module::polyMeshGenCells::calculateOwnersAndNeighbours() const
> in file utilities/meshes/polyMeshGen/polyMeshGenCells.C at line 147.
>
> FOAM aborting"Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/687foamToVTK requires system/faSchemes2017-12-30T21:27:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK requires system/faSchemesfoamToVTK on any case:
--> FOAM FATAL ERROR:
cannot find file ".../system/faSchemes"
(foamToEnsight is ok)
foamToVTK on any case:
--> FOAM FATAL ERROR:
cannot find file ".../system/faSchemes"
(foamToEnsight is ok)
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/686distributedTriSurfaceMesh hangs with motorBike2019-01-09T09:06:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistributedTriSurfaceMesh hangs with motorBikeChange motorBike tutorial to use distributedTriSurfaceMesh (see attached snappyHexMeshDict)
[snappyHexMeshDict](/uploads/92dd12940023efa4669d8d5c98d4bb74/snappyHexMeshDict)
- hangs in surfaceRedistributePar when using collated format
-...Change motorBike tutorial to use distributedTriSurfaceMesh (see attached snappyHexMeshDict)
[snappyHexMeshDict](/uploads/92dd12940023efa4669d8d5c98d4bb74/snappyHexMeshDict)
- hangs in surfaceRedistributePar when using collated format
- hangs in snappyHexMesh when using uncollated formatMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/685BUG: incorrect dimensions for pressureTools2017-12-30T21:27:47ZPrashant SonakarBUG: incorrect dimensions for pressureToolsThe attached case replicates the issue.
- dimensions are incorrect for second iteration.
[cavity.tgz](/uploads/484b28a50405eb27e12492834fb953fb/cavity.tgz)
@Sergio @andy @MattijsThe attached case replicates the issue.
- dimensions are incorrect for second iteration.
[cavity.tgz](/uploads/484b28a50405eb27e12492834fb953fb/cavity.tgz)
@Sergio @andy @Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/684alphatJayatillekeWallFunction "k field not found" issue for the SpalartAllmar...2018-03-14T17:25:48ZAdminalphatJayatillekeWallFunction "k field not found" issue for the SpalartAllmaras turbulence modelHi, I am testing buoyantBoussinesqSimpleFoam using the tutorial case: hotRoom. I noticed that the alphatJayatillekeWallFunction (for the alphat field) implementation requires k field which is not provided in the SpalartAllmaras turbulenc...Hi, I am testing buoyantBoussinesqSimpleFoam using the tutorial case: hotRoom. I noticed that the alphatJayatillekeWallFunction (for the alphat field) implementation requires k field which is not provided in the SpalartAllmaras turbulence model.
Basically, if you run the case I uploaded, you can see warnings: "k field not found, return 0" in the flow log. I then checked the alphat wall values which were **all zeros (not right!)**.
If I run the hotRoom case with the default kEpsilon model, the alphat wall field values are right.
Could you please look up the problem? Thanks very much in advance!
[hotRoom.tar.gz](/uploads/238ca977ab5a08d3eca226def3d17852/hotRoom.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/683lumpedPointMotion/building/steady Allclean does not remove surface2018-07-16T21:29:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlumpedPointMotion/building/steady Allclean does not remove surfaceAfter ./Allclean the constant/triSurface/building_wtc2.obj is still present.After ./Allclean the constant/triSurface/building_wtc2.obj is still present.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/682COMP : missing make files for heatTransferCoeff function object2017-12-28T04:51:51ZAdminCOMP : missing make files for heatTransferCoeff function objectMissing
heatTransferCoeff/heatTransferCoeff.C
heatTransferCoeff/heatTransferCoeffModels/fixedReferenceTemperature/fixedReferenceTemperature.C
heatTransferCoeff/heatTransferCoeffModels/localReferenceTemperature/localReferenceTemperature...Missing
heatTransferCoeff/heatTransferCoeff.C
heatTransferCoeff/heatTransferCoeffModels/fixedReferenceTemperature/fixedReferenceTemperature.C
heatTransferCoeff/heatTransferCoeffModels/localReferenceTemperature/localReferenceTemperature.C
heatTransferCoeff/heatTransferCoeffModels/heatTransferCoeffModel/heatTransferCoeffModelNew.C
heatTransferCoeff/heatTransferCoeffModels/heatTransferCoeffModel/heatTransferCoeffModel.C
heatTransferCoeff/heatTransferCoeffModels/ReynoldsAnalogy/ReynoldsAnalogy.C
in Make/files
@andyhttps://develop.openfoam.com/Development/openfoam/-/issues/681Feature: Possibility for the concurrent usage of multiple subsetFeatures in s...2020-01-03T11:28:59ZKutalmış BerçinFeature: Possibility for the concurrent usage of multiple subsetFeatures in surfaceFeatureExtractDictConsider the OpenFOAM-v1706 tutorial: `/tutorials/mesh/foamyHexMesh/mixerVessel`
Therein, the feature lines of `shaftRotating.stl` were extracted and subsetted via the following group of entries in `surfaceFeatureExtractDict`:
```
subs...Consider the OpenFOAM-v1706 tutorial: `/tutorials/mesh/foamyHexMesh/mixerVessel`
Therein, the feature lines of `shaftRotating.stl` were extracted and subsetted via the following group of entries in `surfaceFeatureExtractDict`:
```
subsetFeatures
{
// Remove the top feature
insideBox (-0.1 -0.1 -0.1)(0.1 0.1 0.1);
}
```
Say, the user required not to remove (or remove) some other features in the same .stl file. To this end, IMHO, the user likely adds another `subsetFeatures` entry by intuition. Let add another box into the tutorial's entry, so that it can readily be reproduced:
```
subsetFeatures
{
// Remove all other features apart from the top and bottom features
insideBox (-0.1 -0.1 -0.1)(0.1 0.1 0.1);
insideBox (-0.1 -0.1 0.8)(0.1 0.1 1);
}
```
Yet the execution of `surfaceFeatureExtract` yields the consideration of **only** the latter box. The output stream is:
```
...
Subset edges inside box (-0.1 -0.1 0.8) (0.1 0.1 1)
...
```
In addition, the simultaneous usage of different entries seems also not possible. For example, when the user enters `insideBox` and `outsideBox` entries under the same `subsetFeatures`, the `insideBox` seems overriding the `outsideBox` entry irrespective of the order of entry sequence.
I found a workaround to subset features from several regions on the same surface mesh, yet this requires sequential command executions. For instance, if one wants to remove/add features from two different locations on the same surface mesh, the person can extract the first region through `surfaceFeatureExtract` with a single `subsetFeature`. Then, the resulted '.eMesh' files can be used to extract features in the second region through another `surfaceFeatureExtract`, however, this time using `extractionMethod extractFromFile;` with another `subsetFeature`, and so on.
IMHO, from a user perspective, a simultaneous surface feature extraction, which may need to consider multiple region restrictions for some reason, might be facilitative.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/680decomposition fails with faMesh2017-12-22T11:54:11ZMark OLESENdecomposition fails with faMeshRunning the wolfsgrube avalanche tutorial. Decomposing with 4 proc OK.
Decomposing with hierarchical (4 4 1)
--> FOAM FATAL ERROR:
Impossible processor label 757738797for face 8
From function Finite area mesh decompositio...Running the wolfsgrube avalanche tutorial. Decomposing with 4 proc OK.
Decomposing with hierarchical (4 4 1)
--> FOAM FATAL ERROR:
Impossible processor label 757738797for face 8
From function Finite area mesh decomposition
in file faMeshDecomposition.C at line 223.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/679redistributePar fails for faMesh2020-01-07T16:32:23ZMark OLESENredistributePar fails for faMeshv1806Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/678fftw compile problem in single-precision2017-12-21T15:59:45ZMark OLESENfftw compile problem in single-precisionv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/677Medium loop- failures - 21.12.20172018-06-12T04:01:04ZPrashant SonakarMedium loop- failures - 21.12.2017Cases in :
/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/
- compressible/sonicFoam/RAS/nacaAirfoil - solver failed
- multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection - solver failed
- multiphase/compressibleInt...Cases in :
/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/
- compressible/sonicFoam/RAS/nacaAirfoil - solver failed
- multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection - solver failed
- multiphase/compressibleInterDyMFoam/laminar/sphereDrop -solver failed
- multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection -solver failed
@andy @Mattijs @Sergio @markhttps://develop.openfoam.com/Development/openfoam/-/issues/676label64 with FULLDEBUG gives problems2018-01-17T13:27:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlabel64 with FULLDEBUG gives problemsWhen doing WM_LABEL_SIZE=64 and WM_COMPILE_OPTION=Debug there is a problem in reading even the initial controlDict. This traces back to UIPstream::readStringFromBuffer where it tries to read zero bytes from the current pointer (&external...When doing WM_LABEL_SIZE=64 and WM_COMPILE_OPTION=Debug there is a problem in reading even the initial controlDict. This traces back to UIPstream::readStringFromBuffer where it tries to read zero bytes from the current pointer (&externalBuf_[externalBufPosition_]).
If that pointer points to one-beyond the end of the buffer the call will fail.
Workaround: do not use pointer in case of zero bytes. Note that it only affects the fulldebug checking; the library routine handles it ok.
E.g.
inline Foam::Istream& Foam::UIPstream::readStringFromBuffer(std::string& str)
{
// Use std::string::assign() to copy content, including '\0'.
// Stripping (when desired) is the responsibility of the sending side.
size_t len;
readFromBuffer(len);
if (len == 0)
{
str.assign(nullptr, len);
}
else
{
str.assign(&externalBuf_[externalBufPosition_], len);
}