Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-04-26T16:10:39Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1652adding porous media in rotatine zone2022-04-26T16:10:39ZRoshanakadding porous media in rotatine zoneAdding feature of "Relative velocity Resistance formulation" which exists in Ansys-fluent for better prediction of source term when rotating region and porous zone are located in one zone. in Ansys-Fluent, the results, when you choose th...Adding feature of "Relative velocity Resistance formulation" which exists in Ansys-fluent for better prediction of source term when rotating region and porous zone are located in one zone. in Ansys-Fluent, the results, when you choose this option or not selecting it, are quite different.
it seems that Openfoam can only calculate porous source term based on absolute velocity. when it is calculated Darcy-Forchimmier source term based on absolute velocity, it seems that porous zone is fixed in position and not rotating(see attachment files)![Screenshot_from_2020-03-30_10-42-16](/uploads/993db2537153c78ad9347af3ff8f75ad/Screenshot_from_2020-03-30_10-42-16.png)![Screenshot_from_2020-03-30_10-42-32](/uploads/39025939c059c1eb36d8aa33dcaec335/Screenshot_from_2020-03-30_10-42-32.png)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1651Missing "interface.correct();" in interCondensatingEvaporatingFoam2020-03-30T17:35:58ZSebastian BorrmannMissing "interface.correct();" in interCondensatingEvaporatingFoam<!--
*** 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 -->
The interface in interCondensatingEvaporatingFoam is not reproduced correctly if sigma > 0
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run the example case with interCondensatingEvaporatingFoam. After 1 s you will already see a deformed interface in paraview.
### 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
-->
[buggedCase.tar.gz](/uploads/81d0b0736377ea0cdc1c6cdd0b8fd0d5/buggedCase.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The interface between liquid and gas deforms (see Figure 1). The deformation in the testcase might actually happen due to parasitic currents. But the surface tension doesn't correct the interface as it would do in interFoam.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
See Figure 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.
-->
![bugged](/uploads/11133c9f0b9d4323714c9534ad528af9/bugged.png)
Figure 1
![fixed](/uploads/6d9a5c11d1a8e305532dedb9c5f06873/fixed.png)
Figure 2
### 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 : Debian
### 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
-->
Add the folowing line to interCondensatingEvaporatingFoam (I added it behind #include "alphaEqnSubCycle.H"):
```C++
121 interface.correct();
```https://develop.openfoam.com/Development/openfoam/-/issues/1650scotch compilation : mingw2020-06-19T14:30:12ZPawan Ghildiyalscotch compilation : mingwHi Mark,
I was trying to find reason the failure of compilation with scotch-6.0.9. But was not able
to find any reason , so I tried scotch-6.0.6 which was working with v1906 and I found following error
i.e regex.h not found. Am I am m...Hi Mark,
I was trying to find reason the failure of compilation with scotch-6.0.9. But was not able
to find any reason , so I tried scotch-6.0.6 which was working with v1906 and I found following error
i.e regex.h not found. Am I am missing something in my compilation enviornment
![image](/uploads/7ae94776c25f06ed3c4eb3ace6b3cd5f/image.png)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1647More control for making or skipping make2020-11-05T17:36:59ZMark OLESENMore control for making or skipping makeWhen building with or without modules, it will be useful to selective suppress building of some components.
- compile all of OpenFOAM, but without any modules
- later compile a module indvidually
I'm thinking of places where we might w...When building with or without modules, it will be useful to selective suppress building of some components.
- compile all of OpenFOAM, but without any modules
- later compile a module indvidually
I'm thinking of places where we might want to have a module such as visualization, or adios added as an additional RPM or spack package **on top** of an existing OpenFOAM installation.
Ideas:
1. If a `Allwmake.disabled` exists at the same level as a `Allwmake` file, skip it.
2. Use a `Allwmake.override` instead of `Allwmake` file at the same level.
3. Rename `Allwmake` file to `Allwmake.enabled` and symlink back to `Allwmake` when it is enabled.
4. Add in a minor logic into the overridable `Allwmake`. For example,
```
enabled=true
if [ "$enabled" != true ]
then
echo "$0: is disabled"
exit 0
fi
```
@Development Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1646wmake -debug creates Make/linuxGccDebug directory2020-04-01T18:19:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwmake -debug creates Make/linuxGccDebug directory### Functionality to add/problem to solve
wmake -debug creates unused Make/linuxGccDebug directory with sourceFiles and options.
The actual files go into Make/linuxGccOpt (as they should) so it is a bit confusing.### Functionality to add/problem to solve
wmake -debug creates unused Make/linuxGccDebug directory with sourceFiles and options.
The actual files go into Make/linuxGccOpt (as they should) so it is a bit confusing.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1645Re-open Issue: Gauss CoBlended scheme fails for div(phi,alpha) in interFoam2022-04-26T16:10:40ZLydia SchulzeRe-open Issue: Gauss 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
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
Note:
I re-open this issue, as it is still relevant and not fixed in the latest version.
The issue was already described in #1236 for version v1812.
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:
```div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;```
logfile output:
`\--> 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.`
### Steps to reproduce
Use tutorial /multiphase/RAS/interFoam/damBreak. Change in fvSchemes:
```div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;```
Run the case with Allrun.
### Example case
The damBreak tutorial (tutorials/multiphase/RAS/damBreak)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Run fails in first alpha-Subcycle.
See logfile output below.
### 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.
-->
```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.```
### 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 : centos
- Hardware info :
- Compiler : gcc
### 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1643BUG: ddt FO throws warning message for legitimate input fields2020-04-01T16:55:25ZKutalmış BerçinBUG: ddt FO throws warning message for legitimate input fields<!--
*** 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
For a `volVectorField` input, say `U`, `ddt` FO throws a warning message:
```
--> FOAM Warning : functionObjects::ddt ddt1 cannot find required object U of type volScalarField
```
however in the subsequent line of log, reports the successful execution:
```
functionObjects::ddt ddt1 writing field: ddtU
```
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`cd $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity`
Append the following to `controlDict`:
```
functions
{
ddt1
{
// Mandatory entries
type ddt;
libs (fieldFunctionObjects);
field U;
// Optional (inherited) entries
result ddtU;
}
}
```
### 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 : dev
- Operating system : osuse
- Compiler : clang7 && gcc4
### 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
-->
Another layer of type selection into `ddt:calc()` should solve the problem.v2006https://develop.openfoam.com/Development/openfoam/-/issues/1642force function object has no control over output frequency in postProcessing ...2020-08-05T06:29:30ZLouisforce function object has no control over output frequency in postProcessing folderI am not sure if that is a bug or a feature request and I have not tested enough to identify all possible options (I did test in both v1906 and the latest plus version), but it seems to me that:
- no matter what I write for writeControl...I am not sure if that is a bug or a feature request and I have not tested enough to identify all possible options (I did test in both v1906 and the latest plus version), but it seems to me that:
- no matter what I write for writeControl and writeInterval in the function object definition (forces in this case, but I think it applies to other function objects as well) the output in the postProcessing folder is always one per timestep
- the same applies to the "timestep"/uniform/functionObjects/functionObjectProperties folder (ie: it gets written when fields are written no matter what I write in writeControl and writeInterval for the function object.
A simple test can be made using the $FOAM_TUTORIALS/compressible/sonicFoam/RAS/nacaAirfoil tutorial with this modified [controlDict](/uploads/9f891a0835abfc599116756ebe2e8fbf/controlDict).
I modified it as such:
made the fields write at each timestep and requested an output for the forces function as such:
```
writeControl timeStep;
writeInterval 10;
```
but the output in `postProcessing/forces/0/coefficient.dat` is still made every timestep and the field folders still show the computed forces for each timestep, as can be verified by the following command: `cat *e-0*/uniform/functionObjects/functionObjectProperties|grep results|grep -n ""|less`https://develop.openfoam.com/Development/openfoam/-/issues/1641Mesh Conversion - maximum mesh size for ccmToFoam and ccm26ToFoam2024-01-11T17:23:32Znolan gothMesh Conversion - maximum mesh size for ccmToFoam and ccm26ToFoamHello,
There appears to be a limit to the mesh size that can be successfully converted using the mesh conversion utilities, 'ccmToFoam' and 'ccm26ToFoam'.
I can provide both working and failing test cases.
Would you be interested in c...Hello,
There appears to be a limit to the mesh size that can be successfully converted using the mesh conversion utilities, 'ccmToFoam' and 'ccm26ToFoam'.
I can provide both working and failing test cases.
Would you be interested in collaborating to improve and update the utility?
Thank you for your time,
Nolan
gothne@ornl.govMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1640timeVaryingMappedFixedValue does not work with collated file format2020-06-11T15:03:07ZTimofey MukhatimeVaryingMappedFixedValue does not work with collated file format<!--
*** 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 -->
timeVaryingMappedFixedValue will crash if the collated fileHandler is used.
It attemts to search for relevant files in the uncollated processor# directories.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Grab the pitzDailyExptInlet tutorial, switch the fileHandler to collated, decompose and run in parallel.
### Relevant logs and/or images
Here is the log from pitzDailyExptInlet
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1912 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _f3950763fe-20191219 OPENFOAM=1912
Arch : "LSB;label=32;scalar=64"
Exec : simpleFoam -parallel
Date : Mar 17 2020
Time : 11:07:42
Host : DESKTOP-MPTRIAD
PID : 2403
I/O : uncollated
Case : /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet
nProcs : 4
Hosts :
(
(DESKTOP-MPTRIAD 4)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0
SIMPLE: convergence criteria
field p tolerance 0.01
field U tolerance 0.001
field "(k|epsilon|omega)" tolerance 0.001
Reading field p
Reading field U
Reading/calculating face flux field phi
Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model kEpsilon
RAS
{
RASModel kEpsilon;
turbulence on;
printCoeffs on;
Cmu 0.09;
C1 1.44;
C2 1.92;
C3 0;
sigmak 1;
sigmaEps 1.3;
}
No MRF models present
No finite volume options present
Starting time loop
streamLine streamLines:
Employing velocity field U
automatic track length specified through number of sub cycles : 5
Time = 1
[1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor1/../constant/boundaryData/inlet/points" does not exist
[1]
[1] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor1/../constant/boundaryData/inlet/points at line 1.
[1]
[1] From function Foam::IFstream& Foam::IFstream::operator()() const
[1] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[1]
FOAM parallel run exiting
[1]
[2]
[2]
[2] --> FOAM FATAL IO ERROR:
[2] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor2/../constant/boundaryData/inlet/points" does not exist
[2]
[2] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor2/../constant/boundaryData/inlet/points at line 1.
[2]
[2] From function Foam::IFstream& Foam::IFstream::operator()() const
[2] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[2]
FOAM parallel run exiting
[2]
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor3/../constant/boundaryData/inlet/points" does not exist
[3]
[3] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor3/../constant/boundaryData/inlet/points at line 1.
[3]
[3] From function Foam::IFstream& Foam::IFstream::operator()() const
[3] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[3]
FOAM parallel run exiting
[3]
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor0/../constant/boundaryData/inlet/points" does not exist
[0]
[0] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor0/../constant/boundaryData/inlet/points at line 1.
[0]
[0] From function Foam::IFstream& Foam::IFstream::operator()() const
[0] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[0]
FOAM parallel run exiting
[0]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[DESKTOP-MPTRIAD:02401] 3 more processes have sent help message help-mpi-api.txt / mpi-abort
[DESKTOP-MPTRIAD:02401] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
```
### 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 : Windows 10 WLS: Ubuntu
- Hardware info : Irrelevant
- Compiler : gcc
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1639simpleFoam: non-realistic turbulence increase in the streamwise direction in ...2024-01-11T17:22:49ZLorenzo CozzisimpleFoam: non-realistic turbulence increase in the streamwise direction in a wall-bounded flowDear developers,
running a case of a wall bounded flow over a flat plate with simpleFoam I got really weird results, with turbulent kinetic energy and turbulence intensity increasing in the flow direction when they are supposed to lower...Dear developers,
running a case of a wall bounded flow over a flat plate with simpleFoam I got really weird results, with turbulent kinetic energy and turbulence intensity increasing in the flow direction when they are supposed to lower down because of the turbulence decay.
To ease the issue-solving procedure, I prepared an archive with my case folder ready to be used. Find the .tar file here: [https://www.dropbox.com/s/szkz4vymu92eev0/smooth-openFOAM-RANS-Re70k-CFDOnline.tar?dl=0](https://www.dropbox.com/s/szkz4vymu92eev0/smooth-openFOAM-RANS-Re70k-CFDOnline.tar?dl=0)v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1638BUG: Zero (complex) to the power of zero (label/scalar) does not follow Gcc/C...2020-03-19T16:33:55ZKutalmış BerçinBUG: Zero (complex) to the power of zero (label/scalar) does not follow Gcc/Clang<!--
*** 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
There is no agreed value for zero to the power of zero in C++ standard, but C99.
Despite this, `Gcc` and `Clang` implementations assume `Type(0)^0 = 1`.
In OpenFOAM, when `Type=complex`, the assumption is not followed even though `Foam::pow` is based on `std::pow`. When `Type=scalar`, the above assumption is followed.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
[Test-A.tar.gz](/uploads/abc926c1291683e8e861c5961d7edcbe/Test-A.tar.gz) produces the following:
```
# FOAM: complex(0)^0 #
Foam::pow(Foam::complex, label) = (-nan -nan)
Foam::pow(Foam::complex, scalar) = (-nan -nan)
std::pow(std::complex, label) = (-nan -nan)
std::pow(std::complex, scalar) = (-nan -nan)
# std: complex(0)^0 #
std::complex(scalar,scalar)^scalar = (1,0)
# FOAM: scalar(0)^0 #
Foam::pow(scalar, label) = 1
Foam::pow(scalar, scalar) = 1
# std: scalar(0)^0 #
std::pow(scalar, label) = 1
std::pow(scalar, scalar) = 1
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`Foam::pow` should return whatever `std::pow` returns for complex types.
### 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 : dev
- Operating system : osuse
- Compiler : gcc 7v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1637Finite Area Method: ZeroGradient Boundary condition changed2020-04-21T15:38:36ZMatti RauterFinite Area Method: ZeroGradient Boundary condition changed<!--
*** 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
I use the zeroGradient boundary condition for outlets in thin film simulations (with faSavageHutterFoam from the avalanche module).
This strategy worked with v1812 but does not after an update to v1912.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Outlets, modeled as grad(Us) = 0, grad(h) = 0 in shallow water/thin film simulations will show distortions.
Run the appended case with OpenFOAM-v1912. It relies on the avalanche module.
<!-- How one can reproduce the issue - this is very important -->
### Example case
This example is taken from section 6.2 in https://www.researchgate.net/publication/323184565_A_finite_area_scheme_for_shallow_granular_flows_on_three-dimensional_surfaces
[outlet_testcase.zip](/uploads/0776a4aaabcd76d0494c66a8bd252b5c/outlet_testcase.zip)
## Result of the example with OpenFOAM-v1812
![OpenFOAM-v1812](/uploads/449d69d2694ab0e8ffdbaed438c20a1c/OpenFOAM-v1812.png)
## Result of the example with OpenFOAM-v1912
Note the high peak of the height at the outlet.
![OpenFOAM-v1912](/uploads/eac1d1a7395e246c4b0903d7c14ad3d4/OpenFOAM-v1912.png)
<!--
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?
The height grows monotonically near the outlet.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The height should reach a steady state near the outlet similar to the rest of the domain.
<!-- 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 : v1912
- Operating system : Ubuntu (Linux Mint)
- Hardware info :
- Compiler : gcc
### Possible fixes
I expect the change in the zeroGradient boundary condition.
<!--
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/1636overset : (bug?) whole background domain switch to "wall" (cellType=2) if an ...2021-07-06T17:25:13ZKevin Siauoverset : (bug?) whole background domain switch to "wall" (cellType=2) if an overset wall get very close to a background wallHi,
I am doing some tests to see if the overset method could be used to simulate the closing of a valve. My test case is a simple background domain with an inlet/outlet (compressible) with a restriction supposed to be closed by a moving...Hi,
I am doing some tests to see if the overset method could be used to simulate the closing of a valve. My test case is a simple background domain with an inlet/outlet (compressible) with a restriction supposed to be closed by a moving wall present in the overset "region". The movement is done via displacementLaplacian.
My problem is that when the moving overset wall get close to the background wall, the entire background domain is switched to cellType=2 (wall/hole) and it never switch back to "normal". See the attached video illustrating the problem.
oversetInterpolation methods:
* cellWeighted : not really tested as too slow and does not mark the cells inside the moving wall as wall.
* inverseDistance and trackedInverseDistance : both show same behaviour. the second one was used for the attached video.
* leastSquares : the problem appears earlier than inverseDistance. Also in the gap, cells in the overset "region" are flagged as hole/wall even if, in my opinion, they should not (before contact, see last image below).
I tested under v1806, v1812 and v1912 (release versions). The problem does not appears in v1806 but appears in v1812 and v1912 (I could not test v1906 as it is not installed on our cluster).
I don't know if it is a bug or if I am doing something not supported (wall contact) but happens to work in v1806.
The videos was done with moveDynamicMesh in sequential. The mesh is (really) coarse outside the overlapping region in order to speed-up tests. The test case can be provided if needed.
comparison between versions for trackedInverseDistance :
![comp_overset_v1806_v1812_v1912](/uploads/53caa8b228484c727889c22f115fe325/comp_overset_v1806_v1812_v1912.mp4)
![comp_overset_1806_1912.0012](/uploads/1401ddc46645c45832294bd39cd3a17c/comp_overset_1806_1912.0012.png)
results for leastSquares in v1912, just before everything get flagged as hole/wall :
![overset_1912_leastSquares](/uploads/6eb4e44a5cc843fa27e77565ed2ed255/overset_1912_leastSquares.png)
Best regardshttps://develop.openfoam.com/Development/openfoam/-/issues/1635BUG: argList::noBanner silently suppresses foamDictionary -includes output2020-04-15T08:53:56ZKutalmış BerçinBUG: argList::noBanner silently suppresses foamDictionary -includes output<!--
*** 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
`foamDictionary -includes system/controlDict` does not return #include headers.
The reason is that even though `::Foam::infoDetailLevel` is initialised to 1, it is assigned to zero in `argList::noBanner()`. This converts `DetailInfo` macro to a no-op as is executed in `functionEntries::includeEntry::execute()`, therefore no call is made to `Info`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`cd $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike`
`foamDictionary -includes system/controlDict`
which will return nothing unlike OFv1712 that returns the #include headers.
### 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 : dev
- Operating system : osuse
- Compiler : gccv2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1634Style formatting config needed (e.g. clang-format)2024-02-16T13:40:05ZGerasimos ChourdakisStyle formatting config needed (e.g. clang-format)### Functionality to add/problem to solve
Add a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) or similar system config file in the code repository, so that contributions to the repository or derived projects can follow th...### Functionality to add/problem to solve
Add a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) or similar system config file in the code repository, so that contributions to the repository or derived projects can follow the [Coding Style Guide](https://develop.openfoam.com/Development/openfoam/wikis/Coding-Style-Guide).
Clang-format is an established formatting tool and integration is already provided in many editors and IDEs, including [Emacs](https://clang.llvm.org/docs/ClangFormat.html#emacs-integration), [Vim](https://clang.llvm.org/docs/ClangFormat.html#vim-integration), and [CLion](https://clang.llvm.org/docs/ClangFormat.html#clion-integration).
### Target audience
- Regular developers of OpenFOAM
- External contributors to OpenFOAM
- Contributors to third-party OpenFOAM projects (e.g. function objects, such as the [preCICE OpenFOAM adapter](https://github.com/precice/openfoam-adapter))
### Proposal
1. Create a `.clang-format` file, e.g. in the root directory of the repository, or any other directory preferred for developers' tools.
- For example, with `clang-format -style=llvm -dump-config > .clang-format`
2. Define the preferred rules following the [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html). Beware that the rules may depend on the Clang-Format version.
### What does success look like, and how can we measure that?
Running `clang-format -i FILES` should reformat the source files `FILES` to follow the coding style guidelines.
### Links / references
- [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html)
- [OpenFOAM Coding Style Guide](https://develop.openfoam.com/Development/openfoam/wikis/Coding-Style-Guide)
### Funding
I am not aware of existing functionality regarding this. However, it may have been already developed by other developers.https://develop.openfoam.com/Development/openfoam/-/issues/1633Overset performance degradation (re-opened)2020-03-20T09:30:34ZRiccardo RossiOverset performance degradation (re-opened)I'm reopening this topic as preliminary testing with our model using the latest v1912 release shows the same issues.
In the following I'll present the results from testing based from what we learned from the previous discussion in #1183...I'm reopening this topic as preliminary testing with our model using the latest v1912 release shows the same issues.
In the following I'll present the results from testing based from what we learned from the previous discussion in #1183 using with tutorials from the official release (twoSimpleRotors and boatAndPropeller) and our test case (surfboard maneuvering).
The v1912 will be also compared to v1706 as the old release so far is the only one able to run our model with no issues.https://develop.openfoam.com/Development/openfoam/-/issues/1632objToVTK broken since v18122020-03-16T11:20:40ZThorsten ZirwesobjToVTK broken since v1812Since v1812, `objToVTK` does not work.
**How to reproduce:**
Convert any .obj file to .vtk, e.g.:
```
cp -r $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity .
cd cavity
blockMesh -blockTopology
objToVTK blockTopology.obj test.vtk ...Since v1812, `objToVTK` does not work.
**How to reproduce:**
Convert any .obj file to .vtk, e.g.:
```
cp -r $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity .
cd cavity
blockMesh -blockTopology
objToVTK blockTopology.obj test.vtk # fails
```
**Error message:**
```
--> FOAM FATAL IO ERROR:
Bad token - could not get word
file: input at line 0.
From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::word&)
in file primitives/strings/word/wordIO.C at line 48.
```
Versions up to (and including) v1806 work fine. v1812, v1906 and v1912 exhibit the error. The generated `blockTopology.obj` is the same among all versions, so the culprit seems to be `objToVTK`.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1631Writing fields with layer information makes snappyHexMesh crash in motorbike ...2021-10-29T20:19:32ZRiccardo RossiWriting fields with layer information makes snappyHexMesh crash in motorbike tutorial (reopen)I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1...I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1] #0 [2] #0 [3] #0 [4] #0 [5] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
`https://develop.openfoam.com/Development/openfoam/-/issues/1630Possible inconsistency in documentation2020-06-12T17:35:40ZMathieu OlivierPossible inconsistency in documentationThis is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stat...This is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stated in the documentation (at the beginning of the file) that the default value of the "blended" switch is set to "false". However, by looking at the constructors in omegaWallFunctionFvPatchScalarField.C, it seems that the default value is rather set to "true". Am I missing something?
Thank you!
Mathieu Olivierv2006Kutalmış BerçinKutalmış Berçin