Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-03-31T14:29:52Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1988cyclicACMI can not be used with layer addition/removal2021-03-31T14:29:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicACMI can not be used with layer addition/removal### Functionality to add/problem to solve
Currently cyclicACMI cannot be used with layer addition. It works with layer removal though.
### Proposal
The problem is that in cyclicACMI there are duplicate boundary faces (one is in the cy...### Functionality to add/problem to solve
Currently cyclicACMI cannot be used with layer addition. It works with layer removal though.
### Proposal
The problem is that in cyclicACMI there are duplicate boundary faces (one is in the cyclicACMI and one in the blockage). Only the cyclicACMI face gets added. This means that now the cyclicACMI is no longer matched.
@Pawanhttps://develop.openfoam.com/Development/openfoam/-/issues/1985snappyHexMesh : unwanted illimited refinement between curved triangulated sur...2021-07-07T10:54:24ZRenaud GabansnappyHexMesh : unwanted illimited refinement between curved triangulated surfaces<!--
*** 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 re...<!--
*** 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
It has already been reported that snappyHexMesh creates small gaps between curved triangulated surfaces when the stl don't match exactly (https://develop.openfoam.com/Development/openfoam/-/issues/1528). It seems that it causes another problem when using the gapLevel refinement : these small gaps are seen as regions to be refined and since they are very small, the refinement will be "illimited" all around the curved interface.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregions case with a curved interface between two regions and with the different regions specified by different stl files, and by putting a high enough maximum level of refinement into the gapLevel of either one of the regions.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Here is a case that illustrates the problem. A fluid with curved faces is inside a cubic solid and the triangulations don't match.
![image](/uploads/188cca2d2f3c44d5c7e8b0f11c94db8d/image.png)
![image](/uploads/189c20dc1537e6e146324b48a291581a/image.png)
Then a maximum gap refinement of 4 is applied and we see the result on a clipped inside view :
![image](/uploads/af22186f155f817e8d63f013eae02c30/image.png)
The same with a maximum gap refinement of 5 :
![image](/uploads/a21582bf6fd53a9e8f59b660e3dada9c/image.png)
The same as the last one but with nCellZoneIter = -1 :
![image](/uploads/b9af3706fb6ef588ec488f6adce89f69/image.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?
While looking for gaps during the procedure, snappyHexMesh will regard these unwanted gaps as actual ones and refine the surrounding cells further. Even though we can close the gaps with nCellZoneErodeIter = -1, the refinement still takes place before.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The interface should be refined just as any non-curved interface. Therefore, one should be able to set an arbitrary high maximum level of refinement and not end up with cells being refined up to this level.
<!-- What you should see instead -->
### Relevant logs and/or images
See above.
<!--
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
OpenFOAM version : v2012
Operating system : centos 7
<!--
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
-->
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1984Meson build system2023-03-06T06:54:14ZVolker WeißmannMeson build systemHello,
in [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936), we talked about exploring meson as an alternate build system.
The first prototype is ready and can be found [here](https://gitlab.com/volkerweissma...Hello,
in [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936), we talked about exploring meson as an alternate build system.
The first prototype is ready and can be found [here](https://gitlab.com/volkerweissmann/openfoam/-/tree/meson3).
The build currently works like that:
```
$ ./generate_lnInclude.py
$ ./generate_meson_build.py
$ /path/to/the/correct/version/of/meson.py setup your_build_directory
$ ninja -C your_build_directory
```
the `./generate_meson_build.py` command requires the OpenFOAM environment to be set, the other 3 commands don't.
Note that you currently need [this version of meson](https://github.com/Volker-Weissmann/meson/tree/dot-C-files-are-C++). I will work to get that merged into the original meson.
Please don't forget that this is just the first prototype. Today is literally the first day that it builds on my machine without Allwmake being run prior. So don't suggest things that are obvious like "you forgot the add the license notes in some files" or "you still have some todo comments" or "you need to cleanup the code". Please only suggest non-obvious things.
If the build does not work on your machine, it is probably because the dependency lookup of things like scotch or metis or kahip is only tested for my machine.
`generate_lnInclude.py` makes symlinks into lnInclude directories and `generate_meson_build.py` is a very hacky script that creates the `meson.build` files.
If we like this Prototype and we decide to continue working on meson I will remove the necessity for `generate_lnInclude.py`. We would ship the meson.build files, so `generate_meson_build.py` would be either never run, or only run by build-system developers.
If running `generate_meson_build.py` does not work on your machine or you want to look at the results without having to setup everything, [this patch](/uploads/5ec388bb5375f241daf0142e958aedbe/meson_build.patch) are the generated meson.build files.
Before you do performance tests of meson vs wmake, you should note that we currently link some things a bit different than wmake, so linking will get faster.
What I like about this meson/prototype:
1. Meson is far better at knowing if something needs to be rebuild or not. If you forget to add a file to Make/files, but you include that file, `wmake` will not rebuild your code if you change this file.
if you change a meson.build file, meson will rebuild all targets affected by the changes, but not rebuild the other targets.
2. Unlike wmake, meson is used by a lot of other projects. This means better tooling support, better community support and better documentation. It also means newcomers to the projects might already know meson.
3. If everything is up to date, ./Allwmake takes a long time, but `ninja` takes less than a second if everything is up to date.
4. The meson.build files are really easy to read, no comparison the the wmake folder that has bash scripts and hard to read makefiles. For an outsider, it is far easier to read those meson.build files and understand than, than to read and understand the root/wmake folder. The only part complicated thing in the meson.build files are the two topological sorts at the bottom of root/meson.build (the `foreach step : [1,1,1,1,1,1,1,1,1,1,1,1,1,1,0]` loops). Note that I'm currently working on getting this algorithm into the meson master branch (see https://github.com/mesonbuild/meson/issues/8178).
What do you think of this prototype?https://develop.openfoam.com/Development/openfoam/-/issues/1981fixedNormalSlipFvPatchField does not write its value2021-04-16T08:19:46ZJohan RoenbyfixedNormalSlipFvPatchField does not write its valueThe write function of fixedNormalSlipFvPatchField does not write its value to file:
```
template<class Type>
void Foam::fixedNormalSlipFvPatchField<Type>::write(Ostream& os) const
{
transformFvPatchField<Type>::write(os);
fixedV...The write function of fixedNormalSlipFvPatchField does not write its value to file:
```
template<class Type>
void Foam::fixedNormalSlipFvPatchField<Type>::write(Ostream& os) const
{
transformFvPatchField<Type>::write(os);
fixedValue_.writeEntry("fixedValue", os);
}
```
although this is required for for restart and visualisation in paraview.
I suggest changing it to:
```
template<class Type>
void Foam::fixedNormalSlipFvPatchField<Type>::write(Ostream& os) const
{
transformFvPatchField<Type>::write(os);
fixedValue_.writeEntry("fixedValue", os);
this->writeEntry("value", os);
}
```https://develop.openfoam.com/Development/openfoam/-/issues/1979Problem with totalFlux calculation in adjustPhi2022-04-26T16:06:28ZJohan RoenbyProblem with totalFlux calculation in adjustPhiThe variable totalFlux in cfdTools/general/adjustPhi/adjustPhi.C is calculated like this:
```
scalar totalFlux = VSMALL + sum(mag(phi)).value();
```
If I understand this correctly, the sum is over all internal faces.
At least in my cas...The variable totalFlux in cfdTools/general/adjustPhi/adjustPhi.C is calculated like this:
```
scalar totalFlux = VSMALL + sum(mag(phi)).value();
```
If I understand this correctly, the sum is over all internal faces.
At least in my case [floating2Dbox.zip](/uploads/09927295f1b004a086522694b51a693f/floating2Dbox.zip), the sum is initially zero, and I get totalFlux = 1e-300 although on the boundaries I have matching in- and outflow fluxes. For the attached case, this results in crash with:
```
--> FOAM FATAL ERROR: (openfoam-2012)
Continuity error cannot be removed by adjusting the outflow.
Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow.
Total flux : 1.0000000000000000251e-300
Specified mass inflow : 1.0000000000000059952
Specified mass outflow : 1.0000000000000064393
Adjustable mass outflow : 0
[floating2Dbox.zip](/uploads/eaba426b2041929d8e0787cc7a877d0d/floating2Dbox.zip)
```
The culprit is the line:
```
else if (mag(fixedMassOut - massIn)/totalFlux > 1e-8)
```
triggering the error.
My suggestion is to redefine totalFlux to also include the fixed boundary flux:
```
scalar totalFlux =
VSMALL + sum(mag(phi)).value() + mag(fixedMassOut) + mag(massIn);
```
It could also be considered to replace the hardcoded 1e-8 in the error condition above by for instance the `tolerance` of pFinal or p_rghFinal specified by the user in fvSolution.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1977Contribution: Dynamic load balancing for combustion simulations2023-11-24T16:26:56ZBulut TekgulContribution: Dynamic load balancing for combustion simulationsDear all,
I am writing behalf of my research group in Aalto University, Finland. Recently we have developed a custom chemistry model called DLBFoam that mitigates the well-known computational load imbalance issue in multi-processor reac...Dear all,
I am writing behalf of my research group in Aalto University, Finland. Recently we have developed a custom chemistry model called DLBFoam that mitigates the well-known computational load imbalance issue in multi-processor reactive CFD simulations using finite-rate chemistry and provides speed-up by 10 fold. Our model consists of two main features:
* A dynamic load balancer that uses MPI routines to balance the load between the processors during runtime
* A zonal reference mapping model based on Bilger's mixture fraction to map the chemistry solution of the cells from a reference solution instead of explicitly solving them, when applicable.
![crab pet](https://i.imgur.com/yYVBgHV.gif)
Our code is very well written and implemented with following OpenFOAM's code structure and guidelines and can be found in our public repository:
[GitHub - DLBFoam](https://github.com/blttkgl/DLBFoam)
You can find the branch called v1.0_OF2006 to see the version compatible with OpenFOAM ESI.
In addition, the preprint describing the code in great detail and providing benchmarking results are available at:
[ArXiv - DLBFoam](https://arxiv.org/abs/2011.07978)
There are still some things that need to be ironed out for a fully compatible contribution.
Minor:
* The Bilger's mixture fraction that we implement ourselves can be easily changed with the Bilger's mixture fraction that is implemented to OpenFOAM a while ago: [Issue Link](https://develop.openfoam.com/Development/openfoam/-/issues/1915)
Major:
* The chemistry model **at the moment** is derived from StandardChemistryModel and it does not extend to TDACChemistryModel. However, this is a low hanging fruit and can be easily implemented in a future release by us.
Finally, we will be rolling out some major changes to DLBFoam in the near future, such as replacing the finite-difference Jacobian of the chemistry ODE system with an analytical solution and using optimized matrix routines for the ODE solver. Combined with these features, we report speedup in the order of 200x in large 3D cases compared to StandardChemistryModel. Unlike DLBFoam at its current state these features are dependent on some open-source third party libraries but we would be glad to share them as well as contributions.
Please let me know if you are interested with this contribution and if yes what else would you require from us to move on with the contribution process. I will be following this thread but also feel free to reach at to me from bulut.tekgul@aalto.fi
Best,
Buluthttps://develop.openfoam.com/Development/openfoam/-/issues/1976Possible bug in prescribedRotation restrain2022-04-26T16:07:46ZFederico ZilicPossible bug in prescribedRotation restrain<!--
*** 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 re...<!--
*** 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
Hello, I'm running the boatAndPropeller tutorial and the prescribed rotations assigned to the propeller and rudder don't seem to match what is defined in dynamicMeshDict. This seems to be linked to the prescribedRotation restrain.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Run the boatAndPropeller tutorial with ./Allrun
### What is the expected *correct* behavior?
My understanding is that the propeller should accelerate until reaching a constant speed, and the rudder angular speed should be a sine wave, according to the dynamicMeshDict file:
![photo](/uploads/bf099782e4c89f1e0874717c7be293c5/photo.png)
### Relevant logs and/or images
The angular velocities as calculated with v2006:
![rud_ang_velocity](/uploads/e7888cc255404031ee1c007940befc26/rud_ang_velocity.png) ![pro_ang_velocity](/uploads/7d7a2712990bfdd9af1703894fdf479b/pro_ang_velocity.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 : v2006 (tested with v1912 and v2012 as well)
- Operating system : Ubuntu
- Hardware info : x86_64
- Compiler : gcc 9.3.0
### 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
-->
My guess is that it could be the prescribedRotation restrain.
Thanks a lot.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1972Incompressible non-uniform density turbulent model for VOF not compatible wit...2022-04-26T16:08:03ZBrecht DevolderIncompressible non-uniform density turbulent model for VOF not compatible with multiphaseStabilizedTurbulence fvOptionv2012 includes an incompressible non-uniform density turbulent model for VOF by adding
` density variable;`
in the turbulenceProperties dictionary ([https://openfoam.com/releases/openfoam-v2012/solver-and-physics.php#solver-...v2012 includes an incompressible non-uniform density turbulent model for VOF by adding
` density variable;`
in the turbulenceProperties dictionary ([https://openfoam.com/releases/openfoam-v2012/solver-and-physics.php#solver-and-physics-multiphase-rho-turbulence](https://openfoam.com/releases/openfoam-v2012/solver-and-physics.php#solver-and-physics-multiphase-rho-turbulence)).
This is not compatible with the multiphaseStabilizedTurbulence fvOption ([https://openfoam.com/releases/openfoam-v1912/solver-and-physics.php#solver-and-physics-vof-turbulence-stabilization](https://openfoam.com/releases/openfoam-v1912/solver-and-physics.php#solver-and-physics-vof-turbulence-stabilization)).
Modify damBreak tutorial (tutorials/multiphase/interFoam/RAS/damBreak) by adding system/fvOptions
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2012 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvOptions;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs
{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
// ************************************************************************* //
```
Error message:
```
Creating finite volume options from "system/fvOptions"
Selecting finite volume options type multiphaseStabilizedTurbulence
Source: multiphaseStabilizedTurbulence1
--> FOAM FATAL ERROR: (openfoam-2012)
Unable to find incompressible turbulence model
From Foam::fv::multiphaseStabilizedTurbulence::multiphaseStabilizedTurbulence(const Foam::word&, const Foam::word&, const Foam::dictionary&, const Foam::fvMesh&)
in file sources/derived/multiphaseStabilizedTurbulence/multiphaseStabilizedTurbulence.C at line 121.
FOAM exiting
```v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1961adapt/integrate PDRfitMesh2020-12-21T08:22:52ZMark OLESENadapt/integrate PDRfitMesh- serves as a pre-processor for PDRblockMesh. Scans the obstacles and helps determine an initial cell distribution for creating a PDRblockMeshDict
cross-ref: EP1247
@Pratap- serves as a pre-processor for PDRblockMesh. Scans the obstacles and helps determine an initial cell distribution for creating a PDRblockMeshDict
cross-ref: EP1247
@PratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1959displacementLaplacian cannot handle rotations > 90°2022-01-21T06:47:05ZLouisdisplacementLaplacian cannot handle rotations > 90°### Context
I'm looking to compare the clocktime, particularly the parallel scaling, between AMI, Overset, and deformable meshes when simulating [cycloidal rotor motions](https://www.youtube.com/watch?v=XKbxtCnBZbE) which consists of a s...### Context
I'm looking to compare the clocktime, particularly the parallel scaling, between AMI, Overset, and deformable meshes when simulating [cycloidal rotor motions](https://www.youtube.com/watch?v=XKbxtCnBZbE) which consists of a superposition of a local oscillating motion over a global rotating motion. The idea of using a deformable mesh is to get rid of the interfaces inherent to AMI and Overset, thus accommodating the oscillating motion through mesh deformation. AMI and Overset can produce both motions without problem. The deformable mesh can model the pitching motion without problem. However, there are to the best of my knowledge no way to solidly rotate a deforming mesh without leading to issues. I give fours examples and videos to explain that.
### Functionality to add/problem to solve
My guess is that a singularity occurs in the solution of the displacementLaplacian solver when rotations are beyond 90°. The same occurs for displacementSBRStress as well. Using velocityLaplacian mitigates the issue but the mesh will, in that case, nevertheless deteriorate, only at a later time, and that even if the motion is only limited to oscillation without rotation.
### Steps to reproduce
I'm adding a few example cases and linking videos where the issue is visible. The left side shows whole domain while the right side zooms into the zone of interest. The cases must be run with moveDynamicMesh.
#### 1 pointDispRotation:
a simple rotation of the whole domain, imposed though a pointDisplacement dictionary and a uniform diffusivity, everything runs smoothly until ~90° where mesh distortion suddenly explodes. [Video](https://youtu.be/2Y8cjZgf690).
#### 2 workingPitching:
a simple pitching motion of the two blades, works without particular issues as long as the diffusivity and boundary conditions are properly tuned. [Video](https://youtu.be/p4WNNdpyUH0).
#### 3 scalingPitchingCombinedMotion:
trying to impose the rotation in dynamicMeshDict through the solidBodyDisplacementLaplacian motion solver and the pitching in pointDisplacement. Mesh quality remains good but the patches are deformed. Scaling of patches is clearly visible, but not wanted nor requested. [Video](https://youtu.be/wT65NFZkXmg).
#### 4 pitchingVelocityLaplacian:
This solver is able to handle rotations going well beyond 360°, though the use of a angularOscillatingVelocity boundary condition imposed in the pointMotionU file. However, the quality of the mesh deteriorates with time, and this even when no global rotation is imposed. [Video](https://youtu.be/kNnoq37QWjo) comparing with the workingPitch case, diffusivity and other parameters are equal for both cases.
### What is the current *bug* behaviour?
Local mesh deformations when the whole domain rotates beyond 90° are not possible.
### What is the expected *correct* behaviour?
Local mesh deformations should not differ whether the whole domain rotates or not.
### Environment information
* OpenFOAM version : v2006
* Operating system, hardware info, and compiler : bug can be reproduced with other architectures
### Funding
Not available. However, if this issue is solved you can use my case as a mesh tutorial.
### Case files
[issueDeformingMesh.zip](/uploads/8621c546957c9482c6c6961085d15a6e/issueDeformingMesh.zip)https://develop.openfoam.com/Development/openfoam/-/issues/1958Refining coarse cells with point on boundary can give illegal mesh2020-12-14T19:01:27ZPrashant SonakarRefining coarse cells with point on boundary can give illegal mesh<!--
*** 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 re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The feature-runtime-selection-geometry has an additional refinement of cells which have a point on the boundary and are coarser than the (face) neighbouring cells. This can cause walking errors.
To be investigated.
### What is the current *bug* behaviour?
- During the refinement stages, code throws error about inconsistent 2:1 refinement.
### 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 : develop
### 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
-->
commented section for boundary refinement as temporary fix at https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/mesh/snappyHexMesh/snappyHexMeshDriver/snappyRefineDriver.C#L3454Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1954BUG: snappyHexMesh: searchableCone incorporates other searchableSurface patch...2020-12-10T12:32:08ZKutalmış BerçinBUG: snappyHexMesh: searchableCone incorporates other searchableSurface patches into its patch<!--
*** 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 re...<!--
*** 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 -->
Whenever `geometry:searchableCone` is used in combination with other `searchableSurfaces` (e.g. `searchableBox`) in `snappyHexMesh`, many faces from other `searchableSurfaces` patches are joined (spill) to the resulting patch of `searchableCone`.
Below shows a case where a `searchableBox` and `searchableCone` were input.
Visualisation of `cone1` patch, only:
![1-cone1](/uploads/c67972eff7599c014e83271bbfb0082f/1-cone1.png)
Visualisation of `box1` patch, only:
![1-box1](/uploads/cdf6f52daf07b06fe4b3f06fd8dbdc16/1-box1.png)
Note:
- Separate input of `searchableCone` and `searchableBox` produces the desired output.
- Using two or more `searchableCone`s produces the desired output (i.e. separate patches for each `searchable`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
[snappyHexMesh-searchables.zip](/uploads/f6dacb4537c1888b903015a057ee3589/snappyHexMesh-searchables.zip)
### 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.
-->
[log.snappyHexMesh.gz](/uploads/24c930caafd5535ad28a3ee309d486b4/log.snappyHexMesh.gz)
### 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 : 25246f22a6
- Compiler : gcc4.8
### 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
-->
unknown
@MattijsKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1951use sampleMesh() only on local world2020-12-09T10:25:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuse sampleMesh() only on local world<!--
*** 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 re...<!--
*** 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 -->
When running with a different `sampleWorld` take care not to use the helper function `sampleMesh`.
### What is the current *bug* behaviour?
<!-- What actually happens -->
FatalError complaining about trying to lookup a mesh which isn't present in the current world.
### 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 : feature-localWorldMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1945extrudeMesh -region BBB reads extrudeMeshDict from system instead of system/BBB2020-12-02T13:09:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comextrudeMesh -region BBB reads extrudeMeshDict from system instead of system/BBB<!--
*** 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 re...<!--
*** 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
extrudeMesh -region BBB reads extrudeMeshDict from system instead of system/BBB
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Read dictionary from region directory.
### 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 : v2006
### 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
-->
Use `setSystemMeshDictionaryIO.H`?https://develop.openfoam.com/Development/openfoam/-/issues/1944alphaEqn is missing alphac term in MPPICInterFoam2021-07-07T10:46:38Zutkan CaliskanalphaEqn is missing alphac term in MPPICInterFoamalphac should be added in line 106 of alphaEqn.H in MPPICInterFoam solver.
There is another note to this solver with the usage of MULESCorr during simulations. I think alpha field is not correctly solved without MULESCorr. Without MULE...alphac should be added in line 106 of alphaEqn.H in MPPICInterFoam solver.
There is another note to this solver with the usage of MULESCorr during simulations. I think alpha field is not correctly solved without MULESCorr. Without MULESCorr, twoPhasePachuka tutorial crashes at about 0.9s. The issue can be reproduced on twoPhasePachuka case by commenting out MULESCorr in fvSolution, and changing maxCo and maxAlphaCo to 0.5.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1937redistributePar produces illogical warning message2024-01-05T16:59:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar produces illogical warning message<!--
*** 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 re...<!--
*** 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 -->
redistributePar uses internally fvMeshSubset to subset mesh+fields to send to other processors. Exposed internal faces will produce a warning for any boundary condition holding per-face information (e.g. fixedValue v.s. uniformFixedValue).
Since the bits will get stitched later on there is actually no use for the warning message - it is just due to the current implementation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Eg in `tutorials/incompressible/simpleFoam/pitzDaily` :
```
mpirun -np 2 redistributePar -decompose -parallel
```
This will give a warning:
```
--> FOAM Warning :
From Foam::fixedValueFvPatchField<Type>::fixedValueFvPatchField(const Foam::fixedValueFvPatchField<Type>&, const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::fvPatchFieldMapper&) [with Type = double]
in file src/finiteVolume/lnInclude/fixedValueFvPatchField.C at line 81
On field subsetepsilon patch lowerWall patchField fixedValue : mapper does not map all values.
To avoid this warning fully specify the mapping in derived patch fields.
```
### 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 : <= v2006Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1925block face orientation checks don't consider the curved edges2021-07-07T10:44:14ZHassan Kassemblock face orientation checks don't consider the curved edgesHello,
The extra check introduced by commit 3aa78f2bf treats the block in the same way as ``cellShape``. I reported before to the foundation fork, [here](https://bugs.openfoam.org/view.php?id=3349). A more robust check with an option to...Hello,
The extra check introduced by commit 3aa78f2bf treats the block in the same way as ``cellShape``. I reported before to the foundation fork, [here](https://bugs.openfoam.org/view.php?id=3349). A more robust check with an option to disabled it has been introduced by this [commit](https://github.com/OpenFOAM/OpenFOAM-dev/commit/471810313636980d142a995369815aa9d5db5dd8).
I understand that both forks are not the same and you do not merge everything to keep the backward compatibility as possible. But I think this is a critical issue and I hope you consider it.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1909chtMultiRegionTwoPhaseEulerFoam, pimple2022-05-24T08:14:58ZRobin KamenickychtMultiRegionTwoPhaseEulerFoam, pimple<!--
*** 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 re...<!--
*** 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 -->
Solver reports that it runs PIMPLE mode but actually it runs in PISO mode. Further more, residualControl for PIMPLE cannot be used.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D.
````
$./Allrun
````
Have a look at the log.chtMultiRegionTwoPhaseEulerFoam. It will show
````
PIMPLE: no residual control data found. Calculations will employ 2 corrector loops
````
You can further check that only one outer correction loop was done
![log](/uploads/bc0eaf803d6614eed6a57c2cdd536c3d/log.png)
Then change system/water/fvSolution from
````
PIMPLE
{
nOuterCorrectors 2;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
nEnergyCorrectors 4;
faceMomentum yes;
}
````
into
````
PIMPLE
{
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
nEnergyCorrectors 4;
faceMomentum yes;
}
````
Now, it informs
````
PIMPLE: Operating solver in PISO mode
````
There are no other differences in log because it run before in PISO mode as well. It just informed wrongly.
![log1](/uploads/eee26a12f3287435ec66c42c1fae2e38/log1.png)
Apparently, the solver outer loop logic which loops over fluid and solid regions is based on system/fvSolution. It constructs object of pimpleControl from system/\<region\>/fvSolution, but it does not use it for outer correction loops.
The pimplControl object is constructed in createFluidFields.H but it is used only for pressure correction loops and nonorthogonal correction. Thus, eventhough the number of outercorrectors and residualControl are read from system/\<region\>/fvSolution, they are not used.
The residualControl was tested adding
````
{
p_rgh {relTol 0; tolerance 1e-3;}
}
````
in the PIMPLE dictionary in system/fvSolution and system/water/fvSolution and defining the nOuterCorrectors to 10. However, the residualControl is ignored in system/fvSolution and in system/water/fvSolution is read but not used.
### Example case
Given above
<!--
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?
Given above
<!-- What actually happens -->
### What is the expected *correct* behavior?
It should correctly inform whether PIMPLE runs as PIMPLE or in PISO. Also, residual conrol should be possible to use.
<!-- 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 :v1906 (most probably also in v2006, but not tested)
- Operating system : ubuntu 16.04.6 LTS
- Hardware info :
- Compiler : gcc
### Possible fixes
Perhaps pimpleControl class should be adapted for multiregion solvers.
<!--
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
-->
/lable ~bugv2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1894Equation in Burns.C of Turbulent dispersion model of Burns et al.2022-04-26T16:10:00ZGuan ChaoranEquation in Burns.C of Turbulent dispersion model of Burns et al.Burns is one of the turbulent dispersion models of interficial models in reactingEulerFoam. And the reference is
*Burns, A. D., Frank, T., Hamill, I., & Shi, J. M. (2004, May).The Favre averaged drag model for turbulent dispersion in Eu...Burns is one of the turbulent dispersion models of interficial models in reactingEulerFoam. And the reference is
*Burns, A. D., Frank, T., Hamill, I., & Shi, J. M. (2004, May).The Favre averaged drag model for turbulent dispersion in Eulerian multi-phase flows.In 5th international conference on multiphase flow, ICMF (Vol. 4, pp. 1-17).* [Reference link](https://www.researchgate.net/publication/261761053_The_Favre_Averaged_Drag_Model_for_Turbulent_Dispersion_in_Eulerian_Multi-Phase_Flows)
The equation used in `Burns.C` from the reference is
```math
\vec M_{\alpha}^{TD}=-\vec M_{\beta}^{TD}=-\frac{3}{4}C_D\frac{\overline r_{\beta}\rho_{\alpha}}{d_\beta}|\vec{U_\beta}-\vec{U_\alpha}|\frac{\nu_{t\alpha}}{\sigma_{r\alpha}}(\frac{1}{\overline r_{\alpha}}+\frac{1}{\overline r_{\beta}})\nabla \overline r_{\alpha}
```
And the correspponding source code in `Burns.C` is
```C++
0.75
*drag.CdRe()
*pair_.continuous().nu()
*continuousTurbulence().nut()
/(
sigma_
*sqr(pair_.dispersed().d())
)
*pair_.continuous().rho()
*pair_.dispersed()
*(
1.0/max(pair_.dispersed(), residualAlpha_)
+ 1.0/max(pair_.continuous(), residualAlpha_)
);
```
I tried to translate it into the mathematical form as
```math
\frac{3}{4}C_D\frac{\nu_\alpha\rho_\alpha \overline r_\beta}{d^2_\beta}\frac{\nu_{t\alpha}}{\sigma_{r\alpha}}(\frac{1}{\overline r_{\alpha}}+\frac{1}{\overline r_{\beta}})
```
The two equations seem not to be the same. The interphase velocity term $`|\vec{U_\beta}-\vec{U_\alpha}|`$ is missed in the source code and there is an additional term $`\frac{\nu_{\alpha}}{d_{\beta}}`$ in it.
Is there any relationship between these two terms?v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1876icoUncoupledKinematicParcelFoam description2021-11-02T10:12:25ZAndrew RobertsicoUncoupledKinematicParcelFoam descriptionHello,
I hope this is not an inconvenient time, I am using icoUncoupledKinematicParcelFoam and I just wondered if you knew of any mathematical description of the approach (esp parcel definition, governing equations, integration)? I am on...Hello,
I hope this is not an inconvenient time, I am using icoUncoupledKinematicParcelFoam and I just wondered if you knew of any mathematical description of the approach (esp parcel definition, governing equations, integration)? I am only interested for academic purposes. I've been told to tag @Sergio. Cheers!
Kind regards,
Andy