Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-06-08T20:33:33Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2076planned changes to geometricVoF2021-06-08T20:33:33ZHenning Scheuflerplanned changes to geometricVoFAs hinted in issue #1955, we (@johan_roenby and me) are planning to update the geometricVoF code and unify it with our open-source release:
https://arxiv.org/abs/2103.00870
https://github.com/DLR-RY/twophaseflow
This step will signific...As hinted in issue #1955, we (@johan_roenby and me) are planning to update the geometricVoF code and unify it with our open-source release:
https://arxiv.org/abs/2103.00870
https://github.com/DLR-RY/twophaseflow
This step will significantly reduce our time spent maintaining both codes and should raise the code quality of both releases. This would also signficantly simplify testing the library for us.
Currently, the libraries are almost identical and the only feature added is the capability to run interIsoFoam with AMR. In this process, smaller changes to the comments are also planned.
Would you support this approach?
if so, I would create a new branch so we can merge into develop later
@kuti @andy @markv2106Henning ScheuflerHenning Scheuflerhttps://develop.openfoam.com/Development/openfoam/-/issues/2077Missing "make" causes misleading error about missing C++ compiler rule2021-06-18T16:58:25ZMichael BazarewskyMissing "make" causes misleading error about missing C++ compiler rule### Summary
In the event that wmake is installed but make is not (eg in the case of a binary installation on a very clean cloud server environment), RunFunctions incorrectly reports that there is no rule for C++ compilation. This is du...### Summary
In the event that wmake is installed but make is not (eg in the case of a binary installation on a very clean cloud server environment), RunFunctions incorrectly reports that there is no rule for C++ compilation. This is due to the code not validating the existence of "make".
### Steps to reproduce
On an Ubuntu system that does not have make installed but does have the 2012 binaries installed and the proper PATH configuration, attempt to Allrun one of the tutorials.
The real cause can be seen if you `sh -x ./Allrun` and note the "swallowed" error from wmake that is exposed.
### Example case
### What is the current *bug* behaviour?
"missing C++ rule, cannot compile" error
### What is the expected *correct* behavior?
"No make command found ... cannot compile"
### Relevant logs and/or images
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : ubuntu
- Hardware info : n/a
- Compiler : gcc
### Possible fixes
This can be fixed by adding the following at or about [line 67](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/tools/RunFunctions#L67) (that's the correct place as of when I'm submitting this) of RunFunctions:
```
if ! command -v make > /dev/null
then
echo "No make command found ... cannot compile" 1>&2
return 1
fi
```https://develop.openfoam.com/Development/openfoam/-/issues/2078Crash with dynamicMotionSolverFvMeshAMI2024-01-10T10:57:24ZDavid HoraCrash with dynamicMotionSolverFvMeshAMIHi all
I wanted to test the dynamicMotionSolverFvMeshAMI but my simulation of a centrifugal fan crashes immediately because of an unallocated autoPtr. The case has 9.3 million cells and consists of an impeller and a volute. The simulati...Hi all
I wanted to test the dynamicMotionSolverFvMeshAMI but my simulation of a centrifugal fan crashes immediately because of an unallocated autoPtr. The case has 9.3 million cells and consists of an impeller and a volute. The simulation is a restart from a dynamicMotionSolverFvMesh simulation where two revolutions were calculated without problems. Unfortunately I can't reproduce it with a smaller case. I hope the log file helps. Otherwise let me know if you need more information.
Kind regards
David
[pimpleFoam_rerun.log](/uploads/0a899b9c446f6fd1bade038e6d63546f/pimpleFoam_rerun.log)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2079change location of "static" ensight geometry2021-05-28T12:16:15ZMark OLESENchange location of "static" ensight geometryLooking at adding in multi-region support for foamToEnsight (#2080) and we have a slight chance of name collisions if someone happens to have a region called "data" or "geometry", since these are reserved names in our EnSight output.
Wa...Looking at adding in multi-region support for foamToEnsight (#2080) and we have a slight chance of name collisions if someone happens to have a region called "data" or "geometry", since these are reserved names in our EnSight output.
Was thinking that `geometry` should become `data/constant/geometry`, by inserting a _constant_ data sub-directory.
Any concerns about this affecting workflows etc, or any other thoughts?
@andy @Mattijs @Sergio @kuti @Prashant @Pawan @chiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2080add multi-region support for foamToEnsight2021-07-08T07:05:25ZMark OLESENadd multi-region support for foamToEnsightMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2081add support for volume expressions in fvOptions2021-04-29T15:54:49ZMark OLESENadd support for volume expressions in fvOptionsTopic raised in EP1558.
Seems reasonable to add, but will want a different type, or an additional keyword to distinguish between "regular" expression evaluations (which result in a single-element field) and ones that have access to the ...Topic raised in EP1558.
Seems reasonable to add, but will want a different type, or an additional keyword to distinguish between "regular" expression evaluations (which result in a single-element field) and ones that have access to the entire volume.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2082DEShybrid leads to crash for single and mixed precision versions of OpenFOAM2021-06-10T09:01:50ZHendrik HetmannDEShybrid leads to crash for single and mixed precision versions of OpenFOAM<!--
*** 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 -->
OpenFOAM crashes if using the DEShybrid blending scheme with single (SP) or mixed precision (SPDP) compilation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Compile OpenFOAM in single or mixed precision mode. Run any case with DEShybrid blending scheme for div(phi,U).
### 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
-->
pitzDaily with SA-DDES and DEShybrid blending scheme
[DEShybrid_pitzDaily.tar.gz](/uploads/784a1c6c92f877792108b1d972745bf2/DEShybrid_pitzDaily.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
OpenFOAM crashes.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No crash :-)
### 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.
-->
```
Starting time loop
fieldAverage fieldAverage1:
Restarting averaging for fields:
U: starting averaging at time 0
p: starting averaging at time 0
Sampled surface:
nearWall -> vtk
Time = 1e-05
Courant Number mean: 8.74894e-05 max: 0.0315889
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libc.so.6
#3 Foam::pow(Foam::Field<float>&, Foam::UList<float> const&, float const&) at ??:?
#4 Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> > Foam::pow<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensioned<float> const&) at ??:?
#5 Foam::tmp<Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> > Foam::pow<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&, float const&) at ??:?
#6 Foam::DEShybrid<Foam::Vector<float> >::calcBlendingFactor(Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#7 Foam::DEShybrid<Foam::Vector<float> >::blendingFactor(Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#8 Foam::DEShybrid<Foam::Vector<float> >::weights(Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#9 Foam::fv::gaussConvectionScheme<Foam::Vector<float> >::fvmDiv(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#10 Foam::fv::boundedConvectionScheme<Foam::Vector<float> >::fvmDiv(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#11 ? at ??:?
#12 ? at ??:?
#13 __libc_start_main in /lib64/libc.so.6
#14 ? at /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:122
Gleitkomma-Ausnahme (Speicherabzug geschrieben)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system : openSUSE 15.1
- Hardware info :
- Compiler : gcc7
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2083remove/deprecate construct list from two iterators2021-07-15T16:54:40ZMark OLESENremove/deprecate construct list from two iteratorsThere are different two-parameter forms when constructing a `List`, notably these:
```
List(const label len, const T& val);
List(const UList<T>& list, const labelUList& indices);
template<class InputIterator>
List(InputIterator begIter...There are different two-parameter forms when constructing a `List`, notably these:
```
List(const label len, const T& val);
List(const UList<T>& list, const labelUList& indices);
template<class InputIterator>
List(InputIterator begIter, InputIterator endIter)
```
This typically causes compilation issues with 64-bit labels, eg,
```
bad: labelList test(5, 0);
good: labelList test(label(5), 0);
good: labelList test(5, Zero);
```
otherwise the two-iterator constructor masks everything.
In the past, this has prompted both the removal (c43b78e8de830a327409a0449400e6decc9488f4) and the reinstatement (d01eb45cfc5936d337bafd93d7ed1370d26586b9) of this constructor, even if the problem was never resolved.
Although we generally deal with the problem by properly casting the arguments, still cannot unmask the mapping constructor.
For example,
```
labelList allValues = ...;
labelList indices = ...;
labelList myValues(allValues, indices); -> Error bad iterator pair!!
```
Although this mapping lookup works with Field and most other types of List, it will not work for a `labelList`.
This leads to this type of code:
```
callFunction(labelList(UIndirectList<label>(allValues, indices)));
```
vs
```
callFunction(labelList(allValues, indices));
```
Propose once again removing the construct from iterator pair and/or replace with a tagged version. For example,
```
template<class InputIterator>
List(std::piecewise_construct, InputIterator begIter, InputIterator endIter)
```
Open to suggestions for better dispatch tags.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2084missing decomposition constraint for finite-area2021-11-05T18:07:40ZMark OLESENmissing decomposition constraint for finite-arearaised during discussion with @Mattijs - the outside perimeter of a finiteArea **can** be split on a processor boundary. This means loss of the BC and replacement with a bad processor definition.
@Sergioraised during discussion with @Mattijs - the outside perimeter of a finiteArea **can** be split on a processor boundary. This means loss of the BC and replacement with a bad processor definition.
@SergioMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2085snappyHexMesh bumps (bulges) when using different refinementSurfaces levels2024-02-22T12:54:44ZNikola MajksnersnappyHexMesh bumps (bulges) when using different refinementSurfaces levels
### Summary
When using different `refinementSurfaces` levels, for example `5 6`, mesh gets bumps (bulges) and while possible to get rid of them by changing `minTetQuality` to `-1e+30` that change makes CFD very unstable and in most cas...
### Summary
When using different `refinementSurfaces` levels, for example `5 6`, mesh gets bumps (bulges) and while possible to get rid of them by changing `minTetQuality` to `-1e+30` that change makes CFD very unstable and in most cases results in a crash.
* Bumps mainly appear when reducing skewness from `20 4` to `4 2` and lower. Leaving skewness high again comes at the cost of stability during the run.
* Bumps often occur at the transition from one refinement level to another
* The bumps go away when using the same refinement level everywhere on the surface but that eliminates the possibility for local refinement
### Steps to reproduce
Run attached case and open Paraview, and you'll see bumps the top of the wind shield.
### Example case
See attached
### What is the current *bug* behaviour?
Bumps appear at the transition from one refinement level to another
### What is the expected *correct* behaviour?
Bumps should not be appearing on the surface when using different refinement levels
### Relevant logs and/or images
This image shows bumps for `maxBoundarySkewness 20` `maxInternalSkewness 4` which is default value
![aquilo_bumps](/uploads/072126393b21ff9425413028bf49db26/aquilo_bumps.png)
Using `maxBoundarySkewness 2` `maxInternalSkewness 2` bumps are even more pronounced
![aquilo_bumps_2_2](/uploads/10724548283e97966707913d7081c91a/aquilo_bumps_2_2.png)
### Environment information
- Operating system : Ubuntu 20.04
- OpenFOAM version : 2012
- Hardware info : AMD EPYC 7401P 24-Core Processor
- Compiler : GCC
### Possible fixes
* Increase skewness (to the default values of 20 4) (but reduces solver stability)
* set minTetquality to -1e+30 (but reduces solver stability significantly)
[bumps.zip](/uploads/1728cad11bd29c4840e2ef185c2e039b/bumps.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2088blockMesh fails when mergePatchPairs is used and regions are declared2021-05-21T07:57:54ZMark YobbblockMesh fails when mergePatchPairs is used and regions are declared<!--
*** 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 -->
When using mergePatchPairs in blockMeshDict, blockMesh fails only when regions are declared as part of a block declaration with hex.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Author a blockMeshDict file with 3 blocks that share common planes. Declare patches for two of the adjacent blocks. Use mergePatchPairs to merge the patches together. In the hex declaration assign a region name to any one of the blocks. blockMesh fails even if the region defined is not associated with a merged block. (That is why I indicated 3 blocks above.)
### 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
-->
I am attaching a sample case that I made to trouble shoot the problem I was having.
### What is the current *bug* behaviour?
The bug behavior is that blockMesh fails to complete and outputs the following messasge:
```
--> FOAM FATAL ERROR: (openfoam-2012)
point, face or cell zone already exists
From void Foam::polyMesh::addZones(const Foam::List<Foam::pointZone*>&, const Foam::List<Foam::faceZone*>&, const Foam::List<Foam::cellZone*>&)
in file meshes/polyMesh/polyMesh.C at line 1007.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::polyMesh::addZones(Foam::List<Foam::pointZone*> const&, Foam::List<Foam::faceZone*> const&, Foam::List<Foam::cellZone*> const&) at ??:?
#3 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/blockMesh
#4 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#5 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/blockMesh
Aborted
```
### What is the expected *correct* behavior?
The correct behavior is to successfully generate the mesh with the regions defined as long as blocks from different regions were not joined with mergePatchPairs.
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :2012
- Operating system :Debian 10 (Buster)
- Hardware info :AMD Ryzen 9 3900X 12-Core Processor, 64 GB ddr4
- Compiler :g++ 4:8.3.0-1,g++-8 8.3.0-6[blockMeshDict](/uploads/67dfd557d69b8288c115d8cd9b3d16ab/blockMeshDict)
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2089BUG: turbulentDFSEMInlet: wrong operator in checkStresses function2021-06-09T13:47:40ZKutalmış BerçinBUG: turbulentDFSEMInlet: wrong operator in checkStresses function### Summary
<!-- Summarize the bug encountered concisely -->
In [L1003](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/turbulentDFSEMInlet/turbulentDFSEMInletFvPatchVectorF...### Summary
<!-- Summarize the bug encountered concisely -->
In [L1003](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/turbulentDFSEMInlet/turbulentDFSEMInletFvPatchVectorField.C#L1003), the relevant term `*a_yy` should be `/a_yy`.
The bug was found by Ole Meyer, @h2o_meyer.v2106Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2091Style: PDRFOAM2021-05-19T13:49:16ZHenning ScheuflerStyle: PDRFOAMPDR and PDRAutorefine end with:
Info<< "\n end\n";
instead of
Info<< "End\n";PDR and PDRAutorefine end with:
Info<< "\n end\n";
instead of
Info<< "End\n";Henning ScheuflerHenning Scheuflerhttps://develop.openfoam.com/Development/openfoam/-/issues/2092redistributePar does not always detect whether reconstruction is needed2024-01-05T16:55:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not always detect whether reconstruction is needed### Functionality to add/problem to solve
redistributePar does not always decide to reconstruct mesh correctly
- run `redistributePar` with -decompose (or decomposePar)
- remove constant/polyMesh (but not processorXXX/constant/polyMesh...### Functionality to add/problem to solve
redistributePar does not always decide to reconstruct mesh correctly
- run `redistributePar` with -decompose (or decomposePar)
- remove constant/polyMesh (but not processorXXX/constant/polyMesh/*addressing)
- now redistributePar still thinks it has an undecomposed mesh (since above *addressing still exists)
### Target audience
Cleanup scripts that don't delete addressing
### Proposal
Add some more checks
(EP 1573) @Prashant @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2093BUG: forces: UName entry is not used2021-08-05T12:56:59ZKutalmış BerçinBUG: forces: UName entry is not used### Summary
<!-- Summarize the bug encountered concisely -->
For basic incompressible and compressible simulations, the `force` function object has not been using a given `UName` for the `devRhoReff` computation (affecting the tangenti...### Summary
<!-- Summarize the bug encountered concisely -->
For basic incompressible and compressible simulations, the `force` function object has not been using a given `UName` for the `devRhoReff` computation (affecting the tangential component), but using the `U` of the latest available step.
In contrast, the `pName` has always been being used correctly.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Consider any tutorial using the `force` function object.
Compute the following, and compare the output of integrated forces or force fields:
- `fieldAverage` of `force` function object using instantaneous `U` field.
- `force` function object using a given `UMean` at the end of the simulation; obtain `UMean` by using `fieldAverage`.
The results consistently differ within a certain range of decimal points irrespective of initialisation/sampling duration.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
api = 2102
patch = 210414
HEAD = 5eb48c443a
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
(EP#1224)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2094read updated VTK legacy format2021-07-08T07:05:07ZMark OLESENread updated VTK legacy formattopic flagged on [paraview discourse](https://discourse.paraview.org/t/paraview-segmentation-fault-core-dumped/6694) with a wandering title, but the essentials:
With new VTK versions, the internal vtkCellArray changed (see 9338f0b8600d1...topic flagged on [paraview discourse](https://discourse.paraview.org/t/paraview-segmentation-fault-core-dumped/6694) with a wandering title, but the essentials:
With new VTK versions, the internal vtkCellArray changed (see 9338f0b8600d1ba5f0b24f79a83c63111e90675b for previous changes). As a result of this, the VTK legacy format has also changed.
### Previously
```
POLYGONS (npoly) (nPolys + nConnectivity)
n1 verts1...
n2 verts2...
...
```
### Updated
```
POLYGONS (npoly) (nConnectivity)
OFFSETS int
0 n1 n1+n2 n1+n2+n3 ...
CONNECTIVITY int
verts1 verts2 ...
```
Same thing for unstructured etc. We probably don't yet want to update our output routines to generate the new contents (and potentially ruin things for any downstream consumers of the files), but should adjust the readers to accommodate.
Note: cannot tell from any particular VTK spec if the ordering OFFSETS/CONNECTIVITY vs CONNECTIVITY/OFFSETS is prescribed, but the internal vtkCellArray writer routine does output then in OFFSETS/CONNECTIVITY order. So reasonable to start there.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2095invalid/inconsistent math expression expansion2021-05-28T12:15:35ZMark OLESENinvalid/inconsistent math expression expansionIf embedded within a string, the math expr is properly evaluated:
```
fileName "${input${{ 2*10 }}}";
```
However, the following entry currently fails:
```
value ${{2*10}};
```
Error: _no entry or environment variable '2*10'_
Clearly ...If embedded within a string, the math expr is properly evaluated:
```
fileName "${input${{ 2*10 }}}";
```
However, the following entry currently fails:
```
value ${{2*10}};
```
Error: _no entry or environment variable '2*10'_
Clearly not what we expect.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2096manualInjection fails with sprayFoam2022-08-08T07:31:12ZJairo Andrés GutiérrezmanualInjection fails with sprayFoam<!--
*** 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
sprayFoam fails to run // runs poorly when using a manualInjection atomization.
### Steps to reproduce
Use the tutorial AachenBomb and modify the atomization to manualInjection (inject only 1 parcel)
### Example case
### What is the current *bug* behaviour?
1. Depending on the SOI, the case might either run (erroneously) or fail to run
When it runs, a particle is atomized every time step (but it also disappears). This happens for SOI > initial time.
When it does not run, (this happens for SOI = initial time) it shows the following result:
Selecting BreakupModel none
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 ? in "/opt/openfoam8/platforms/linux64GccDPInt32Opt/bin/sprayFoam"
#4 ? in "/opt/openfoam8/platforms/linux64GccDPInt32Opt/bin/sprayFoam"
#5 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6 ? in "/opt/openfoam8/platforms/linux64GccDPInt32Opt/bin/sprayFoam"
Floating point exception (core dumped)
### What is the expected *correct* behaviour?
<!-- 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 : 2012 (also observed in OF8)
Operating system : Ubuntu 18.04 LTS
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : OpenFOAM 2012
- Operating system : Ubuntu 18.04
- Hardware info :
- Compiler :
### Possible fixes
This bug was previously reported in OpenFOAM.org (v2.2) and appears as fixed, but I also experienced it today in OFV8. https://bugs.openfoam.org/view.php?id=1241. I'm afraid I don't have time at the moment to go into the code.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2097BUG: channel395 and turbulentInflow/PCF: wrong length scale input2021-06-09T13:48:19ZKutalmış BerçinBUG: channel395 and turbulentInflow/PCF: wrong length scale input<!--
*** 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 -->
In the tutorials of `channel395` and `turbulentInflow/PCF`, the integral-length scale input files (i.e. `constant/boundaryData/inlet/0/L`) involve length-scale values considerably lower (i.e. at least two orders of magnitude) than those indirectly reported in Moser et al. (1999).
In Moser et al., (1999), the integral-length scale information can be computed either by partially integrating the reported x-autocorrelations or by using the relation of k^(3/2)/epsilon on the reported resolved kinetic energy balance.
Both methods yielded similar values for length scales which revealed to be considerably higher in comparison to the length-scale info being used in the aforementioned tutorials.
The content of the available L files were computed by using the `turbulenceFields` function object on a given RANS simulation. This should have yielded comparable length-scale info, yet have not. This should also need to be inspected.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Pending
### 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
-->
Pending
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
api = 2102
patch = 210414
HEAD = 18c1da05fd
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
Pendingv2106Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2098Bug: MappedFile: merging of entry scopes2021-06-09T13:48:11ZKutalmış BerçinBug: MappedFile: merging of entry scopes<!--
*** 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 -->
For a boundary condition, assume there are two MappedFile-object entries: `R` and `L`.
The condition definition could look like as follows:
```
condition
{
type condition;
R
{
type mappedFile;
mapMethod nearest;
}
L
{
type mappedFile;
mapMethod nearest;
}
}
```
However, utilities invoking `MappedFile::writeData`, e.g. `decomposePar`, writes out all the subdictionaries into the same scope:
```
condition
{
type condition;
R mappedFile;
mapMethod nearest;
L mappedFile;
mapMethod nearest;
}
```
The above is problematic because we have multiple `mapMethod` entries within the same scope.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
NA
### 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
-->
NA
### What is the current *bug* behaviour?
<!-- What actually happens -->
NA
### What is the expected *correct* behavior?
<!-- What you should see instead -->
@mark's comment:
> Should probably be writing out RCoeffs { mapMethod ...; } and LCoeffs { ... }
### 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.
-->
NA
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
api = 2102
patch = 210414
HEAD = 739c1c1d61
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
NA
@Mattijs