Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-03T09:32:20Zhttps://develop.openfoam.com/Development/openfoam/-/issues/541foamList does not link without scotch present2020-01-03T09:32:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamList does not link without scotch presentIs missing the dummy version.Is missing the dummy version.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/487foamList does not link if no fftw library (since randomProcesses not built)2020-01-03T09:32:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamList does not link if no fftw library (since randomProcesses not built)Remove it from the Make/options?Remove it from the Make/options?Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/535Harmonize \par vs \param for application options2020-01-03T09:24:40ZMark OLESENHarmonize \par vs \param for application optionsAs noted in !125 and #293 there is a mix of `\par` and `\param` for application options. Andy's suggestion of introducing a doxygen alias would be a good, flexible solution.
@petebachantAs noted in !125 and #293 there is a mix of `\par` and `\param` for application options. Andy's suggestion of introducing a doxygen alias would be a good, flexible solution.
@petebachantv1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1534Wiki home: broken link to page "Submitting issues"2019-12-27T10:02:17ZGerasimos ChourdakisWiki home: broken link to page "Submitting issues"In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/p...In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/page-submitting-issues)
```
the [Submitting Issues](https://develop.openfoam.com/Development/openfoam/wikis/Submitting-issues) link is broken. Replace with:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/Submitting-issues)
```https://develop.openfoam.com/Development/openfoam/-/issues/1515compilation failure of libs POSIX (latest version Dec 2019, PLUS)2019-12-26T08:48:56Zsariew8compilation failure of libs POSIX (latest version Dec 2019, PLUS)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1042External forces for rigid body dynamics2019-12-24T11:18:55ZAdminExternal forces for rigid body dynamicsCurrently the rigidBodyDynamics library only supports springs, dampers and a prescribed rotation. I'd love to see a functionality that allows for an external force restraint. E.g for simulating a rigid body that is being pushed by a cert...Currently the rigidBodyDynamics library only supports springs, dampers and a prescribed rotation. I'd love to see a functionality that allows for an external force restraint. E.g for simulating a rigid body that is being pushed by a certain force. Which might be especially useful for overset simulations. Attached is this restraint, which I'd like to see added to src/rigidBodyDynamics/restraints. The force is time and direction variable via function1.
[externalForce.zip](/uploads/a7e0e7af6e122a0b2b3b8c67b7ef001a/externalForce.zip)
Best regards
Stephan
\## Reattaching the author to the issue ticket: @Goeke ##https://develop.openfoam.com/Development/openfoam/-/issues/1489LiquidEvaporationBoil spalding number defined on molar basis2019-12-24T10:34:28ZAdminLiquidEvaporationBoil spalding number defined on molar basisIn OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is...In OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is the Sherwood number (Sh(Re,Sc)), Dab the vapor diffusivity assuming properties at the film, rhos the density at the film and Xr (line313):
// molar ratio
const scalar Xr = (Xs - Xc)/max(SMALL, 1.0 - Xs);
The units of dMassPC are in kg. However, the dimensionless group Xr is expressed in terms of molar fractions.
In literature, Xr is better known as the Spalding mass number (BM) where the ratio is expressed in terms of mass fractions rather than molar fractions [1,2]
I wonder if there is an implementation reason, which I do not see immediately, or if this is an implementation issue that should be fixed in order to correctly predict the evaporation rate.
Thank you in advance for your support and reply.
Alessandro
[1] Sergei S. Sazhin, Advanced models of fuel droplet heating and evaporation, Progress in Energy and Combustion Science, Volume 32, Issue 2, 2006.
[2] Patrick Jenny, Dirk Roekaerts, Nijso Beishuizen, Modeling of turbulent dilute spray combustion, Progress in Energy and Combustion Science, Volume 38, Issue 6, 2012.
\## Reattaching the author to the issue ticket: @pappo1890 ##https://develop.openfoam.com/Development/openfoam/-/issues/1490postProcess with cyclicACMI patches2019-12-23T14:55:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compostProcess with cyclicACMI patches<!--
*** 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 -->
Run the oscillatingACMI2D tutorial with some e.g. isoSurface functionObject as
``postProcess```
and it will crash since the pointMesh gets cleared out but the pointField (from volPointInterpolation) does not.
### 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
-->
In polyMesh::readUpdate make sure to update pointMesh (or MeshObject) in general instead of deleting it.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1464nearWallFields does not produce correct sampling location2019-12-23T14:53:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnearWallFields does not produce correct sampling location<!--
*** 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 -->
nearWallFields uses mappedPatchBase::facePoint to find a starting location which is on a tet-face when using the FACE_DIAG cell decomposition. Even on e.g. pitzDaily this might not find a point for all wall faces. Run e.g. nearWallFields with
```
type nearWallFields;
fields
(
(U UNear)
);
// Patches/groups to sample (regular expressions)
patches (wall);
// Distance to sample
distance 0.00001;
```
the fourth face on the top-wall is not found correctly and it falls back to the cell centre.
2) the destination for tracking is calculated from the fall-back cell centre in above case instead of the wanted location on the wall face.
See the UNear on the top-wall. Above tiny distance (0.00001) should produce near-zero.
![topWall](/uploads/b303ab599ba14ba04a2e14c2341252ae/topWall.png)https://develop.openfoam.com/Development/openfoam/-/issues/1529foamFormatConvert in parallel does miss converting faces file2019-12-23T14:48:52ZPrashant SonakarfoamFormatConvert in parallel does miss converting faces file### Summary
foamFormatConvert to convert between uncollated and collated format fails
### Steps to reproduce
- any case
- set writeFormat binary
- decomposePar -fileHandler uncollated
- mpirun -np XXX foamFormatConvert -parallel -file...### Summary
foamFormatConvert to convert between uncollated and collated format fails
### Steps to reproduce
- any case
- set writeFormat binary
- decomposePar -fileHandler uncollated
- mpirun -np XXX foamFormatConvert -parallel -fileHandler collated
This misses out converting the faces file!Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1526no fvMesh::solve forwarding for sphericalTensor2019-12-23T14:48:52ZMark OLESENno fvMesh::solve forwarding for sphericalTensor- seen on https://www.cfd-online.com/Forums/openfoam-programming-development/222893-port-of60-of1812-problem.html#post752642- seen on https://www.cfd-online.com/Forums/openfoam-programming-development/222893-port-of60-of1812-problem.html#post752642https://develop.openfoam.com/Development/openfoam/-/issues/1523Generate distance to surface for checking correspondence of generated mesh to...2019-12-23T14:48:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGenerate distance to surface for checking correspondence of generated mesh to original surface### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh users### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh usersMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1505Failed start of simulation due to non-zero "defaultFaces" in a case converted...2019-12-19T08:53:00ZAdminFailed start of simulation due to non-zero "defaultFaces" in a case converted by gmshToFoam<!--
*** 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 -->
(I think this issue can be closed. I gave my analysis in the first comment.)
I intended to generate 2D mesh by `Gmsh` (latest version v4.4.1), and then convert it to `OpenFOAM` (latest version v1906) polyMesh by `gmshToFoam`.
But I found the utility "gmshToFoam" is unreliable. Two example cases are provided here. They have nearly the same configuration but produce different states of mesh conversion. After minor adjustment of the spatial coordinate of a control point in the geometry definition ("bridgeFlow.geo"), "gmshToFoam" might find some faces that belongs to none of any defined physical groups and label them as "`defaultFaces`" in "constant/polyMesh/boundary". By visualizing the patches, the internal wall, which is expected to be in the same patch, is found to be divided into two patches by `gmshToFoam`.
The non-zero "nFaces" of "defaultFaces" in "boundary" will make the following commands unable to proceed.
For example, errors will be met in the operation "`decomposePar`".
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. Have Gmsh v4.4.1 and OpenFOAM v1906 in the environment.
2. Extract zipped files in the example cases.
3. `cd example_failed` or `cd example_successful`
4. `gmsh -3 bridgeFlow.geo`
5. `gmshToFoam bridgeFlow.msh`
6. Open `constant/polyMesh/boundary` and check whether it has non-zero "defaultFaces".
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
I've uploaded two cases here. The only differences in their setup are Line 14 and Line 17 in `bridgeFlow.geo` in these two cases.
The "failed" one will produce non-zero "defaultFaces".
[example_failed.zip](/uploads/d69ae6d7064727938b0a894a74630d55/example_failed.zip)
[example_successful.zip](/uploads/fd7a016b47cf46d6785c815681c5fb3c/example_successful.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The utility `gmshToFoam` is unreliable. Sometime it works well (as in 'example_successful'), but after a minor modification of geometry setup of mesh (as in 'example_failed'),
it will generate non-zero `defaultFaces` in `constant/polyMesh/boundary` and make the workflow unable to proceed.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No `defaultFaces` appears in `constant/polyMesh/boundary`, as in 'example_successful'.
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1906 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1906 OPENFOAM=1906
Arch : "LSB;label=32;scalar=64"
Exec : gmshToFoam bridgeFlow.msh
Date : Nov 20 2019
Time : 01:08:37
PID : 5532
I/O : uncollated
Case : /mnt/c/python/Chamorro_thermal/DRL_girder_optimization/example_failed
nProcs : 1
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
Starting to read mesh format at line 2
Read format version 4.1 ascii 0
Starting to read physical names at line 5
Physical names:7
Surface 1 outlet
Surface 2 top
Surface 3 inlet
Surface 4 bottom
Surface 5 backAndFront
Surface 6 bridgeWall
Volume 7 bridgeFlow
Starting to read points at line 174
Vertices to be read: 14844
Vertices read: 14844
Starting to read cells at line 29989
Cells to be read:43860
Mapping region 5 to Foam patch 0
Mapping region 6 to Foam patch 1
Mapping region 1 to Foam patch 2
Mapping region 2 to Foam patch 3
Mapping region 3 to Foam patch 4
Mapping region 4 to Foam patch 5
Mapping region 7 to Foam cellZone 0
Cells:
total: 14513
hex : 0
prism: 14513
pyr : 0
tet : 0
CellZones:
Zone Size
0 14513
Skipping tag $Periodic at line 73888
Patch 0 gets name backAndFront
Patch 1 gets name bridgeWall
Patch 2 gets name outlet
Patch 3 gets name top
Patch 4 gets name inlet
Patch 5 gets name bottom
--> FOAM Warning :
From function Foam::polyMesh::polyMesh(const Foam::IOobject&, Foam::pointField&&, const cellShapeList&, const faceListList&, const wordList&, const wordList&, const Foam::word&, const Foam::word&, const wordList&, bool)
in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 592
Found 29357 undefined faces in mesh; adding to default patch.
Finding faces of patch 0
Finding faces of patch 1
Finding faces of patch 2
Finding faces of patch 3
Finding faces of patch 4
Finding faces of patch 5
FaceZones:
Zone Size
1 24
Writing zone 0 to cellZone bridgeFlow and cellSet
Writing zone 1 to faceZone bridgeWall and faceSet
End
```
For the failed case, the block in `boundary` says:
```
defaultFaces
{
type patch;
nFaces 34;
startFace 50927;
}
```
I visualized the location of the 'defaultFaces' by Tecplot.
The 2D mesh layout looks like:
![location_of_defaultFaces](/uploads/9134ccea3d7116d1a838c4c7f39c49db/location_of_defaultFaces.png)
The internal wall is dyed with colors for each patch.
![location_of_defaultFaces_2](/uploads/9e66b9e5cbbbab84249a6444b6a2f69f/location_of_defaultFaces_2.png)
The whole internal wall should be in the same patch `bridgeWall`.
However, after the mesh conversion by `gmshToFoam`, the internal wall is divided into two patches: `bridgeWall` in the blue color and `defaultFaces` in the green color, as shown in the picture above.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1906
Operating system : ubuntu
Compiler : pre-compiled binary for WSL of Win10
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Compiler : pre-compiled binary for WSL of Win10
- Gmsh version : 4.4.1
\## Reattaching the author to the issue ticket: @lyupin ##https://develop.openfoam.com/Development/openfoam/-/issues/1114No Iterations for U and p in tutorials/incompressible/simpleFoam/turbineSiting2019-12-18T16:20:42ZAdminNo Iterations for U and p in tutorials/incompressible/simpleFoam/turbineSiting****I just run the case from OpenFOAM-v1806/tutorials/incompressible/simpleFoam/turbineSiting. There is a problem about sloving the UEqn and pEqn. Log as shown below, Initial residual,Final residual amd No Iterations are always 0. I thin...****I just run the case from OpenFOAM-v1806/tutorials/incompressible/simpleFoam/turbineSiting. There is a problem about sloving the UEqn and pEqn. Log as shown below, Initial residual,Final residual amd No Iterations are always 0. I think this results from the ABL boundary condition, becasue there are no problems from other cases under tutorials/incompressible/simpleFoam. ****
============================================================
Starting time loop
Time = 1
smoothSolver: Solving for Ux, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
GAMG: Solving for p, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
smoothSolver: Solving for epsilon, Initial residual = 0.0886043707687, Final residual = 0.00415880864373, No Iterations 3
smoothSolver: Solving for k, Initial residual = 0.999999999999, Final residual = 0.0561633717339, No Iterations 4
ExecutionTime = 1.14 s ClockTime = 1 s
Time = 2
smoothSolver: Solving for Ux, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
GAMG: Solving for p, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
smoothSolver: Solving for epsilon, Initial residual = 0.0528178005233, Final residual = 0.00435780437261, No
Iterations 2
smoothSolver: Solving for k, Initial residual = 0.49548245865, Final residual = 0.0477465631246, No Iterations 3
ExecutionTime = 1.37 s ClockTime = 1 s
Time = 3
smoothSolver: Solving for Ux, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
GAMG: Solving for p, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
smoothSolver: Solving for epsilon, Initial residual = 0.0972013129464, Final residual = 0.00472751378512, No Iterations 3
smoothSolver: Solving for k, Initial residual = 0.394880724125, Final residual = 0.0221518636059, No Iterations 4
ExecutionTime = 1.59 s ClockTime = 1 s
...
**This case is also tested in OpenFOAM-v1712 and it looks no problem. The log is shown below.**
===========================================================================
Starting time loop
Time = 1
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.0477489367561, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 0.0538730764114, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 1, Final residual = 0.0669858308617, No Iterations 2
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0621855191776, No Iterations 3
time step continuity errors : sum local = 0.000974118673505, global = 1.89337013488e-05, cumulative = 1.89337013488e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0608576422262, Final residual = 0.00235143170564, No Iterations 3
smoothSolver: Solving for k, Initial residual = 1, Final residual = 0.0517062220961, No Iterations 2
ExecutionTime = 1.12 s ClockTime = 1 s
Time = 2
smoothSolver: Solving for Ux, Initial residual = 0.255464680163, Final residual = 0.0195594486154, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.308510924562, Final residual = 0.0110977491911, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 0.284472419959, Final residual = 0.0280404303152, No Iterations 2
GAMG: Solving for p, Initial residual = 0.13322215283, Final residual = 0.0101976026944, No Iterations 3
time step continuity errors : sum local = 0.000902796719122, global = -3.47014708889e-05, cumulative = -1.57677695401e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0346080936392, Final residual = 0.00267021263905, No Iterations 2
smoothSolver: Solving for k, Initial residual = 0.270329057688, Final residual = 0.0168602729862, No Iterations 2
ExecutionTime = 1.38 s ClockTime = 2 s
Time = 3
smoothSolver: Solving for Ux, Initial residual = 0.403798686956, Final residual = 0.0335683918725, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.32172625807, Final residual = 0.0306454045428, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 0.347723798359, Final residual = 0.0245220605412, No Iterations 2
GAMG: Solving for p, Initial residual = 0.0412987455385, Final residual = 0.00277826618771, No Iterations 2
time step continuity errors : sum local = 0.000703580205099, global = 0.000107184465015, cumulative = 9.14166954752e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0277288699551, Final residual = 0.00233613182817, No Iterations 2
smoothSolver: Solving for k, Initial residual = 0.262482535305, Final residual = 0.021940268746, No Iterations 2
ExecutionTime = 1.62 s ClockTime = 2 s
Time = 4
smoothSolver: Solving for Ux, Initial residual = 0.179980986317, Final residual = 0.0153420244482, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.176634654264, Final residual = 0.0065788228814, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 0.191853265263, Final residual = 0.01904668678, No Iterations 2
GAMG: Solving for p, Initial residual = 0.0729952671173, Final residual = 0.00340694854856, No Iterations 3
time step continuity errors : sum local = 0.000569941231663, global = 7.07002016898e-05, cumulative = 0.000162116897165
smoothSolver: Solving for epsilon, Initial residual = 0.0271072262376, Final residual = 0.00108121164345, No Iterations 3
smoothSolver: Solving for k, Initial residual = 0.212894843102, Final residual = 0.00862376163002, No Iterations 3
ExecutionTime = 1.9 s ClockTime = 2 s
\## Reattaching the author to the issue ticket: @chuck ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1197Add grids to foamMonitor (gnuplot)2019-12-18T16:20:34ZRoger AlmenarAdd grids to foamMonitor (gnuplot)It would be good to add an option to foamMonitor, like "-g|--grid", to plot the background grid to the monitoring plots, so that it is easier to identify the trends and values.
In gnuplot, it is enough to add a "set grid" line to the gnu...It would be good to add an option to foamMonitor, like "-g|--grid", to plot the background grid to the monitoring plots, so that it is easier to identify the trends and values.
In gnuplot, it is enough to add a "set grid" line to the gnuplot file.v1912Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1100Possible Deprecation of turbulentInlet Boundary Condition2019-12-18T16:20:29ZKutalmış BerçinPossible Deprecation of turbulentInlet Boundary ConditionHi,
**turbulentInlet** boundary condition generates fluctuating velocity fields by superimposing (pseudo-)random number sets (scaled by a given turbulence intensity) onto a reference (mean) velocity field.
https://www.openfoam.com/docu...Hi,
**turbulentInlet** boundary condition generates fluctuating velocity fields by superimposing (pseudo-)random number sets (scaled by a given turbulence intensity) onto a reference (mean) velocity field.
https://www.openfoam.com/documentation/cpp-guide/html/classFoam_1_1turbulentInletFvPatchField.html
Although this approach was proposed in the literature as the first turbulence inflow method, numerous studies quantified its ineffectiveness (refs can be provided if need be). Unfortunately, turbulence is fully deterministic and involving various spatial/temporal coherent structures, yet is random in a sense that its stochastic development cannot be predicted, again due to its acute sensitivity to initial/boundary conditions.
For example, in detail, for turbulentInlet the energy of generated time-series is equally distributed over the whole wavenumber range, that means the spectrum is approximately a horizontal line. Therefore, due to a lack of energy in the low wave number range, the pseudo turbulence is immediately damped to zero when enters into a CFD domain, and the result is virtually identical with a laminar inflow.
For these reasons, I kindly suggest a discussion as to this module's deprecation since customers/developers/users could be misled by its name and offerings.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/942velocity damping description not up-to-date2019-12-18T16:20:17Zvilfayeauvelocity damping description not up-to-dateHi,
I'd just realized that the velocity damping header file description is not up-to-date
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/fvOptions/constraints/derived/velocityDampingConstraint/velocityDampingCon...Hi,
I'd just realized that the velocity damping header file description is not up-to-date
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/fvOptions/constraints/derived/velocityDampingConstraint/velocityDampingConstraint.H
It should be:
`
damp
{
type velocityDampingConstraint;
active true;
velocityDampingConstraintCoeffs
{
UMax 25;
selectionMode all;
// Optional: name of velocity field (default: U)
//UName U;
}
}
`
Best,
SebastienKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1510support specified time for transformPoints2019-12-15T21:09:38ZPrashant Sonakarsupport specified time for transformPoints### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constant### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1518BUG: no regression in tutorials using potentialFoam due to the lack of -writephi2019-12-12T11:33:12ZKutalmış BerçinBUG: no regression in tutorials using potentialFoam due to the lack of -writephi[New `writephi` option](https://develop.openfoam.com/Development/openfoam/blob/develop/applications/solvers/basic/potentialFoam/potentialFoam.C#L200) of `potentialFoam` was default in previous versions (<= 1906).
The lack of new option ...[New `writephi` option](https://develop.openfoam.com/Development/openfoam/blob/develop/applications/solvers/basic/potentialFoam/potentialFoam.C#L200) of `potentialFoam` was default in previous versions (<= 1906).
The lack of new option throughout tutorials will lead to different results from tutorials.
Adding `-writephi` option into the `Allrun` scripts where `potentialFoam` is present could be the solution.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1465turbulentDFSEMInlet for LES imulation for naca0012 aerofoil2019-12-12T08:26:59ZAdminturbulentDFSEMInlet for LES imulation for naca0012 aerofoil<!--
*** 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 am trying to use turbulentDFSEMInlet at the inlet for simulation flow over aerofoil (The domain is attached below
domain size ( 5c upstream, 10 c downstream and spanwise 0.1 c ) c is the chord length (c=0.3048 m) and in the log file at the first time step only 5 eddies are generated at the inlet as shown below
`starting time loop
Courant Number mean: 0.000449944 max: 0.0468918
deltaT = 1.2e-07
Time = 1.2e-07
PIMPLE: iteration 1
**Turbulent DFSEM patch: inlet seeded 5 eddies with total volume 0.0519412**
smoothSolver: Solving for Ux, Initial residual = 3.70186e-06, Final residual = 5.58285e-09, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 2.02752e-06, Final residual = 7.27509e-08, No Iterations 1
smoothSolver: Solving for Uz, Initial residual = 0.000726498, Final residual = 8.2538e-08, No Iterations 1
GAMG: Solving for p, Initial residual = 0.999923, Final residual = 1.86291, No Iterations 1000
GAMG: Solving for p, Initial residual = 0.0407024, Final residual = 0.0142608, No Iterations 1000
time step continuity errors : sum local = 9.09561e-07, global = -1.32729e-08, cumulative = -1.32729e-08
GAMG: Solving for p, Initial residual = 0.0149751, Final residual = 0.00549751, No Iterations 1000
GAMG: Solving for p, Initial residual = 0.0055067, Final residual = 0.00168609, No Iterations 1000
time step continuity errors : sum local = 1.49201e-07, global = -4.97451e-09, cumulative = -1.82474e-08`
### Steps to reproduce
**boundary conditions**
`/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1906 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [ 0 1 -1 0 0 0 0 ];
internalField uniform ( 71.3 0 0 );
boundaryField
{
aerofoil
{
type fixedValue;
value uniform ( 0 0 0 );
}
top
{
type symmetryPlane;
}
bottom
{
type symmetryPlane;
}
front
{
type cyclic;
}
back
{
type cyclic;
}
inlet
{
type turbulentDFSEMInlet;
delta 2;
nCellPerEddy 3;
mapMethod nearestCell;
R uniform (0.5 0 0 0.5 0 0.5);
U uniform (71.3 0 0);
L uniform 0.055;
value $internalField;
}
outlet
{
type freestream;
freestreamValue uniform (71.3 0 0);
value uniform (71.3 0 0);
}
}
// ************************************************************************* //`
`
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "constant";
object turbulenceProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
simulationType LES;
LES
{
LESModel kEqn;
turbulence on;
printCoeffs on;
delta vanDriest;
vanDriestCoeffs
{
delta cubeRootVol;
cubeRootVolCoeffs
{
deltaCoeff 1;
}
Aplus 26;
Cdelta 0.158;
}
}
// ************************************************************************* //`
### 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?
only 5 eddies are generated at the inlet and inlet velocity higher than average specified velocity as shown in the attached picture (velocity inlet=113 although the Umean=71.3 m/s)
![Capture](/uploads/15f090f2c4897ce376acd3550064832d/Capture.JPG)![Capture1](/uploads/98ff8a5078c628de6df3a034dc79a67c/Capture1.JPG)
### What is the expected *correct* behavior?
<expected higher numbers of eddies are generated at the inlet with umean=71.3 m/s
### 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 :1906
- Operating system :ubuntu 15.04
- 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
-->
\## Reattaching the author to the issue ticket: @zein.elserfy ##Kutalmış BerçinKutalmış Berçin