Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-04-05T05:22:11Zhttps://develop.openfoam.com/Development/openfoam/-/issues/89fvOption limitTemperature not recognised2016-04-05T05:22:11ZAdminfvOption limitTemperature not recognisedthe fvOption limitTemperature is not recognised as a valid fvOption. This is because it is omitted from the OpenFOAM-v3.0+/src/fvOptions/Make/files although the source is present in OpenFOAM-v3.0+/src/fvOptions/corrections/limitTemperatu...the fvOption limitTemperature is not recognised as a valid fvOption. This is because it is omitted from the OpenFOAM-v3.0+/src/fvOptions/Make/files although the source is present in OpenFOAM-v3.0+/src/fvOptions/corrections/limitTemperature.
howver the entry for limitTemperature is present in OpenFOAM-3.0.1/src/fvOptions/Make/fileshttps://develop.openfoam.com/Development/openfoam/-/issues/1136fvOption (meanVelocityForce) not parallel consistent2018-12-20T18:10:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvOption (meanVelocityForce) not parallel consistentThere are artefacts at the processor boundaries in the periodicHill tutorial.There are artefacts at the processor boundaries in the periodicHill tutorial.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/415fvOption reports selected set of cells even if it does not change (mesh motio...2018-05-29T05:39:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvOption reports selected set of cells even if it does not change (mesh motion only)Tiny issue: mesh motion cases (so no topo change) still report the selected cells even if this does not change. Attached possible fix.
[cellSetOption.C](/uploads/80bea040872b54c51f6e17086137c9b2/cellSetOption.C)Tiny issue: mesh motion cases (so no topo change) still report the selected cells even if this does not change. Attached possible fix.
[cellSetOption.C](/uploads/80bea040872b54c51f6e17086137c9b2/cellSetOption.C)https://develop.openfoam.com/Development/openfoam/-/issues/2045fvOptions SemiImplicitSource issue2024-01-09T12:14:22Zsung won choifvOptions SemiImplicitSource issueI am simulating a conjugate heat transfer problem using chtMultiRegionTwoPhaseEulerFoam, a simple case of a solid being cooled by a fluid. However no matter how much I increase the value of heat flux for the solid in fvOptions, the outle...I am simulating a conjugate heat transfer problem using chtMultiRegionTwoPhaseEulerFoam, a simple case of a solid being cooled by a fluid. However no matter how much I increase the value of heat flux for the solid in fvOptions, the outlet water temperature or the temperature of the solid just does not change. it seems to be openfoam is just ignoring fvOptions file. Maximum value of temperature at the solid and outlet water temperature remains the same as the initial value and just does not change no matter how much I change heat flux(or Power) value in fvOptions. Thanks for any advice. Regards (Please see the attached file[solidQuench37T-UP.zip](/uploads/43e6e1275839edb3ce8f7e2c7c006684/solidQuench37T-UP.zip). This model is using V-2012))https://develop.openfoam.com/Development/openfoam/-/issues/2559GAMG for overset cases2022-12-23T14:57:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG for overset cases<!--
*** 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 -->
Solving overset with GAMG does not work since GAMGInterface is not agglomerated so stays zero size. Mapping to zero size is not supported.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use any overset case. Switch on GAMG (needs algebraicPair as agglomerator). There will be error in GAMGSolverAgglomerateMatrix when trying to restrict the solution to the coarser level (since it has zero 'faces').
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Out of bounds indexing.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : feature-overset-coupledPatch branch
### 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
-->
Agglomerate GAMGInterface as e.g. cyclicAMIGAMGInterface.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2710GAMG + processorAgglomeration + interpolateCorrection fails2024-01-08T11:02:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG + processorAgglomeration + interpolateCorrection fails<!--
*** 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 -->
Divide by zero when
- GAMG
- processorAgglomerator masterCoarsests;
- interpolateCorrection true;
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any parallel case using GAMG. E.g. `pitzDaily` tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Sigfpe since coarseLevel correction is not sent across when processor agglomerating. Instead the coarse-level correction stays zero for the missing/remote elements. This causes a divide by zero when normalising.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No failure.
### 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
### 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
-->
Avoid accessing coarse-level when interpolating correction. Or send across coarse-level correction.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/379GAMGSolverScale.C does not use Field macros (from FieldM.H)2019-12-09T21:29:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMGSolverScale.C does not use Field macros (from FieldM.H)Some compilers cannot optimise our [] operators. One particular instance is inside GAMGSolverScale where pulling out the raw pointer (using .begin()) did improve performance.Some compilers cannot optimise our [] operators. One particular instance is inside GAMGSolverScale where pulling out the raw pointer (using .begin()) did improve performance.https://develop.openfoam.com/Development/openfoam/-/issues/3052GAMG: support for polling2023-12-18T15:49:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG: support for polling<!--
*** 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 -->
processorGAMGInterfaceField does not implement ready() even though it maintains its own requests. Hence any polling will call matrixInterfaceUpdate in original order, negating any benefit of polling. Note that it only affects operations inside the GAMG solver.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Hard. Default lduInterfaceField::ready() returns true so it will do the waiting instead in the matrixInterfaceUpdate routine.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Order of GAMG interface updates is always the same.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Re-runs might give slightly different truncation error.
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2309https://develop.openfoam.com/Development/openfoam/-/issues/1342GAMG uses hardcoded coarse-level solver2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG uses hardcoded coarse-level solver### Functionality to add/problem to solve
GAMG currently has two different methods for solving the coarsest level : direct or CG. It would be nice to override this behaviour
### Target audience
(Who will benefit from the changes?)
(W...### Functionality to add/problem to solve
GAMG currently has two different methods for solving the coarsest level : direct or CG. It would be nice to override this behaviour
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
Parallel running
### Proposal
(How are we going to solve the problem?)
Allow specification of coarse-level solverMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2812GAMG with cyclicAMI and mergeLevels > 1 crashes in parallel2024-01-03T13:43:58ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG with cyclicAMI and mergeLevels > 1 crashes in parallel<!--
*** 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 -->
With merging multiple levels of pairwise agglomeration crashes when using cyclicAMI.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
In incompressible `mixerVesselAMI2D` tutorial add `mergeLevels` to `fvSolution`
```
"pcorr.*"
{
solver GAMG;
smoother GaussSeidel;
..
mergeLevels 2;
..
}
```
### 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.
-->
on above tutorial on 4 procs:
```
[2] #1 Foam::sigSegv::sigHandler(int)[1] #1 Foam::sigSegv::sigHandler(int) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
[2] #2 ? in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
[1] #2 ? in /lib64/libpthread.so.0
[2] #3 virtual thunk to Foam::cyclicAMIGAMGInterface::neighbPatchID() const in /lib64/libpthread.so.0
[1] #3 virtual thunk to Foam::cyclicAMIGAMGInterface::neighbPatchID() const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
[2] #4 Foam::cyclicAMIGAMGInterface::internalFieldTransfer(Foam::UPstream::commsTypes, Foam::UList<int> const&) const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
[1] #4 Foam::cyclicAMIGAMGInterface::internalFieldTransfer(Foam::UPstream::commsTypes, Foam::UList<int> const&) const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
```
### 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 :
- Hardware info :
- Compiler :
### 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1919gap refinement /proximity refinement: snappyHexMesh tutorial fails in windows2020-11-17T12:49:52ZPawan Ghildiyalgap refinement /proximity refinement: snappyHexMesh tutorial fails in windowsEP:1434EP:1434Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1236Gauss CoBlended scheme fails for div(phi,alpha) in interFoam2020-03-23T09:56:18ZAdminGauss CoBlended scheme fails for div(phi,alpha) in interFoam<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When using the scheme Gauss CoBlended for the term div(phi,alpha) in the solver interFoam, the simulation breaks up with the following error message:
fvSchemes:
<pre>div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;</pre>
logfile output:
<pre>--> FOAM FATAL ERROR:
Operator + is undefined for unoriented and oriented types
From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&)
in file orientedType/orientedType.C at line 458.</pre>
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use tutorial /multiphase/RAS/interFoam/damBreak.
Change in fvSchemes:
<pre>div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;</pre>
Run the case with Allrun.
### 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
-->
The damBreak tutorial (tutorials/multiphase/RAS/damBreak)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Run fails in first alpha-Subcycle. Logfile output:
<pre> Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
deltaT = 0.00119048
Time = 0.00119048
PIMPLE: iteration 1
smoothSolver: Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.130194 Min(alpha.water) = 0 Max(alpha.water) = 1
--> FOAM FATAL ERROR:
Operator + is undefined for unoriented and oriented types
From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&)
in file orientedType/orientedType.C at line 458.</pre>
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Normal interFoam-running would be expected.
### 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 :v1812
Operating system :centos
Compiler :gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
\#\# Reattaching the author to the issue ticket: @Lydia \#\#https://develop.openfoam.com/Development/openfoam/-/issues/1160general cleanup items for containers2019-06-28T09:39:46ZMark OLESENgeneral cleanup items for containers- move some HashTable details into the Detail namespace
- avoid delete/new when calling HashSet::set()
- better handling of pointers in hashes (IO).
- FixedList output formatting influences pair/edge and thus we get things like `2{100}`...- move some HashTable details into the Detail namespace
- avoid delete/new when calling HashSet::set()
- better handling of pointers in hashes (IO).
- FixedList output formatting influences pair/edge and thus we get things like `2{100}` for a labelPair output. For these short lists it probably doesn't have much space saving. It would be nice to have the same output format for a Pair or a Tuple2 of the same content.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/176general configuration scripts2016-12-23T12:44:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comgeneral configuration scriptsVarious small script changes.Various small script changes.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1523Generate distance to surface for checking correspondence of generated mesh to...2019-12-23T14:48:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGenerate distance to surface for checking correspondence of generated mesh to original surface### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh users### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh usersMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2937Generating uniformly sampling on a sphere for StochasticDispersionRAS2023-07-29T06:26:40ZVictor PozzobonGenerating uniformly sampling on a sphere for StochasticDispersionRAS### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [...### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [0, pi] uniform distributions. Yet, on a sphere the Jacobian makes the angle correlated and the second angle should not be chosen independently from the first angle value.
File: lagrangian/turbulence/submodels/Kinematic/DispersionModel/StochasticDispersionRAS/StochasticDispersionRAS.C
### Target audience
(Who will benefit from the changes?) -> Users
(What type of cases?) -> Lagrangian cases
### Proposal
The current sampling method could be replaced by a corrected one such as: http://corysimon.github.io/articles/uniformdistn-on-sphere/
### What does success look like, and how can we measure that?
By projecting the drawn vector on a plane. Currently, we should get a square. After the correction, we should get a disk.
### Links / references
http://corysimon.github.io/articles/uniformdistn-on-sphere/
### Funding
NAhttps://develop.openfoam.com/Development/openfoam/-/issues/188Generic patches are missing access to their actual underlying patch types2016-12-23T12:44:51ZMark OLESENGeneric patches are missing access to their actual underlying patch typesTrivial change.Trivial change.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/816GeometricFieldFunctions: gmax, gmin double reduction2018-05-30T09:52:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGeometricFieldFunctions: gmax, gmin double reductionIn GeometricFieldFunctions.C
```
Foam::func(gFunc(gf.primitiveField()), gFunc(gf.boundaryField())) \
```
i.e. it does
```
max(reduce(max(internalField)), reduce(max(boundaryField)))
```
Better should be
```
reduce(max(max(in...In GeometricFieldFunctions.C
```
Foam::func(gFunc(gf.primitiveField()), gFunc(gf.boundaryField())) \
```
i.e. it does
```
max(reduce(max(internalField)), reduce(max(boundaryField)))
```
Better should be
```
reduce(max(max(internalField), max(boundaryField)))
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2071Geometry names in snappyHexMesh and surfaceFeatureExtract2021-04-29T13:58:00ZChiara PesciGeometry names in snappyHexMesh and surfaceFeatureExtract### Functionality to add/problem to solve
In general, a geometry file name starting with a digit is not accepted by the parser. Thus, snappyHexMesh or surfaceFeatureExtract will throw an error if a geometry file name is like _12_motorBi...### Functionality to add/problem to solve
In general, a geometry file name starting with a digit is not accepted by the parser. Thus, snappyHexMesh or surfaceFeatureExtract will throw an error if a geometry file name is like _12_motorBike.stl_.
A workaround, without changing the file name, could be to pass the name of the file as a string, i.e. using quotations marks "12_motorBike.stl". This workaround works for snappyHexMesh, but not for surfaceFeatureExtract, because the latter has a stricter policy to explicitly ignore regular expressions.
Would it be possible to have the same behaviour in both utilities? Possibly relaxing the policy for surfaceFeatureExtract.
Thank you and best regards,
ChiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/722getApplication does not work with #calc statements in the controlDict2020-05-23T11:04:36ZRoger AlmenargetApplication does not work with #calc statements in the controlDictWhen there are #calc statements in the controlDict (either directly or as an #include), the function getApplication fails because the output from foamDictionary includes all the output statements from #calc.
This is fixed by adding a ta...When there are #calc statements in the controlDict (either directly or as an #include), the function getApplication fails because the output from foamDictionary includes all the output statements from #calc.
This is fixed by adding a tail -1 as follows to the getApplication function:
*foamDictionary -entry application -value system/controlDict | tail -1*
Examples of issue shown below:
[controlDict](/uploads/a24ecfdd4fc33ecb3b708d568a567744/controlDict)[input.txt](/uploads/adacd8e356f3237544fac31a6ab01ee3/input.txt)v1806Mark OLESENMark OLESEN