Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-04-21T15:38:36Zhttps://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çinhttps://develop.openfoam.com/Development/openfoam/-/issues/1629ensight parallel conversion of lagrangian fields incorrect2020-03-12T10:38:47ZMark OLESENensight parallel conversion of lagrangian fields incorrect- cross-reference EP#1207
Affects 1812, 1906, 1912- cross-reference EP#1207
Affects 1812, 1906, 1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1628blockMesh wrong with BSpline2021-07-06T17:14:59ZThienblockMesh wrong with BSplineBSpline function in blockMesh may encounter problems.
It seems to work well with 1 block. However, when another block is added, the control point is also added to the mesh.
The control point is (-1 1 0). IF I change to (-1 1.0001 0), it ...BSpline function in blockMesh may encounter problems.
It seems to work well with 1 block. However, when another block is added, the control point is also added to the mesh.
The control point is (-1 1 0). IF I change to (-1 1.0001 0), it comes back to the correct mesh.
- OpenFOAM version :7
- Operating system :Linux
[xxx1](/uploads/e0169ab311d0bdfe70a5086de2fafe2c/xxx1.PNG)
![xxx2](/uploads/d6b577195ff5e4fb75460662caadf03f/xxx2.png)
![xxx1](/uploads/dd695de228f4583ca7b37d6bbcd7be71/xxx1.PNG)[airFoil2D.tar.xz](/uploads/d278867849f6e3aaeb2c08ce5ad2bd39/airFoil2D.tar.xz)https://develop.openfoam.com/Development/openfoam/-/issues/1627Build with AOCC Compiler Fails2021-01-22T10:48:23ZNikola MajksnerBuild with AOCC Compiler FailsHi there,
I'm trying to build OpenFOAM v1912 with the AOCC compiler that is optimized for the new AMD processors. But I'm getting an error at the very end of the compilation process when the OpenFOAM applications are getting compiled.
...Hi there,
I'm trying to build OpenFOAM v1912 with the AOCC compiler that is optimized for the new AMD processors. But I'm getting an error at the very end of the compilation process when the OpenFOAM applications are getting compiled.
OS: Ubuntu 18.04
OpenFOAM Version: v1912
Compiler: [AOCC(Clang)](https://developer.amd.com/amd-aocc/)
Below are the commands that I'm running:
```bash
$ apt-get install build-essential flex bison cmake zlib1g-dev libboost-system-dev libboost-thread-dev libopenmpi-dev openmpi-bin gnuplot libreadline-dev libncurses-dev libxt-dev libscotch-dev libcgal-dev curl wget
$ wget https://sourceforge.net/projects/openfoam/files/v1912/OpenFOAM-v1912.tgz
$ wget https://sourceforge.net/projects/openfoam/files/v1912/ThirdParty-v1912.tgz
$ mkdir /opt/OpenFOAM && tar -xzf OpenFOAM-v1912.tgz -C /opt/OpenFOAM && tar -xzf ThirdParty-v1912.tgz -C /opt/OpenFOAM
$ sed -i 's/export WM_COMPILER=.*/export WM_COMPILER=Clang/' /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc
$ source /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc
$ curl 'https://developer.amd.com/aocc-compiler-eula/' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: en-GB,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded' -H 'Origin: https://developer.amd.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://developer.amd.com/aocc-compiler-eula/' -H 'Cookie: c_slidebox_lists=; AKA_A2=A; ak_bmsc=08125A7934F9BC415C45AA72039B16E35435930DA136000064E6685E238A1876~pldSTaRB4wo4gj/7xqZwXbAwCMYYxDpl7AudDCN5q/uyPftrKXIBfjWmPvOTtHqaQALZ5YfYDBwbjJu6wqJwvtJIMB+WaJ1MWYgiREFZ77EA7xTBk7xsVM7E8O2+qzX9Yqf4o9fkwDuK3BKxyT97gLGgIz/kQZhjxmxqGEkfa3QRzWYj5Ar4onwEXHpr7YncScOzkQotLixqAh3bf3Ekhfu54ZkqnuAOIPl6+IyTwEdFg=; c_rurl=https%3A//developer.amd.com/aocc-compiler-eula/' -H 'Upgrade-Insecure-Requests: 1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: Trailers' --data 'amd_developer_central_nonce=7a6cd4da48&_wp_http_referer=%2Faocc-compiler-eula%2F&f=YW9jYy1jb21waWxlci0yLjEuMF8xX2FtZDY0LmRlYg%3D%3D' --output aocc.deb
$ dpkg -i aocc.deb
$ source /opt/AMD/aocc-compiler-2.1.0/setenv_AOCC.sh
$ foam
$ ./Allwmake -j -s -l
```
Most of the commands are taken from https://www.openfoam.com/documentation/system-requirements.php and https://www.openfoam.com/code/build-guide.php
Changing back `export WM_COMPILER=Gcc` in `/opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc` results in successful build of OpenFOAM
Attached is the output of compile process.
Thanks,
[log.linux64ClangDPInt32Opt](/uploads/dce39906cb23b74cc534892624feb4f8/log.linux64ClangDPInt32Opt)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1626non-blocking lduInterface checking resets outstanding requests2021-07-06T17:14:23ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnon-blocking lduInterface checking resets outstanding requestsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1625failure of " Apply" in paraview2021-07-06T17:13:15ZSindze Florianfailure of " Apply" in paraview<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
Hello,
The "Apply" command in "paraview" does not work for the "achenBomb" tutorial. When I click on "Apply", I get the error message you can see (image attached). However with other tutorials, e.g. "cavity" the visualization of the simulation results can be done without any problem.
- OpenFOAM version : v1906
- Operating system :Ubuntu 18.04.2 via virtualbox
- Hardware info : 50GB of hard disk allowed to virtualbox, 11 GB of RAM, 2 processors, 16 MB of video memory.
- Compiler : gcc
![error_paraFoam](/uploads/6a5141a6b571af41230874ee245b68ed/error_paraFoam.PNG)https://develop.openfoam.com/Development/openfoam/-/issues/1624energyJumpFvPatchScalarField.C does not evaluate boundary condition of underl...2020-03-12T08:18:37ZDries AllaertsenergyJumpFvPatchScalarField.C does not evaluate boundary condition of underlying thermo.T field### Summary
When updating the coefficients of the energyJumpFvPatchScalarField boundary condition, the underlying boundary condition of the thermo.T field is not updated properly. Similar to, e.g., mixedEnergyFvPatchScalarField, the und...### Summary
When updating the coefficients of the energyJumpFvPatchScalarField boundary condition, the underlying boundary condition of the thermo.T field is not updated properly. Similar to, e.g., mixedEnergyFvPatchScalarField, the underlying boundary condition should be updated by calling evaluate() instead of updateCoeffs()
### Steps to reproduce
The problem occurs when using a timevarying jump cyclic condition (e.g., uniformJumpCyclic with a linearRamp as jump) on the temperature field in combination with the chtMultiRegionFoam solver.
### What is the current *bug* behaviour?
The current bug behaviour sets the temperature jump boundary condition upon initialization. After that, the flag updated_ remains True throughout the simulation because evaluate() is never called anymore. As a result, the temperature jump is not updated during a simulation.
### What is the expected *correct* behavior?
When the jump is set as time varying, the temperature jump value should be updated during a simulation.
### 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 Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixes
openfoam/src/thermophysicalModels/basic/derivedFvPatchFields/energyJump/energyJump/energyJumpFvPatchScalarField.C line 124
current: `Tbp.updateCoeffs();`
possible fix: `Tbp.evaluate();`
similar fix should be applied to
openfoam/src/thermophysicalModels/basic/derivedFvPatchFields/energyJump/energyJumpAMI/energyJumpAMIFvPatchScalarField.C line 124Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1623Add real density in turbulence models (for 2 phase flow simulations, such as ...2022-02-28T11:46:59ZGabriel Barajasbarajasg@unican.esAdd real density in turbulence models (for 2 phase flow simulations, such as fluid-structure interaction)It is a request that can be very useful when simulating fluid-structure interaction cases (two phase flow cases with an interface) for reducing the numerical damping.
I have realized that in turbulence models, density is defined as *geo...It is a request that can be very useful when simulating fluid-structure interaction cases (two phase flow cases with an interface) for reducing the numerical damping.
I have realized that in turbulence models, density is defined as *geometricOneField* (value of One all over the domain).
Just by changing to real density values (rhoFluid and rhoAir defined in *constant/transportProperties*), we can get more realistic values in the inteface water-air of the turbulent kinematic viscosity (as it can be seen in the picture).
![pic](/uploads/221e939f8e2c0d3f5cb517e58df4c085/pic.png)
I have added the subfix **IH** to all the new modification, so the *standard* and *new* turbulence models can coexist in the same libraries.
I enclose the codes ( **transportModels.tar.xz** and **TurbulenceModels.tar.xz**), the new solver (**interFoamIH.tar.xz**) and two tutorials:
* **waveExample_StokesI_Kepsilon.tar.xz**: waves (stokesI) in empty channel with standard turbulence model (kEpsilon).
* **waveExample_StokesI_KepsilonIH.tar.xz**: waves (stokesI) in empty channel with new turbulence models (called kEpsilonIH).
Please note that I have just updated the three most used turbulence models for fluid-structure interaction (kEpsilon, kOmega, kOmegaSST). It can be done for all the others too.
[interFoamIH.tar.xz](/uploads/d2e8104a9d09132e63cda38ae3815f04/interFoamIH.tar.xz)
[transportModels.tar.xz](/uploads/643299a779dffb9cf98ff470cc256336/transportModels.tar.xz)
[waveExample_StokesI_Kepsilon.tar.xz](/uploads/628207ad9bd7135d3f6017ac10a6f031/waveExample_StokesI_Kepsilon.tar.xz)
[TurbulenceModels.tar.xz](/uploads/c1c9eec00c515a4197a9cb3f8e090c08/TurbulenceModels.tar.xz)
[waveExample_StokesI_kEpsilonIH.tar.xz](/uploads/a236fe8cd44b1d50e278604db340e80b/waveExample_StokesI_kEpsilonIH.tar.xz)https://develop.openfoam.com/Development/openfoam/-/issues/1622Add a magnitude postOperation to the surfaceFieldValue function object2020-05-01T14:26:01ZJustin GraupmanAdd a magnitude postOperation to the surfaceFieldValue function object### Functionality to add/problem to solve
Sometimes I don't care whether the output from surfaceFieldValue is negative or positive (like when monitoring the sum of the flux). Currently the only postOperation in surfaceFieldValue that ap...### Functionality to add/problem to solve
Sometimes I don't care whether the output from surfaceFieldValue is negative or positive (like when monitoring the sum of the flux). Currently the only postOperation in surfaceFieldValue that appears to be supported is sqrt. Adding other simple ones like mag could be useful.
### Target audience
Anyone who wants the magnitude of the value calculated by surfaceFieldValue
### Proposal
Add a mag postOperation to surfaceFieldValue
### Funding
I'm not prepared to fund this directly, but my guess is this will be useful to others. It just seems odd that only one postOperation is supported.https://develop.openfoam.com/Development/openfoam/-/issues/1621Add a "cellZoneAndDirection" mode to surfaceFieldValue FO (like fluxSummary)2020-05-07T22:02:48ZJustin GraupmanAdd a "cellZoneAndDirection" mode to surfaceFieldValue FO (like fluxSummary)### Functionality to add/problem to solve
The fluxSummary function object has a really useful mode called cellZoneAndDirection which takes a cellZone and a direction. This mode finds the interior faces of the faceZone associated with th...### Functionality to add/problem to solve
The fluxSummary function object has a really useful mode called cellZoneAndDirection which takes a cellZone and a direction. This mode finds the interior faces of the faceZone associated with the cellZone and then splits the faces by connected regions. It would be super useful to have a similar mode in the surfaceFieldValue function object so that we can auto split and monitor other fields across cellZone faces (like pressure drop for a porous zone).
### Target audience
Anyone with disconnected cellZone faces that want to monitor the disconnected regions separately. This is common for a porous zone that is surrounded by walls and only has an "inlet" and "outlet" to the zone. Right now pressure drop is difficult to monitor since snappyHexMesh by default puts the "inlet" and "outlet" faces of a cellZone into a single faceZone. TopoSet can be used to split the faceZone after the fact, but we could eliminate that step with this option.
### Proposal
Something like this is what I'd propose (i'm not even sure the direction is needed)...
```
fieldValue
{
type surfaceFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
regionType cellZoneAndDirection;
cellZoneAndDirection
(
(porous (0 0 -1))
);
operation weightedAverage;
weightField U;
fields
(
p
);
}
```
### What does success look like, and how can we measure that?
Being able to do what fluxSummary does with cellZones and splitting the faceZones by connected region, but instead of monitoring flux, have the ability to monitor pressure (or any other field) on each faceZone.
### Funding
Functionality technically already exists, just needs to be applied to surfaceFieldValue. I am not prepared to directly fund this feature request.https://develop.openfoam.com/Development/openfoam/-/issues/1620nearWallFields function object fails2020-03-13T12:44:54ZMatej FormannearWallFields function object failsnearWallFiedls (version 1912) fails and particular geometry reporting error message:
```
--> FOAM FATAL ERROR:
object of type N4Foam14PatchFunction1INS_6VectorIdEEEE is unallocated
From function T* Foam::autoPtr<T>::operator->() [w...nearWallFiedls (version 1912) fails and particular geometry reporting error message:
```
--> FOAM FATAL ERROR:
object of type N4Foam14PatchFunction1INS_6VectorIdEEEE is unallocated
From function T* Foam::autoPtr<T>::operator->() [with T = Foam::PatchFunction1<Foam::Vector<double> >]
in file /scratch/pss/2010560/OpenFOAM/OpenFOAM.master.int32DP/src/OpenFOAM/lnInclude/autoPtrI.H at line 222.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#1 Foam::error::abort() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#2 Foam::uniformFixedValueFvPatchField<Foam::Vector<double> >::write(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libfiniteVolume.so
#3 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::writeEntries(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#4 Foam::Ostream& Foam::operator<< <Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>(Foam::Ostream&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#5 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::writeData(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#6 Foam::fileOperation::writeObject(Foam::regIOobject const&, Foam::IOstreamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#7 Foam::regIOobject::writeObject(Foam::IOstreamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#8 Foam::functionObjects::nearWallFields::write() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libfieldFunctionObjects.so
#9 Foam::functionObjects::timeControl::write() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#10 Foam::functionObjectList::execute() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#11 ? in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#12 __libc_start_main in /lib64/libc.so.6
#13 ? in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
```
Apparently fails only with velocity (vector) and runs ok on e.g. pressure field.
checkMesh does not report any unusual error on a mesh coming from SHM.https://develop.openfoam.com/Development/openfoam/-/issues/1617BUG: circular call to write for gradientEnergyFvPatchScalarField.C2020-03-13T14:55:36ZAndrew HeatherBUG: circular call to write for gradientEnergyFvPatchScalarField.CIn the virtual `::write(Ostream& os)` function the call to
```
os.writeEntry("value", *this)
```
uses the field `<<` operator to write the value field, which in turn (via `fvPatchField`) calls the `::write(Ostream&)` function again and g...In the virtual `::write(Ostream& os)` function the call to
```
os.writeEntry("value", *this)
```
uses the field `<<` operator to write the value field, which in turn (via `fvPatchField`) calls the `::write(Ostream&)` function again and gets locked in an infinite loop.
Current remedy: fields cannot be written to stream using the `os.writeEntry(<name>, <field>)` form---instead use `<field>.writeEntry(<name>, os)`. For the future, look to update the `Ostream::writeEntry` function.
Note: need to check other boundary condition `::write(Ostream&)` functions
~bugv2006https://develop.openfoam.com/Development/openfoam/-/issues/1616CrankNicolson ddtScheme isn't working with MPPICInterFoam2022-04-26T16:10:39ZLinus KCrankNicolson ddtScheme isn't working with MPPICInterFoam### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error ...### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error message attached further down.
### Steps to reproduce
Take the "twoPhasePachuka" tutorial case.
In file fvSchemes, change the ddtScheme to CrankNicolson:
```
ddtSchemes
{
default CrankNicolson 0.1;
}
```
In file fvSolution, change the number of AlphaSubCycles to 1:
```
solvers
{
"alpha.water.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlpha 1;
```
### Relevant logs and/or images
```
--> FOAM FATAL ERROR:
tmp<N4Foam14GeometricFieldIdNS_13fvsPatchFieldENS_11surfaceMeshEEE> deallocated
From function const T& Foam::tmp<T>::cref() const [with T = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file /OpenFOAM/v1812/OpenFOAM-v1812/src/OpenFOAM/lnInclude/tmpI.H at line 230.
FOAM aborting
```
### Environment information
OpenFOAM version : v1812v2206Kutalmış BerçinKutalmış Berçin