Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-03-15T20:10:37Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1435There are some mistakes at the example of Periodic hill on OpenFOAM: User Gui...2021-03-15T20:10:37ZAdminThere are some mistakes at the example of Periodic hill on OpenFOAM: User Guide v1906<!--
*** 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 ...<!--
*** 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 -->At the web site, Periodic hills describtion function is wrong.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
open the website [https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-turbulent-periodic-hill.html#sec-verification-validation-turbulent-periodic-hill-overview]
At the Mesh Table, you will see
hills described by the function:
<img src="http://latex.codecogs.com/gif.latex?y(x) = \begin{cases} a_1 + b_1 x + c_1 x^2 + d_1 x^3 & 0 \le x \textless 9, \\ a_2 + b_2 x + c_2 x^2 + d_2 x^3 & 9 \le x \textless 14, \\ a_3 + b_3 x + c_3 x^2 + d_3 x^3 & 14 \le x \textless 20, \\ a_4 + b_4 x + c_4 x^2 + d_4 x^3 & 20 \le x \textless 30, \\ a_5 + b_5 x + c_5 x^2 + d_5 x^3 & 30 \le x \textless 40, \\ \max(0, a_6 + b_6 x + c_6 x^2 + d_6 x^3) & 40 \le x \textless 54. \\ \end{cases}" />
as the first equation could be large than 1, the function should be corrected as:
<img src="http://latex.codecogs.com/gif.latex?y(x) = \begin{cases} \min(1, a_1 + b_1 x + c_1 x^2 + d_1 x^3) & 0 \le x \textless 9, \\ a_2 + b_2 x + c_2 x^2 + d_2 x^3 & 9 \le x \textless 14, \\ a_3 + b_3 x + c_3 x^2 + d_3 x^3 & 14 \le x \textless 20, \\ a_4 + b_4 x + c_4 x^2 + d_4 x^3 & 20 \le x \textless 30, \\ a_5 + b_5 x + c_5 x^2 + d_5 x^3 & 30 \le x \textless 40, \\ \max(0, a_6 + b_6 x + c_6 x^2 + d_6 x^3) & 40 \le x \textless 54. \\ \end{cases}" />
and the number in the table of c2 should be -1.016116352781×10−1 rather than 1.016116352781×10−1
### 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 -->
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- 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
-->
https://develop.openfoam.com/Development/openfoam/-/issues/1488surfaceField FO fails on interpolate2019-12-09T16:01:25ZMark OLESENsurfaceField FO fails on interpolatecross-ref EP1101 @Prashantcross-ref EP1101 @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1497Error decomposing with redistributePar and codedFixedValue BC2021-07-07T07:54:39ZAdminError decomposing with redistributePar and codedFixedValue BC<!--
*** 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 ...<!--
*** 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
Decomposing a case with `redistributePar` fails when `codedFixedValue` boundary condition is used.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
A minimal example with `pitzDaily` has been attached. The error appears when executing the following commands:
```
blockMesh
mpirun -np 16 redistributePar -parallel -decompose
```
<!-- How one can reproduce the issue - this is very important -->
### Example case
`pitzDaily` tutorial. `0/U` file modified for reproducing the error.
[pitzDailyTest.zip](/uploads/a516c651c6e06aef2e2a8027c9156628/pitzDailyTest.zip)
<!--
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?
Trying to decompose with `redistributePar` any case that includes `codedFixedValue` fails.
Decomposition works with `decomposePar`, or `fixedValue` and `redistributePar` but fails including a basic `codedFixedValue` BC.
<!-- What actually happens -->
### Relevant logs and/or images
```
[10] --> FOAM FATAL IO ERROR:
[10] Attempt to put back onto bad stream
[10]
[10] file: IOstream at line 0
[11]
[11] file: IOstream.
[9]
[9] From function [5]
FOAM parallel run exiting
```
<!--
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 : v1906
- Operating system : centos
- Compiler : gcc
<!--
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
-->
## Reattaching the author to the issue ticket: @carpemonf ##Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1387Iso surface truncated by new "topo" method2020-12-20T14:06:24ZAdminIso surface truncated by new "topo" methodDuring the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown...During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).
![isoSurfaceTopoComparison](/uploads/332d5bd542ea4b4ce71eba275065dfe9/isoSurfaceTopoComparison.png)
\## Reattaching the author to the issue ticket: @Ricky-11 ##
\## Reattached image ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1487I can't compile my own solver: illegal instruction constexpr v19062020-03-13T13:10:15ZAdminI can't compile my own solver: illegal instruction constexpr v1906Hi everyone, I'm trying to compile my own solver in Windows 10, Ubuntu 18.04 but i can't.
The error is " illegal instruction constexpr..."
I've seeing this post: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/938
and when...Hi everyone, I'm trying to compile my own solver in Windows 10, Ubuntu 18.04 but i can't.
The error is " illegal instruction constexpr..."
I've seeing this post: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/938
and when I modify the etc/bashrc file:
# [WM_COMPILER_TYPE] - Compiler location:
# = system | ThirdParty
export WM_COMPILER_TYPE=system
# [WM_COMPILER] - Compiler:
# = Gcc | Gcc4[8-9] | Gcc5[1-5] | Gcc6[1-5] | Gcc7[1-4] | Gcc8[12] |
# Clang | Clang3[7-9] | Clang[4-6]0 | Icc | Cray | Arm | Pgi
export WM_COMPILER=Gcc
(or export WM_COMPILER=Gcc74)
the ubuntu shell says "No completion added for /opt/OpenFOAM/OpenFOAM-v1906/platforms/linux64Gcc73DPInt32Opt/bin
... incorrect platform, or not yet compiled?"
What should I do to fix this?
Thanks,
\## Reattaching the author to the issue ticket: @RoderickZ ##https://develop.openfoam.com/Development/openfoam/-/issues/1486surfaceFeatureExtract trims all features on a brick when minElem > 12020-01-06T19:29:41ZAdminsurfaceFeatureExtract trims all features on a brick when minElem > 1### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set...### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set to something not higher than 1. Since all the features are "connected" on the brick, I would have expected features to not be trimmed until at least a value of 13 on minElem.
This probably gets into how you are determining the number of elements in feature strings. In other software I've used, they generally separate things into "connected" feature groups and then apply element filtering to each of those. For example, a brick would have 12 connected feature edges and be in one group, so a minElem of 2 shouldn't trim any of the features, but in surfaceFeatureExtract, it does.
### Steps to reproduce
Run surfaceFeatureExtract on the attached brick model. No features will be extracted because minElem is set to 2. If you set it to 1, the features get extracted.
### Example case
[brick.zip](/uploads/be63b675856f5a189e7cd6035e0294e6/brick.zip)
### What is the current *bug* behaviour?
No features will be extracted because minElem is set to something above 1.
### What is the expected *correct* behavior?
I would expect all features to be extracted until minElem reaches 13, since there are 12 connected feature edges on a brick.
### Environment information
OpenFOAM version : v1906
Operating system : RHEL / Windows
Compiler : gcc / MinGW
### Possible fixes
I looked in surfaceFeatures.C to try and glean how feature strings were being determined, but I was unable to decipher the strategy being used. My guess is that there is a difference in strategy, if that's the case, then this is a feature request.
\## Reattaching the author to the issue ticket: @graups ##https://develop.openfoam.com/Development/openfoam/-/issues/1482MinGW doesn't appear to have a download link2019-11-09T16:01:41ZAdminMinGW doesn't appear to have a download linkhttps://www.openfoam.com/download/install-binary-windows-mingw.php
@Pawan @andyhttps://www.openfoam.com/download/install-binary-windows-mingw.php
@Pawan @andyAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1433Issues with turbulence modeling in isothermal VOF solvers2021-07-06T16:23:48ZAdminIssues with turbulence modeling in isothermal VOF solversUnder the VOF framework, the flow of the isothermal mixture belongs to the variable-density incompressible flow category. For such flows, VOF-based solvers of OpenFOAM fail to construct the correct governing equations for turbulence mode...Under the VOF framework, the flow of the isothermal mixture belongs to the variable-density incompressible flow category. For such flows, VOF-based solvers of OpenFOAM fail to construct the correct governing equations for turbulence modeling. varRhoTurbVOF contains a set of newly designed VOF-based solvers which could use the desired governing equations for turbulence quantities.
Details could be found at
https://doi.org/10.1016/j.cpc.2019.106876
and
https://arxiv.org/abs/1811.12580v2
Implementations for different OpenFOAM versions are provided at
https://github.com/wenyuan-fan/varRhoTurbVOF
\## Reattaching the author to the issue ticket: @wenyuan ##https://develop.openfoam.com/Development/openfoam/-/issues/1450redistributePar + dyM + lagrangian leads to creash2019-10-25T11:46:06ZAdminredistributePar + dyM + lagrangian leads to creash### Summary
The redistribution of cells for each processor in parallel can be performed via
`mpirun -np 4 redistributePar -parallel -overwrite`
However, when using this for a case with dynamic Mesh and lagrangian particles, this leads...### Summary
The redistribution of cells for each processor in parallel can be performed via
`mpirun -np 4 redistributePar -parallel -overwrite`
However, when using this for a case with dynamic Mesh and lagrangian particles, this leads to a crash at the very first time step after redistribution.
### Steps to reproduce
Start any lagrangian solver with dynamic Mesh in parallel. Stop at first write out. Use redistributePar in parallel, restart the solver at latest timestep.
### Example case
This bug can easily be reproduced using `sprayDyMFoam` in combination with the aachenBomb tutorial case. I attached [aachenBomb.zip](/uploads/8c10285231317d5a4f48247de25fb9de/aachenBomb.zip) tutorial with minimal changes to include dynamic mesh. Just run the Allrun script.
### What is the current *bug* behaviour?
The solver crashes at first time step after executing redistributePar
### What is the expected *correct* behavior?
The solver should run.
### Relevant logs and/or images
The error message looks as following:
`
[3] [2] #0 #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
[3] #1 Foam::sigSegv::sigHandler(int)[2] #1 Foam::sigSegv::sigHandler(int) at ??:?
[3] #2 ? at ??:?
[2] #2 ? in /usr/lib64/libc.so.6
in /usr/lib64/libc.so.6
[3] #3 [2] #3 Foam::tetIndices::faceTriIs(Foam::polyMesh const&, bool) constFoam::tetIndices::faceTriIs(Foam::polyMesh const&, bool) const at ??:?
[3] #4 at ??:?
[2] #4 Foam::particle::position() constFoam::particle::position() const at ??:?
[3] #5 at ??:?
[2] #5 ?? at ??:?
[2] #6 at ??:?
[3] #6 ?? at ??:?
[3] #7 __libc_start_main at ??:?
[2] #7 __libc_start_main in /usr/lib64/libc.so.6
[3] #8 in /usr/lib64/libc.so.6
[2] #8 ?? at ??:?
[tauruslogin3:22317:0] Caught signal 11 (Segmentation fault)
at ??:?
[tauruslogin3:22316:0] Caught signal 11 (Segmentation fault)
`
### Environment information
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info : Intel CPU, openmpi
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/1396AMI zone inside overset zone2020-03-13T13:18:56ZAdminAMI zone inside overset zone### Functionality to add/problem to solve
Is it possible to run an AMI zone within an overset mesh zone? My case involves a cycloidal propeller, in which five blades will rotate together as a single overset mesh zone, and then each sing...### Functionality to add/problem to solve
Is it possible to run an AMI zone within an overset mesh zone? My case involves a cycloidal propeller, in which five blades will rotate together as a single overset mesh zone, and then each single blade will independently vary its pitch as an embedded AMI within the enclosing overset mesh.
\## Reattaching the author to the issue ticket: @burgreen ##https://develop.openfoam.com/Development/openfoam/-/issues/1463snappyHexMesh : Add an option to disable self-proximity in region proximity r...2020-11-25T16:11:15ZAdminsnappyHexMesh : Add an option to disable self-proximity in region proximity refinement### Functionality to add/problem to solve
The proximity refinement added to the refinementRegions in snappyHexMesh is super powerful. However, unless I'm mistaken, one feature I believe it lacks is the ability to limit refinement to be ...### Functionality to add/problem to solve
The proximity refinement added to the refinementRegions in snappyHexMesh is super powerful. However, unless I'm mistaken, one feature I believe it lacks is the ability to limit refinement to be between two separate regions/surfaces only (disable self-proximity). We can already override the gapLevel and gapMode settings on a per surface basis, but this also overrides refinement in gaps between two separate regions/surfaces.
I know that this can be made moot by specifying a very specifically shaped and sized refinementRegion that only covers the gap I want to capture, but I would much rather just throw a bounding box around two objects and have it only refine where they get close to each other and not do self-proximity, which can open up unintended gaps in the surfaces.
### Target audience
Anyone needing proximity refinement between two surfaces on a complex geometry where it is difficult to specify or create a closed surface around only a region you wish to resolve a gap.
### Proposal
Being ignorant of the complexities of snappyHexMesh, it seems like the hard work of finding the gaps is already being done, we just need to recognize whether the gap is between triangles on separate surfaces/regions or the same surface/region and refine or not refine based on a user specified bool input. I envision adding a selfProximity option to the refinementRegion section that can be overridden on a per-surface basis like the other proximity settings.
### What does success look like, and how can we measure that?
I can provide a simple test case if required. A test case where two objects are close to each other and where one of the objects has a small "self-gap" is a good test case. Success would be throwing a bounding box around the two objects, defining it as a proximity region, and only having it refine between the objects and not the small gap that exists within one of the objects.
### Funding
No sponsorship is available right now, I'm just hoping that this is easy enough to add and useful enough to a wide range of groups that it might make the cut in a future release.
\## Reattaching the author to the issue ticket: @graups ##Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/1183Overset performance degradation2020-03-14T15:51:29ZAdminOverset performance degradationHi.
We have been monitoring the performance of the overset solvers hoping in some performance in the new releases but it looks like they actually worsened starting from the v1706 and now further degraded in the latest v1812.
The follow...Hi.
We have been monitoring the performance of the overset solvers hoping in some performance in the new releases but it looks like they actually worsened starting from the v1706 and now further degraded in the latest v1812.
The following results (cloclTime per 2sec of simulated time on 1 core) are based on the twoSimpleRotors test case, run with the fixed time step and using the same fvSolution, fvSchemes and dynamicMeshDict in each case:
v1706: 683 sec
v1806: 860 sec
v1812: 5024 sec
Note that the v1812 needs about twice the number of iterations per correctors, but doesn't justify such an increase in the total clock time.
Also, when using the v1812 with the original settings, the clock time increases to about 13.000 sec.
Would be nice to have a little bit of feedback and some directions to perform further testing and hopefully improve the usage of overset in general.
\## Reattaching the author to the issue ticket: @Ricky-11 ##https://develop.openfoam.com/Development/openfoam/-/issues/1468provide dictionary context for writeOptionalEntries2019-11-03T10:06:39ZMark OLESENprovide dictionary context for writeOptionalEntriescross-ref EP#1160 @svilfayecross-ref EP#1160 @svilfayeMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1288Incorrect behaviour of overset and cellVolumeWeight2020-04-16T12:11:25ZAdminIncorrect behaviour of overset and cellVolumeWeight### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illust...### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illustrate the problems. The test case is explained in a little bit more detail in the README file.
1) First of cellVolumeWeight is a bit chatty. I’ve enclosed all Pouts into a if(debug). This is the first patch.
2) "Cell: X at:(x y z) zone: 0 changed from hole to calculated but there is no donor"
I think there could be several reasons why this error is thrown. A less fatal approach would be to revert cells with no donors to HOLE. Although it has to be done before findHoles and walkFront. The second patch does this.
3) Of course a better approach would be to find where the error is made. The cells shouldn’t have been set to CALCULATED in the first place. I attempt to fix this in patch 3.
### Steps to reproduce
Run the attached test case with overPimpleDyMFoam. The fatal error is thrown during the first iteration. Now change the number of cells in the x-direction in the background mesh from 36 to 37 and the case runs for a little longer until the overset grid again linest up with the background mesh.
Please see the README for instructions on how to run the case. Basically compile rangeLimitedLinearSpring and then run Allrun in the checkvalve folder.
### Example case
A very crude test case of a check valve closing during reverse flow is attached.
[testcase.tgz](/uploads/a8d1bad8d29b7156c61559f8e1c4c27c/testcase.tgz)
### What is the current *bug* behaviour?
I believe a mistake is made in the function combineCellTypes. There, allCellTypes is set to HOLE if interpolatedPatchTypes is a patch and if there is insufficient overlap. Now if the patch from the overset grid cuts the background mesh exactly between cells (or close enough) both cells on both sides will have good overlap and they aren’t set to HOLEs. This will cause findHoles to fail when it “walks” and sets faces to isBlocked. Later when the mesh is split there will be leaks and the entire region might not be found where there should be holes. Theses cells are instead set to CALCULATED. The third attached patch overcomes this problem by simply not checking if there is sufficient overlap and just sets the cells to HOLE when they are cut by a patch from another region. I think it’s a safe assumption that all cells cut by patches from other regions should be HOLE. Before commit 16fb52d42bb5eff4d59910c99410e6f524ef25cc where the tolerance is adjusted, it was also possilbe that the error wasn't thrown, instead regions in the background mesh where set to CALCULATED where they should have been HOLE.This could be seen as high velocites in the background mesh where there should be no solution.
### What is the expected *correct* behavior?
There should be no fatal error, at least not this particular one. The field cellTypes should be correctly calcualted.
### Relevant logs and/or images
Please see attached case.
### Environment information
OpenFOAM version : plus/v1812
Operating system : ubuntu, redhat 6.4
Compiler : gcc
This bug report is based of commit 4569a8b3c5636ae30122ac570cbbca697fc1e07f from 12th of april.
### Possible fixes
blamed file:
[src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/4569a8b3c5636ae30122ac570cbbca697fc1e07f/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C)
In the attached tar-file there is a folder called patches, either apply them or use the file in the "foldermodified_files_after_patch3" which conatins all three patches.
This is a version where all three patches have been applied.
[cellVolumeWeightCellCellStencil.C](/uploads/a19d46b73eb6b0c30ae41c30bdcd9997/cellVolumeWeightCellCellStencil.C)
I've tested with the attached case and twoSimpleRotors. They run fine. I havn't tested other overset solvers.
Also please note that the pressure field is stil calculated in HOLE regions. I haven't found a reason for this. But at least no the velocity field is zero in these regions.
\## Reattaching the author to the issue ticket: @nicolasedh ##https://develop.openfoam.com/Development/openfoam/-/issues/1467Not all entries in etc/controlDict InfoSwitches can be overwritten in the sys...2019-11-04T15:15:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comNot all entries in etc/controlDict InfoSwitches can be overwritten in the system/controlDict### Functionality to add/problem to solve
Not all entries in etc/controlDict InfoSwitches can be overwritten in the system/controlDict
- grep for all occurences of infoSwitch
- subtract all occurences of registerInfoSwitch
and the fol...### Functionality to add/problem to solve
Not all entries in etc/controlDict InfoSwitches can be overwritten in the system/controlDict
- grep for all occurences of infoSwitch
- subtract all occurences of registerInfoSwitch
and the following seem to be unimplemented:
```
OpenFOAM/db/IOobjects/IOdictionary/baseIOdictionary.C: debug::infoSwitch("writeDictionaries", 0)
OpenFOAM/db/IOstreams/IOstreams.C: Foam::debug::infoSwitch("writePrecision", 6)
OpenFOAM/db/Time/Time.C: Foam::debug::infoSwitch("printExecutionFormat", 0)
OpenFOAM/db/dictionary/dictionary.C: Foam::debug::infoSwitch("writeOptionalEntries", 0)
OpenFOAM/db/dictionary/entry/entry.C: Foam::debug::infoSwitch("disableFunctionEntries", 0)
OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCode.C: Foam::debug::infoSwitch("allowSystemOperations", 0)
OpenFOAM/global/JobInfo/JobInfo.C:bool Foam::JobInfo::writeJobInfo(Foam::debug::infoSwitch("writeJobInfo", 0));
OpenFOAM/global/profiling/profiling.C:int Foam::profiling::allowed(Foam::debug::infoSwitch("allowProfiling", 1));
OpenFOAM/primitives/strings/fileName/fileName.C: Foam::debug::infoSwitch("allowSpaceInFileName", 0)
```
@Prashant Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1447nFaces differ in faces and owner files for binary writes2019-10-30T16:04:28ZAdminnFaces differ in faces and owner files for binary writesWhen writing binary, nFaces in polyMesh/faces is one larger than the nFaces value in polyMesh/owner.When writing binary, nFaces in polyMesh/faces is one larger than the nFaces value in polyMesh/owner.https://develop.openfoam.com/Development/openfoam/-/issues/1431finite area non-orthogonal treament errors vs finite volume operators2020-03-19T15:51:29ZSergio Ferrarisfinite area non-orthogonal treament errors vs finite volume operatorsThe treatment of non-orthogonality in fam::laplcian operator differs from fvm:laplacian.
In this simple fixed BC temperature 2D slab, the same mesh is used for fam and fvm. While
in fvm the gradx(T)is smooth in fam presents non-uniformit...The treatment of non-orthogonality in fam::laplcian operator differs from fvm:laplacian.
In this simple fixed BC temperature 2D slab, the same mesh is used for fam and fvm. While
in fvm the gradx(T)is smooth in fam presents non-uniformity, specially close to the patches.
See aGradTx vs vGradTx.
laplacianFaFoam.tar is the fa solver
laplacianFoam is the fv solver.
The case cavity.tar contains the mesh and set up.
[aGradTx](/uploads/07f26b72d0b5cab79c334e8f4e9b7271/aGradTx.png)
[cavity.tar](/uploads/3a5a59a3b65fc071f00b99e64551df5b/cavity.tar)
[laplacianFaFoam.tar](/uploads/753a45d2a662a9bfd3a29b92a7afefbe/laplacianFaFoam.tar)
![vGradTx](/uploads/fabe63aa3fdef2f6c56fc1435a08873e/vGradTx.png)
The issue seems to be related to how the non-orthogonality is treated in the fam::laplacian,
special care should be taken for the non-orthogonality on the boundaries.v1912Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1172imperfect restart for turbulence cases2021-07-06T15:18:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comimperfect restart for turbulence casesRun for lots of iterations; restart from intermediate dump; results are not identical
[pitzDaily_latest.tgz](/uploads/e249c4d403dbb55ae5c866ecb8444e83/pitzDaily_latest.tgz)Run for lots of iterations; restart from intermediate dump; results are not identical
[pitzDaily_latest.tgz](/uploads/e249c4d403dbb55ae5c866ecb8444e83/pitzDaily_latest.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/1311Foam::eigenValues wrong behaviour for complex eigenvalues2020-02-18T12:24:40ZJohan RoenbyFoam::eigenValues wrong behaviour for complex eigenvaluesThe Foam::eigenValues(const tensor&) function sets an eigenvalue to 0 if it is complex:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/primitives/Tensor/tensor/tensor.C#L105
This is fundamentally flawe...The Foam::eigenValues(const tensor&) function sets an eigenvalue to 0 if it is complex:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/OpenFOAM/primitives/Tensor/tensor/tensor.C#L105
This is fundamentally flawed behaviour.
It should either return the complex eigenvalue or a FatalError.
I suggest a reimplementation of Foam::eigenValues which does not use cubicEqn::roots.
See e.g. [here](https://en.wikipedia.org/wiki/Eigenvalue_algorithm#3%C3%973_matrices)v2006Kutalmış BerçinKutalmış Berçin