Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-08-27T14:40:15Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1399Suggestion for improvement of Code development guide2021-08-27T14:40:15ZJohan RoenbySuggestion for improvement of Code development guideCommunity contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I unders...Community contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I understand it) be to git pull the latest OpenFOAM-plus, recompile it and then introduce their changes in a bug-fix/feature branch derived from there.
However, if API changes have occurred since their last git pull, the recompilation will fail due to outdated dep files etc. Having to wait for a full recompilation of everything every time I wanted to contribute has been a source of frustration for me until I discovered the -u/-update flag of the Allwmake script, which removes deprecated files and directories so the updating becomes much faster.
I therefore suggest to make contributors aware of this flag in the code development guide [here](https://develop.openfoam.com/Development/OpenFOAM-plus/wikis/page-code-development).Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1392Capillary Courant Number for reducing spurious velocities2022-12-23T14:57:10ZAdminCapillary Courant Number for reducing spurious velocities### Functionality to add/problem to solve
Spurious (unphysical) velocities are often a problem in volume of fluid simulations. Dozens of papers are written about techniques to reduce them.
As surface tension is implemented explicitly i...### Functionality to add/problem to solve
Spurious (unphysical) velocities are often a problem in volume of fluid simulations. Dozens of papers are written about techniques to reduce them.
As surface tension is implemented explicitly in interFoam, the time step needs to be limited. It should be limited by the capillary Courant number.
### Target audience
A Capillary Courant number will be useful for everyone who uses interFoam or multiphaseInterFoam, and is working with surface tension. It will be especially usefull when simulating instabilities, because before the instability appears there should usually not be any flow in the fluid.
### Proposal
A Capillary Courant Number should be added to interFoam and multiphaseInterFoam.
### What does success look like, and how can we measure that?
The simplest test case would consist of two fluids, one over another. There should not be any flow. Of course, spurious velocities will appear - however, they will be much smaller when using a Capillary Courant number.
### Links / references
Personnettaz, P.; Beckstein, P.; Landgraf, S.; Köllner, T.; Nimtz, M.; Weber, N.; Weier, T.: Thermally driven convection in Li||Bi liquid metal batteries, Journal of Power Sources 401(2018) 362-374
The capillary time step is provided at [page 36, equation A.1 of the arXiv version.](https://arxiv.org/pdf/1805.11521.pdf)
### Funding
I can provide the source code for interFoam and multiphaseInterFoam.
\## Reattaching the author to the issue ticket: @dl6tud ##v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1387Iso surface truncated by new "topo" method2020-12-20T14:06:24ZAdminIso surface truncated by new "topo" methodDuring the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown...During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).
![isoSurfaceTopoComparison](/uploads/332d5bd542ea4b4ce71eba275065dfe9/isoSurfaceTopoComparison.png)
\## Reattaching the author to the issue ticket: @Ricky-11 ##
\## Reattached image ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1380Simplify output of the forces functionObject2020-11-07T16:14:52ZAdminSimplify output of the forces functionObject### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-0...### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-04)\t(4.246068e-01 1.273820e+00 2.141011e-17)\t(7.203576e-02 -2.154636e-02 -3.007485e-04)`
Here `\t` is a tab.
Also, two separate files are created, one for the forces and one for the moments.
### Proposal
Simply having 10 values separated by spaces or tabs (consistently!) would make it much easier to open the text file with e.g. numpy or pandas, without sacrificing much.
Combining both forces and moments into single file is also reasonable.
A switch could be added to allow falling back to the old output format.
\## Reattaching the author to the issue ticket: @timofeymukha ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1370occasional crash in region reduction in regionSpit2019-12-09T22:37:29ZMark OLESENoccasional crash in region reduction in regionSpitAs noted by @Prashant and now experienced myself, inconsistent blockedFace information (not properly sync'd) leads to regionSplit crashing.
Now at least catch these and emit a warning. Still need to trace the root cause.As noted by @Prashant and now experienced myself, inconsistent blockedFace information (not properly sync'd) leads to regionSplit crashing.
Now at least catch these and emit a warning. Still need to trace the root cause.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1361createPatch does not update fields in v19062022-04-26T16:10:39ZAdmincreatePatch does not update fields in v1906when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not ma...when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not match. The field data also cannot be plotted, as it's missing/incomplete on the patches in question.
This is easy and quick to reproduce on the motorbike tutorial. Just put the attached createPatchDict in /system, and run the attached Allrun. snappyHexMesh write the layers fields, which createPatch doesn't update, and then redistributePar fails due to a missing patch.
[Allrun](/uploads/caae2587d08e5ceb8f99c3deacfbe3e1/Allrun)[createPatchDict](/uploads/acb1c63a321d3da71d448d90dcc0a216/createPatchDict)
EDIT: mapFields does not handle this either. command:
**mapFields -noFunctionObjects -parallelSource -parallelTarget -consistent .**
\#\# Reattaching the author to the issue ticket: @aerogt3 \#\#v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1353topoSet: No warning when using inconsistent setup2019-07-03T04:56:26ZPrashant SonakartopoSet: No warning when using inconsistent setup### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@mark### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1347rhoMax/rhoMin defined but not used in buoyantSimpleFoam2022-04-26T16:10:40ZAdminrhoMax/rhoMin defined but not used in buoyantSimpleFoamIn the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occu...In the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occurs in v1812 and v1906-rc1.
According to `git blame`, the commit 1a701d9eac55a49f22b983683826d3ead8a8c85b is when this was added, but the min-max restriction was not imposed into this solver, the same way it was in chtMultiRegionSimpleFoam: https://develop.openfoam.com/Development/OpenFOAM-plus/blob/1a701d9eac55a49f22b983683826d3ead8a8c85b/applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionSimpleFoam/fluid/pEqn.H#L91
\## Reattaching the author to the issue ticket: @wyldckat ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1340low limit of cut-off frequency ignored in surfaceNoise2020-03-09T06:15:06ZAdminlow limit of cut-off frequency ignored in surfaceNoisesurfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://...surfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://exchange.openfoam.com/node/1038
Son.
\## Reattaching the author to the issue ticket: @SonVo ##v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1288Incorrect behaviour of overset and cellVolumeWeight2020-04-16T12:11:25ZAdminIncorrect behaviour of overset and cellVolumeWeight### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illust...### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illustrate the problems. The test case is explained in a little bit more detail in the README file.
1) First of cellVolumeWeight is a bit chatty. I’ve enclosed all Pouts into a if(debug). This is the first patch.
2) "Cell: X at:(x y z) zone: 0 changed from hole to calculated but there is no donor"
I think there could be several reasons why this error is thrown. A less fatal approach would be to revert cells with no donors to HOLE. Although it has to be done before findHoles and walkFront. The second patch does this.
3) Of course a better approach would be to find where the error is made. The cells shouldn’t have been set to CALCULATED in the first place. I attempt to fix this in patch 3.
### Steps to reproduce
Run the attached test case with overPimpleDyMFoam. The fatal error is thrown during the first iteration. Now change the number of cells in the x-direction in the background mesh from 36 to 37 and the case runs for a little longer until the overset grid again linest up with the background mesh.
Please see the README for instructions on how to run the case. Basically compile rangeLimitedLinearSpring and then run Allrun in the checkvalve folder.
### Example case
A very crude test case of a check valve closing during reverse flow is attached.
[testcase.tgz](/uploads/a8d1bad8d29b7156c61559f8e1c4c27c/testcase.tgz)
### What is the current *bug* behaviour?
I believe a mistake is made in the function combineCellTypes. There, allCellTypes is set to HOLE if interpolatedPatchTypes is a patch and if there is insufficient overlap. Now if the patch from the overset grid cuts the background mesh exactly between cells (or close enough) both cells on both sides will have good overlap and they aren’t set to HOLEs. This will cause findHoles to fail when it “walks” and sets faces to isBlocked. Later when the mesh is split there will be leaks and the entire region might not be found where there should be holes. Theses cells are instead set to CALCULATED. The third attached patch overcomes this problem by simply not checking if there is sufficient overlap and just sets the cells to HOLE when they are cut by a patch from another region. I think it’s a safe assumption that all cells cut by patches from other regions should be HOLE. Before commit 16fb52d42bb5eff4d59910c99410e6f524ef25cc where the tolerance is adjusted, it was also possilbe that the error wasn't thrown, instead regions in the background mesh where set to CALCULATED where they should have been HOLE.This could be seen as high velocites in the background mesh where there should be no solution.
### What is the expected *correct* behavior?
There should be no fatal error, at least not this particular one. The field cellTypes should be correctly calcualted.
### Relevant logs and/or images
Please see attached case.
### Environment information
OpenFOAM version : plus/v1812
Operating system : ubuntu, redhat 6.4
Compiler : gcc
This bug report is based of commit 4569a8b3c5636ae30122ac570cbbca697fc1e07f from 12th of april.
### Possible fixes
blamed file:
[src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/4569a8b3c5636ae30122ac570cbbca697fc1e07f/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C)
In the attached tar-file there is a folder called patches, either apply them or use the file in the "foldermodified_files_after_patch3" which conatins all three patches.
This is a version where all three patches have been applied.
[cellVolumeWeightCellCellStencil.C](/uploads/a19d46b73eb6b0c30ae41c30bdcd9997/cellVolumeWeightCellCellStencil.C)
I've tested with the attached case and twoSimpleRotors. They run fine. I havn't tested other overset solvers.
Also please note that the pressure field is stil calculated in HOLE regions. I haven't found a reason for this. But at least no the velocity field is zero in these regions.
\## Reattaching the author to the issue ticket: @nicolasedh ##https://develop.openfoam.com/Development/openfoam/-/issues/1285keepParticle is ignored by postPatch2022-12-23T14:56:06ZAdminkeepParticle is ignored by postPatchI'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam....I'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/CloudFunctionObjects/CloudFunctionObject/CloudFunctionObject.H#L160
This hook has a parameter "keepParticle" if the user wants to remove the particle due to e.g. some custom model.
The hook is called here:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/parcels/Templates/KinematicParcel/KinematicParcel.C#L385
The value of "keepParticle" is not used. Right after the hook, the standard patch interaction code is called. Let's say the user chose "rebound". Then the following code is called:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/LocalInteraction.C#L260
Here, the value of keepParticle is uconditionally set to "true", ignoring the previous value.
To summarize: postPatch may set "keepParticle" to false, but this value is not used until the patch interaction models overwrite this value. Therefore postPatch has no effect on removing particles and the parameter "keepParticle" in postPatch seems to be ignored.
\## Reattaching the author to the issue ticket: @g3 ##v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1279fieldToCell does not use lookup; always reads from disk2022-12-23T14:55:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldToCell does not use lookup; always reads from disk### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Pr...### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Proposal
- add database lookup first and loading from disk only if that fails
- move fieldToCell to finiteVolume and use proper fields
Example of desired use: plot all cells where the pressure is between 5 and 1000.
```
vtkWrite1
{
type vtkWrite;
libs ("libutilityFunctionObjects.so");
timeStart 10;
writeControl timeStep;
writeInterval 1;
format binary;
legacy false;
decompose false;
fields (p U);
selection
{
threshold
{
action use;
source fieldToCell;
field p;
min 5;
max 1000;
}
}
}
```
There is currently also a bug in that it searches for the last valid p,U instead of loading them from the current time (and failing).v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1239paraFoam needs 0/ directory2020-03-13T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam needs 0/ directory### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/43add ospray for paraview2019-03-12T09:47:30ZMark OLESENadd ospray for paraviewMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1219writeDictionary FO only prints after first iteration2022-12-23T14:56:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwriteDictionary FO only prints after first iterationIt should print before the first iteration.It should print before the first iteration.v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1216Improvements for PDRFoam (solver and utilities)2019-12-17T10:04:01ZMark OLESENImprovements for PDRFoam (solver and utilities)@Sergio @pratap@Sergio @pratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1213compressibleInterfoam + twoPhaseTransport2024-02-09T21:57:04ZAdmincompressibleInterfoam + twoPhaseTransport<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Per compressibleInterPhaseTransportModel.H by setting switch to twoPhaseTransport should allow separate turbulence models for each phase (RAS, laminar, LES). Test case ...OpenFOAM-v1812/tutorials/multiphase/compressibleInterFoam/laminar/climbingRod provides further explanation but uses laminar turbulence models only. When the stress model is set to e.g. RAS the solver crashes.
### Steps to reproduce
Change the climbingRod test case to RAS and e.g. kOmegaSST, add omega.air, liquid.air, k.air, k.liquid, alphat.air, alphat.liquid to the 0 folder, update the fvSchemes and fvSolution files and run the case.
### 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
-->
[climbingRod.tar.gz](/uploads/03f55cb8fe6922114873583e5c64d8de/climbingRod.tar.gz)
### What is the current *bug* behaviour?
Solver crashes if the turbulence model is set to anything except laminar.
### What is the expected *correct* behavior?
Case should run, or the error messages should provide indication of how to fix the issues (i.e., the "bananas" approach should guide the user in what is missing).
### 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.
-->
![Selection_001](/uploads/f53d7990a742e1be3297a7cf6bda7228/Selection_001.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v1812
Operating system : Ubuntu 16.04
Compiler : GCC
### Possible fixes
Perhaps use the switch (twoPhaseTransport) should direct the solver to use the turbulence models employed by reactingTwoPhaseEulerFoam, e.g. continuousGasKE?
\## Reattaching the author to the issue ticket: @GXA_William ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1210exact wall distance uses existing decomposition method2019-02-22T09:23:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comexact wall distance uses existing decomposition method<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
'exact' wall distance in parallel uses the decomposition method in system/decomposeParDict. If this is set to a topological method it might behave very badly if the processors cannot be represented by bounding boxes.
### Steps to reproduce
Swithc on the debug flag for distributedTriSurfacMesh and look out for the individual bounding boxes of the processors. You want to avoid that any processor encapsulates all of the global bounding box (since it would cause all queries to be sent to it)
### 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 : 1906
Operating system :
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
The solution is to use hierarchical. The problem is how to automatically set it up if the user e.g. is running with scotch:
- what should be the individual splits (nx ny nz)?
- what if the number of processors cannot be decomposed into factors (e.g. it is a prime)https://develop.openfoam.com/Development/openfoam/-/issues/1191flattenMesh has to have flattish starting mesh2019-02-04T18:02:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comflattenMesh has to have flattish starting meshIt would be nice to be able to supply the plane normal instead of having twoDPointCorrector try to find it. This quite often fails due to the tight tolerance. Also maybe use the patch information?It would be nice to be able to supply the plane normal instead of having twoDPointCorrector try to find it. This quite often fails due to the tight tolerance. Also maybe use the patch information?https://develop.openfoam.com/Development/openfoam/-/issues/1188ENH: foamFormat convert : lagrangian data2020-01-06T08:46:49ZPrashant SonakarENH: foamFormat convert : lagrangian dataAttached a simple case illustrating incorrect conversion of binary data.
[column.tgz](/uploads/e6cebf0e112f53b7da18ec2eb3531aad/column.tgz)
@andy @markAttached a simple case illustrating incorrect conversion of binary data.
[column.tgz](/uploads/e6cebf0e112f53b7da18ec2eb3531aad/column.tgz)
@andy @mark