Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-01-30T15:51:54Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2685Wrong flux with externalWallHeatFluxTemperature2023-01-30T15:51:54ZRémi BoninWrong flux with externalWallHeatFluxTemperature<!--
*** 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
When using the boundary condition _externalWallHeatFluxTemperature_ in _coefficient_ mode and with _thicknessLayers_, _kappaLayers_ and _emissivity_ different from 0, the computed flux is wrong.
### Steps to reproduce
1. Mesh a solid square
2. Left wall and right wall both using _externalWallHeatFluxTemperature_ in _coefficient_ mode with the same _Ta_, same _h_ and _emissivity_ at 0.9 for both.
3. On the right wall, add one _thicknessLayers_ at 0.1 and _kappaLayers_ at 1
3. Top and bottom walls using _zeroGradient_
4. Run the case with _chtMultiRegionSimpleFoam_ (_laplacianFoam_ does not accept _externalWallHeatFluxTemperature_, so you have to manipulate the mesh files a little bit, or you can set up a fluid simulation instead with buoyantSimpleFoam, the same behavior appears).
5. Check the heat flux at both boundaries
### Example case
[case_report.zip](/uploads/a7020df1d2405effedd353c50cbb8d19/case_report.zip)
### What is the current *bug* behaviour?
The heat flux converges to around 2000 W
### What is the expected *correct* behavior?
The heat flux should converge towards 0 W
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system : Windows 10
- Hardware info : 28 cores / 128 GB
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2686Improve length calculation of a spline2023-02-11T18:51:20ZGuanyang XueImprove length calculation of a spline### Functionality to add/problem to solve
Improve the length calculation of a spline. Currently it's using a simple 5-point Gauss-Legendre quadrature without tolerance control.
This is a follow-up of https://develop.openfoam.com/Develo...### Functionality to add/problem to solve
Improve the length calculation of a spline. Currently it's using a simple 5-point Gauss-Legendre quadrature without tolerance control.
This is a follow-up of https://develop.openfoam.com/Development/openfoam/-/issues/1983
### Target audience
Extruding mesh with a spline.
### Proposal
Change the current code to Gauss–Kronrod quadrature with tolerance control.
The algorithm is available in boost library. However to make it independent, it's better to implement the code within [CatmullRomSpline.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/mesh/blockMesh/blockEdges/splineEdge/CatmullRomSpline.C).
I can try to implement a very basic code then you change details to meet your c++ requirements.
Also I would like to implement the length for B-spline as it will be similar. For Bezier I don't have any good idea.
### What does success look like, and how can we measure that?
With tolerance control the curve length can be accurately estimated, so the extruded mesh will be smoother.
### Links / references
https://en.wikipedia.org/wiki/Gauss–Kronrod_quadrature_formula
https://www.boost.org/doc/libs/1_67_0/libs/math/doc/html/math_toolkit/gauss_kronrod.html
### Funding
(Does the functionality already exist/is sponsorship available?)https://develop.openfoam.com/Development/openfoam/-/issues/2688mappedPatchBase is not updated if for topochange after commit 945405c32dca568...2023-02-08T02:40:51ZDarrin StephensmappedPatchBase is not updated if for topochange after commit 945405c32dca5682827356d29fa5557abb3d88d8### Summary
After a recent commit (945405c32dca5682827356d29fa5557abb3d88d8) mappedPatchBase isn't recalculating the map after a topological change to the mesh.
### Steps to reproduce
I'm using the chtMultiRegionDyMFoam solver and libra...### Summary
After a recent commit (945405c32dca5682827356d29fa5557abb3d88d8) mappedPatchBase isn't recalculating the map after a topological change to the mesh.
### Steps to reproduce
I'm using the chtMultiRegionDyMFoam solver and library from https://develop.openfoam.com/Henning86, although it has been updated to work with V2212.
My fork of this can be found here https://github.com/darrinl2t/multiDimAMR/tree/v2212
1. Clone the repository given above.
2. Source OF-v2212
3. Execute the Allwmake script from the multiDimAMR repository
4. Run the heatedRoom tutorial. This will crash at 0.8s when the mesh is changed.
### Example case
An example case is heatedRoom tutorial in the repository link provided above.
### What is the current *bug* behaviour?
The solver crashes after the mesh has been changed. I have isolated this to the Foam::mappedPatchBase::upToDate() function in mappedPatchBaseI.H not returning false after the sampleMesh has been changed.
### What is the expected *correct* behavior?
The expected behaviour is the solver should run. To confirm this checkout commit 013f3cccc41a25b12eb13b32e5e07c09bb3cac3c from the OpenFOAM repository, this is the commit before the changes to mappPatchase. Compile with this commit and recompile the multDimAMR library and solver.
Run the tutorial with the code at this commit, the solver will run fine and the mesh will be adapted to the fluid temperature as expected.
### Environment information
OpenFOAM version : v2212
### Possible fixes
I don't have a fix for this. What I have determined is that after the fluid side mesh has been changed its eventNo() isn't updated, so the test sampleMesh().upToDatePoints(updateSampleMeshTime() returns True when it should be false.https://develop.openfoam.com/Development/openfoam/-/issues/2690contactAngle BC in contactAngleCavity tutorial is not working as expected2023-06-13T11:42:29ZIason TsiapkiniscontactAngle BC in contactAngleCavity tutorial is not working as expected<!--
*** 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
In the tutorial case contactAngleCavity, the free surface of a cavity is simulated with the `interfaceTrackingFvMesh` library. In the simulation a contact angle of 70° is set at the walls via the file `0.orig/contactAngle`. The contact angle after running the tutorial, however, is ~80°.
### Steps to reproduce
1. Copy the case `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contactAngleCavity`
2. Add the following function objects for post-processing (this writes out the first two and last two points on the free surface):
```
pointHistoryLeft1
{
type pointHistory;
refHistoryPoint (0 0.01 0);
fileName leftPoint.txt;
}
pointHistoryLeft2
{
type pointHistory;
refHistoryPoint (0.00025 0.01 0);
fileName leftPointRef.txt;
}
pointHistoryRight1
{
type pointHistory;
refHistoryPoint (0.01 0.01 0);
fileName rightPoint.txt;
}
pointHistoryRight2
{
type pointHistory;
refHistoryPoint (0.00975 0.01 0);
fileName rightPointRef.txt;
}
```
3. Calculate the angle between the first two and the last two points respectively. This can be done by running the accompanied script `postProcessing.py` inside the simulation directory.
### 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 attached the tutorial case with slight modifications in the `functionObjects`, together with the post-processing script.
Run the case using the `Allrun` script.
[contactAngleCavity.tar](/uploads/2bee417aad9c1e7704685b1632fd4804/contactAngleCavity.tar)
### What is the current *bug* behaviour?
The contact angle at the specified locations is not equal to the set contact angle.
### What is the expected *correct* behavior?
The contact angle should be 70°, as specified in `0.orig/contactAngle`.
### 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.
-->
The Figure below shows the calculated angle between the first two and the last two mesh points. Note that the angle does not change with a longer run time. The tutorial runs only for 0.2s.
![contactAngle](/uploads/d64c2e7a4cbb976a264e470ab9c7a47b/contactAngle.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212
Operating system : ubuntu docker container on windows
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v2212
Operating system : ubuntu docker container on windows
### 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
-->
The calculations regarding the contact angle can be found in the file
```$FOAM_SRC/dynamicFaMesh/interfaceTrackingFvMesh/freeSurfacePointDisplacement.C```
in lines 120-197. In this approach, the vector `N` is rotated by the value of `contactAngle` at the specified boundaries. The `patchMirrorPoints` at this boundary are then moved using (line 225f.):
```
patchMirrorPoints[patchI] =
peCentres + ((I - 2*N*N)&delta);
```
Maybe the innermost `controlPoints` have to be moved as well to satisfy the contact angle.https://develop.openfoam.com/Development/openfoam/-/issues/2692Patch buckling using velocityLaplacian motionSolver on specified patches2023-01-31T20:21:30ZManuel ZeitlerPatch buckling using velocityLaplacian motionSolver on specified 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 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
If a rotating motion is enforced on only a few patches (not the whole object; used to "grow" the object during the simulation) using the motionSolver velocityLaplacian, some patches start to buckle in on themselves.
### Steps to reproduce
My test case can be found here: https://github.com/ZeitM/SurfaceBuckling
>There are also 2 png-files included, showing the problem
1. Clone the given repository
2. Execute using overInterDyMFoam
3. inspect the results in paraview (area of interest: the 2ircleSections defined as arc...)
### What is the current *bug* behaviour?
After a few timesteps the moving patches start to buckle in on themselves, resulting in a very jagged geometry. (Important: The problem is considered only if the patches buckle in on themselves, not if the mesh/geometry bends between two patches)
### What is the expected *correct* behavior?
It is expected that the patches don't buckle in on themselves and stay "straight"/stay as one flat plane.
### Environment information
OpenFOAM version : v2206https://develop.openfoam.com/Development/openfoam/-/issues/2694Sourcecode Links in Extended Code Guide (API Guide) are broken2023-02-03T09:05:21ZFranz DSourcecode Links in Extended Code Guide (API Guide) are brokenFor example on this page: https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1functionObjects_1_1filmFlux.html#details
In the "detailed description" section, in the Source Files box, there are two links given to this r...For example on this page: https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1functionObjects_1_1filmFlux.html#details
In the "detailed description" section, in the Source Files box, there are two links given to this repo:
![image](/uploads/8cbbbdf92d8a673c133d33038b72325f/image.png)
This is actually where it links (and 404s) `https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/regionModels/surfaceFilmModels/functionObjects/filmFlux/filmFlux.H`
This is happening for all links to the Repo that I have tried.https://develop.openfoam.com/Development/openfoam/-/issues/2695Links in snappyHexMesh section in online userguide not working2023-03-14T17:10:27ZJohan RoenbyLinks in snappyHexMesh section in online userguide not workingGo here:
https://www.openfoam.com/documentation/user-guide/4-mesh-generation-and-conversion#x14-570004.4.7
and try to click "4.4 Mesh generation with the snappyHexMesh utility" or any of its subsections.
I tried in Chrome and Firefox ...Go here:
https://www.openfoam.com/documentation/user-guide/4-mesh-generation-and-conversion#x14-570004.4.7
and try to click "4.4 Mesh generation with the snappyHexMesh utility" or any of its subsections.
I tried in Chrome and Firefox where nothing happens when I click the links.https://develop.openfoam.com/Development/openfoam/-/issues/2697solverInfo function object: U_converged flag is always false2023-02-03T09:05:03Zs1291solverInfo function object: U_converged flag is always falseHello,
I have used the `solverInfo` function object in many examples, including the official tutorials, such as `$FOAM_TUTORIALS/tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`. Even though the linear solvers for velocity converg...Hello,
I have used the `solverInfo` function object in many examples, including the official tutorials, such as `$FOAM_TUTORIALS/tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`. Even though the linear solvers for velocity converge, the `U_converged` flag is always `false`.
Attached is an example of `solverInfo` log file.
Could you please confirm if this is a bug within the function object itself? or am I missing something?
[solverInfo.dat](/uploads/59596761e8a22e6160833c3f4a14039d/solverInfo.dat)https://develop.openfoam.com/Development/openfoam/-/issues/2698jouleHeating and electric contact resistance is delivering wrong results - co...2023-02-03T15:48:26ZAndreas SchützenbergerjouleHeating and electric contact resistance is delivering wrong results - comparison between openFoam, Comsol and theory - turbulentTemperatureRadCoupledMixedThe description of the problem is in the attachted pdf file.
OpenFOAM version : v2212
Operating system : ubuntu
solver: chtMultiRegionSimpleFoam
[bug_jouleheating.pdf](/uploads/ea26a9667581e90cf77eb97d0c20024a/bug_...The description of the problem is in the attachted pdf file.
OpenFOAM version : v2212
Operating system : ubuntu
solver: chtMultiRegionSimpleFoam
[bug_jouleheating.pdf](/uploads/ea26a9667581e90cf77eb97d0c20024a/bug_jouleheating.pdf)[stab_joule.zip](/uploads/5ead128f3cad12a49668f60893c7c7d6/stab_joule.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2700coincidentBaffleInteraction missing from the source code (but present in the ...2024-01-04T09:46:28ZFranz DcoincidentBaffleInteraction missing from the source code (but present in the documentation?)In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not worki...In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not working.
Seems to be a long-standing issue:
https://bugs.openfoam.org/view.php?id=2939
https://www.cfd-online.com/Forums/openfoam-solving/141571-cyclic-boundary-conditions-particles.htmlAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2705dynamicRefineFVMesh support for Overset meshes2023-02-22T08:55:33ZMatt GuentherdynamicRefineFVMesh support for Overset meshes### Functionality to add/problem to solve
For ship simulations using overset mesh motion, the free surface interface is difficult to capture properly. If the background mesh is refined, the cell sizes are not matched well to the overset...### Functionality to add/problem to solve
For ship simulations using overset mesh motion, the free surface interface is difficult to capture properly. If the background mesh is refined, the cell sizes are not matched well to the overset mesh of the ship. By extending the existing capability of dynamicRefineFVMesh to be able to be applied to overset simulations, the free surface could be better defined.
### Target audience
For high speed vessels that have the most to gain from overset mesh due to their large mesh motions, the wave resistance is comparatively high, so good capture of the interface is important. This feature will increase interest in openfoam in a larger number of naval architecture companies.
High speed planing hulls with large displacement motion.
### Proposal
(How are we going to solve the problem?) Rework the dynamicMesh functionality to enable both dynamicRefineFVMesh and dynamicOversetFVMesh to be defined together.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
For a simple case, use the rigidbody test case found in overInterDYMFoam and extend it to have free surface refinement, as found in damBreakWithObstacle tutorial (multiphase/interfoam/laminar).
less than 10% error resistance in head seas, See figure 8 of reference below.
### Links / references
(Links to literature, supporting information)
Jeonghwa Seo, Hak-Kyu Choi, Uh-Cheul Jeong, Dong Kun Lee, Shin Hyung Rhee, Chul-Min Jung, Jaehoon Yoo,
Model tests on resistance and seakeeping performance of wave-piercing high-speed vessel with spray rails,
International Journal of Naval Architecture and Ocean Engineering,
Volume 8, Issue 5,
2016,
Pages 442-455,
ISSN 2092-6782,
https://doi.org/10.1016/j.ijnaoe.2016.05.010.https://develop.openfoam.com/Development/openfoam/-/issues/2707extractEulerianParticles does not work correctly if it targets a faceZone on ...2023-02-22T08:55:52ZJunichi MukaiextractEulerianParticles does not work correctly if it targets a faceZone on a boundary with patchID of zero### Summary
All particles are discarded if target faceZone is on a boundary with patchID of zero.
### Steps to reproduce
1. Copy the tutorials of 'multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection'.
2. Move the boundary ...### Summary
All particles are discarded if target faceZone is on a boundary with patchID of zero.
### Steps to reproduce
1. Copy the tutorials of 'multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection'.
2. Move the boundary entry of the 'bottom' patch to first in system/blockMesh dictionary.
3. Exexute Allrun.
### Example case
[eulerianInjection.tar.gz](/uploads/6f95e6bafa0452e6ad4a2459e1c2fc85/eulerianInjection.tar.gz)
### Environment information
- OpenFOAM version : v2212
### Possible fixes
```
diff extractEulerianParticlesTemplates.C extractEulerianParticlesTemplates.C_fixed
46c46
< if (patchi != 0)
---
> if (patchi != -1)
```https://develop.openfoam.com/Development/openfoam/-/issues/2711dynamicOversetFvMesh with displacementLaplacian/velocityLaplacian does not pr...2023-11-09T15:05:13ZPhilip CardiffdynamicOversetFvMesh with displacementLaplacian/velocityLaplacian does not preserve zeroGradient on overset 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 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
The bug can be observed by making a minor modification to `$FOAM_TUTORIALS/incompressible/overPimpleDyMFoam/cylinder`:
- Change the boundary condition for the `walls` patch in `cylinderAndBackground/0/pointDisplacement` to
- ```
walls
{
type oscillatingDisplacement;
amplitude (1 0 1);
omega 3.14;
value uniform (0 0 0);
}
```
I have attached this case (bug.cylinder.displacementLaplacian.tgz) below.
Incorrect behaviour can also be produced using the velocityLaplacian motion solver on this case instead of the displacementLaplacian solver; to reproduce this behaviour, make the following modifications to the same `cylinder` case:
- rename `cylinderAndBackground/0/pointDisplacement` to `cylinderAndBackground/0/pointMotionU`
- In the header of `cylinderAndBackground/0/pointMotionU`, update the `object` to `cellMotionU`
- In `cylinderAndBackground/0/pointMotionU`, change the `walls` boundary condition to:
- ```
walls
{
type fixedValue;
value uniform (1 0 1);
}
```
- In `cylinderAndBackground/constant/dynamicMeshDict`, replace `displacementLaplacian` with `velocityLaplacian`
- In `cylinderAndBackground/system/fvSolution`, replace `cellDisplacement` with `cellMotionU`
I have also attached this case (bug.cylinder.velocityLaplacian.tgz) below.
### 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
-->
As noted above, here are the two cases:
- [bug.cylinder.displacementLaplacian.tgz](/uploads/96db22f3dc5e08cf99d1471c9185cb17/bug.cylinder.displacementLaplacian.tgz)
- [bug.cylinder.velocityLaplacian.tgz](/uploads/33646d8b4e495ee03b2de1dea3b19ed3/bug.cylinder.velocityLaplacian.tgz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
As the mesh boundary condition for the overset patch is `zeroGradient` (`overset { patchType overset; type zeroGradient; }`), I expect the overset mesh region around the cylinder to rigidly translate over the background mesh. However, in the two cases above, you will see that the overset mesh patch is not acting as `zeroGradient`. For the displacementLaplacian case, it seems to act as zero `fixedValue`, whereas, for the velocityLaplacian case, it seems to act as a normal overset patch (i.e. coupled to the background mesh).
As a result, in both cases, the simulation crashes due to extreme mesh deformations in the overset region.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The expected behaviour in both cases is that the overset mesh region rigidly translates over the background mesh and the background mesh does not move.
### 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.
-->
Here is an image of the mesh just before crashing in the displacementLaplacian case, where the overset patch mesh condition seems to act like `fixedValue`:
![pointDisplacement_field_before_crash](/uploads/11eca913b55c15a996031e3a4be80d62/pointDisplacement_field_before_crash.png)
Here is an image of the mesh just before crashing in the velocityLaplacian case, where the overset patch mesh condition seems to act like a normal `overset` condition:
![pointMotionU_field_before_crash](/uploads/073fbda728b4ebeab289c9fc5b96cc70/pointMotionU_field_before_crash.png)
With the user-fix proposed below, the correct behaviour is observed for both cases:
![pointDisplacement_field_with_fix](/uploads/dab91b541c3bcf53f02b2836512d5b07/pointDisplacement_field_with_fix.png)![pointMotionU_field_with_fix](/uploads/62b501584af8455fa6b3b760b7d96ac2/pointMotionU_field_with_fix.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212
Operating system : ubuntu|macOS (should be the same on all)
Hardware info : N/A
Compiler : gcc|clang (should be independent of the compiler, but I have checked gcc on Ubuntu and clang on macOS
-->
- OpenFOAM version : v2212
- Operating system : I have chedk ubuntu and macOS but it should be the same on all OSes
- Hardware info : N/A
- Compiler : I checked gcc (on Ubuntu) and clang (on macOS) but it should be independent of the 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
-->
The problem seems to come from the construction of the boundary conditions for the `cellDisplacement` field in the displacementLaplacian class and the `cellMotionU` field in the velocityLaplacian class. The `zeroGradient` condition on the overset mesh patch does not seem to be correctly copied from the `pointDisplacement` and `pointMotionU` fields.
A simple user workaround is to provide the cell mesh motion fields in the case, including the correct boundary conditions on the overset patch. These user-provided fields are used because the cell fields are `READ_IF_PRESENT` in the displacementLaplacian and velocityLaplacian motion solvers.
For example, to fix the `displacementLaplacian` case, add the following `cellDisplacement` file to `cylinderAndBackground/0/`:
```
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object cellDisplacement;
}
dimensions [0 1 0 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
overset
{
patchType overset;
type zeroGradient;
}
walls
{
type cellMotion;
value uniform (0 0 0);
}
".*"
{
type uniformFixedValue;
uniformValue (0 0 0);
}
}
```
Similarly, to fix the `velocityLaplacian` case, add the following `cellMotionU` file to `cylinderAndBackground/0/`:
```
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object cellMotionU;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 0 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
overset
{
patchType overset;
type zeroGradient;
}
walls
{
type cellMotion;
value uniform (0 0 0);
}
".*"
{
type uniformFixedValue;
uniformValue (0 0 0);
}
}
```
Here are the two modified cases:
- [fix.cylinder.displacementLaplacian.tgz](/uploads/a5dbd28c2c608f87e37705e4f1f17b56/fix.cylinder.displacementLaplacian.tgz)
- [fix.cylinder.velocityLaplacian.tgz](/uploads/4e952262f0b1087b2132dbd4f75b6a30/fix.cylinder.velocityLaplacian.tgz)
This user fix is a simple workaround; however, it would be better if this was fixed within the code, such that `zeroGradient` conditions on overset patches are correctly mapped from point fields to cell fields.https://develop.openfoam.com/Development/openfoam/-/issues/2713searchbox in the overset is expected to move along the motion of the object, ...2023-02-24T08:35:34Zgrace wsearchbox in the overset is expected to move along the motion of the object, rather than fixed in the space### Functionality to add/problem to solve
(Brief scope)
In overset function, searchbox is set to narrow the search area and improve the hole-search efficiency. However, the searchbox is fixed in the mesh, other than moving along with t...### Functionality to add/problem to solve
(Brief scope)
In overset function, searchbox is set to narrow the search area and improve the hole-search efficiency. However, the searchbox is fixed in the mesh, other than moving along with the object.
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
The efficiency of overset function can be benefited by setting the searchbox moving along the object.
### Proposal
(How are we going to solve the problem?)
1 extract the mesh motion from Mesh class, 2 add the mesh motion to searchbox, which reduces the size of the searchbox and improve the efficiency of the overset mesh.
I find the motion is calculated from transformation and transformPoints. I would like to isolate the displacement for searchbox motion.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
I think the tutorial case can be a test case.https://develop.openfoam.com/Development/openfoam/-/issues/2717SelectionMode geometric requires cellZone name in DarcyForchheimer fvOptions2023-03-13T13:49:27ZTobias HolzmannSelectionMode geometric requires cellZone name in DarcyForchheimer fvOptions<!--
*** 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
-->
As described by @Prashant in EP2090 the selectionMode namely geometric can be used within the DarcyForchheimer model but we need also to specify the keyword "cellZone" while specifying a cellZone in addition. This does not make sense and is inconsistent as the cellZone is comming from the geometric selection mode.
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Add an fvOption in such a way:
```
porousity
{
type explicitPorositySource;
active true;
explicitPorositySourceCoeffs
{
type DarcyForchheimer;
d d [0 -2 0 0 0 0 0] (1e12 1e12 1e12);
f f [0 -1 0 0 0 0 0] (0 0 0);
coordinateSystem
{
origin (0 0 0);
e1 (1 0 0);
e2 (0 1 0);
}
selectionMode geometric;
selection
{
box
{
action use;
source box;
min (0 -1 -1);
max (1 0 1);
}
}
}
}
```
<!-- How one can reproduce the issue - this is very important -->
### Example case
Any tutorial 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?
Selection mode "geometric" requires a cellZone in addition.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Selection mode "geometric" should be usable without specification of a cellZone
<!-- 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system :
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2718Proposal: Meson Build System2023-09-07T19:03:22ZVolker WeißmannProposal: Meson Build SystemIn [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936) we first talked about meson as an alternative build system. In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1984#note_57979) I p...In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936) we first talked about meson as an alternative build system. In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1984#note_57979) I presented the first prototype. Now we need to talk about how this project should continue. Please either respond in writing, or we can arrange a Jitsi-Meeting in English or German, whatever you prefer.
Example How to build and run:
```shell
git clone https://develop.openfoam.com/Development/openfoam.git
cd openfoam
git checkout 988ec18ecc
wget https://codeberg.org/Volker_Weissmann/foam_meson_patches/raw/branch/trunk/for_openfoam_commit_hash_988ec18ecc.diff
git apply ../for_openfoam_commit_hash_988ec18ecc.diff
meson setup ../build # Takes about 10 seconds
cd ../build
ninja # Takes hours
meson devenv # Launches a subshell that has some environmental variables (among others: $PATH) set.
cd ../openfoam/tutorials/basic/laplacianFoam/flange
./Allrun
```
(You can replace ../build with any path you like, no matter if its inside of the openfoam folder or not.)
Note that the above is a debug build, i.e. equivalent to setting "WM_COMPILE_OPTION=Debug". If you want a release build, i.e. equivalent to "WM_COMPILE_OPTION=Opt", you need to add a flag like this:
```
meson setup ../build --buildtype=release
```
I generated patches for the openfoam version with the commit hash 988ec18ecc, but I can generate patches for other versions too, just tell me what versions you need patches for.
# Open Issues
I have not looked at the ThirdParty folder yet, but that can follow.
I know that the OpenFOAM project needs to generate binary packages for different distributions. I have not looked closer at that yet, but that can follow.
The following dependencies are currently never used:
- zoltan
- mgrid
- ccmio
- kahip
- scotch
Again, fixing this is possible, but I want to fix this after we know what direction the project is gonna take.
## Build Subfolders seperately
One good thing about wmake is that you can copy e.g. the `applications/solvers/lagrangian/reactingParcelFoam/simpleReactingParcelFoam` folder to some other path outside of the openfoam folder, modify the contents a bit and run `wmake` inside that folder to build it. I think we will have to talk about that more than about any other feature. Currently, my build system offers no similar feature, but I have ideas on how to implement something like that.
## OS Support
I only tested it on my ArchLinux machine, and on a debian docker container, with the following additional packages installed:
```sh
apt-get install -y git g++ zlib1g-dev libfftw3-dev mpi-default-dev libboost-system-dev flex
```
I installed meson from source, since the packaged version is too old (we need at least 0.59.0).
This was the script I ran on Debian:
```
set -euo pipefail
IFS=$'\n\t'
cd /root
apt update
apt install -y git g++ zlib1g-dev libfftw3-dev mpi-default-dev libboost-system-dev flex python3 ninja-build wget
wget https://codeberg.org/Volker_Weissmann/foam_meson_patches/raw/branch/trunk/for_openfoam_commit_hash_988ec18ecc.diff
git clone https://github.com/mesonbuild/meson || true
cd meson
git checkout 0.59.0
cd ..
git clone https://develop.openfoam.com/Development/openfoam.git
cd openfoam
git checkout 988ec18ecc
git apply ../for_openfoam_commit_hash_988ec18ecc.diff
../meson/meson.py setup ../build
cd ../build
ninja
../meson/meson.py devenv bash -c "cd ../openfoam/tutorials/basic/laplacianFoam/flange && ./Allrun"
```
Support for other OS's should not be much work.
If we decide to continue this project, I will setup proper testing on different OS's.
# Advantages over wmake
While wmake is only used by the openfoam project, meson is used by many different projects and has way more/better documentation that wmake. So if you know how to use meson, you know how to use it in the OpenFOAM project.
The meson.build files are very easy to read.
`meson setup` generates a compilation_commands.json file with can be [useful to IDE's](https://openfoamwiki.net/index.php/HowTo_Use_OpenFOAM_with_Visual_Studio_Code). No need for any slow hacks anymore.
I have not confirmed the following with measurements yet, but I will do so if we decide to continue this project:
A clean compile is about as fast as a clean compile with Allwmake. Incremental builds however, are *way* faster. If nothing has changed and you run `ninja` again, this takes 2-5 seconds (and we could further reduce that time). In contrast, running `./Allwmake` in the top-level directory will take over a minute on the same machine.
Afaik, meson is better at knowing what needs to be rebuilt and what does not. This results in faster incremental builds and less wrong builds (I vaguely remembering having trouble that wmake did not recompile stuff that changed, leading to a confusing debugging session).
Afaik, if you build openfoam, then do `git pull` and run `./Allwmake` again, it is possible that this will fail and you have to manually run `wclean`. This happened to me, when I upgraded from `0031cb1efac0d550334108346f26dde5e707b6fd` to `988ec18ecca76aa0cef65acbab765374416d61b6`:
```
make: *** No rule to make target 'fields/faPatchFields/constraint/processor/processorFaPatchScalarField.H', needed by '/home/volker/Documents/foam/openfoam/build/linux64GccDPInt32Opt/src/finiteArea/fields/faPatchFields/constraint/processor/processorFaPatchFields.C.dep'. Stop.
```
Meson on the other hand, is afaik quite robust in such cases. The only thing that ever forced manual intervention or a clean rebuild was if I made changes to the OS (e.g. removing a package that is an optional dependency of OpenFOAM, or when I built in on one machine and copied the build folder to a different machine).
If you just want to build a single binary, you ran run `ninja targetname` and it will build this binary and all of its dependencies. With wmake, you either have to run `./Allwmake` in the top directory, which is slow, or manually go into each directory that is a dependency of this binary and run `wmake` there.
If you add "#include something.C" to a source file, then run `wmake`, then remove that line and the file, `wmake` will fail with
```
make: *** No rule to make target 'something.C', needed by '/home/volker/Sync/git/foam_meson/legacy/build/linux64GccDPInt32Opt/src/parallel/reconstruct/faReconstruct/processorFaMeshes.C.dep'. Stop.
```
You have to run `wclean` to fix this. The same thing works fine with meson/ninja.
If you build (at least a part of) OpenFOAM, then change `WM_COMPILE_OPTION`, and run `./Allwmake`, it will not recompile the things that were compiled with the old `WM_COMPILE_OPTION`. Ninja will recompile everything that is necessary. (With wmake, I had to delete my build folder many times because I forget if I had always set WM_COMPILE_OPTION correctly.)
If your machine is missing a dependency of OpenFOAM, meson will error during the first few seconds and tell you that you are missing that dependency. With wmake on the other hand, it might compile for hours until you see that some header file cannot be found. (Trying to build OpenFOAM on a machine that uses musl-libc instead of glibc was fun.)
With meson, you can do out-of-tree builds.
Make interleaves the output of multiple cores, Ninja does not.https://develop.openfoam.com/Development/openfoam/-/issues/2722BUG: Error in setReference behaviour with moving mesh, correctPhi and paralle...2023-04-06T12:16:12ZJohan RoenbyBUG: Error in setReference behaviour with moving mesh, correctPhi and parallel runI have noticed generation of spurious bubble generation in the bulk of the liquid when working with interIsoFoam or interFoam combined with moving mesh in parallel and using correctPhi in fvSolution->PIMPLE. My investigations indicate th...I have noticed generation of spurious bubble generation in the bulk of the liquid when working with interIsoFoam or interFoam combined with moving mesh in parallel and using correctPhi in fvSolution->PIMPLE. My investigations indicate that there is a bug in the setting of the reference pressure (fvMatrix::setReference).
I have attached a minimal test case to this issue report which illustrates the problem. The case is based on v2206. The case is a simple square domain filled water and oscillating sinusoidally back and forth with a coded dynamicMeshDict. The case only includes 1 time step since this is enough for the problem to arise. To reproduce the problem, simply run the Allrun script in the case and look with paraview at the alpha.water values in the bottom of the domain (load the state.pvsm file to also see phi vectors). What you see is overshoot in the leftmost cell, which is cell 0 in processor0, and a corresponding undershoot in the leftmost cell (label 0) at the bottom of processor1:
![Udklip](/uploads/b95d10e0d21fc6361fd4f40110f3601f/Udklip.JPG)
The problem happens with both interFoam and interIsoFoam.
The flow is not solved (frozenFlow), but the correctPhi is set to "yes" in fvSolution->PIMPLE.
If correctPhi is set to "no" the problem disappears.
If the case is run in serial, the problem disappears.
If an "atmosphere" inlet/outlet is added to the top, so that no reference pressure is set, the problem disappears.
If I use 4 or 16 subdomains in decomposeParDict instead of 2, it is clear that it is the 0'th cell on each processor that is over- or undershooting in alpha.water:
![Picture1](/uploads/8e90bd9852dfe04ca193d2c1d0460e30/Picture1.png)
In the case, phi is corrected in the first time step using CorrectPhi(...). The Foam::CorrectPhi function has hardcoded cell 0 to be the reference cell:
pcorrEqn.setReference(0, 0);
If I change this to pcorrEqn.setReference(2, 0), I observe that the problematic cells move two cells to the right.
I assume that there should not be a reference cell for each processor, but a single reference cell on the entire domain to which all other cell pressures should refer.
Plotting phi-vectors in paraview, as done with the state.pvsm file supplied with the case, I have confirmed that the alpha.water over- and undershooting arise due to nonzero div(phi) where phi is the corrected phi from CorrectPhi.
Does anyone have an idea for how to fix this problem?
Test case: [oscillatingTank.zip](/uploads/50eae14bdb13ea752164a5845bee446e/oscillatingTank.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2723avoid register/deregister of tmp fields2024-02-21T13:32:54ZMark OLESENavoid register/deregister of tmp fieldsBy default IOobject uses (REGISTER). When a tmp field is created, its name will be registered in the corresponding objectRegistry (invoking an allocation to add to the HashTable, plus calculation of a hash value etc). If the tmp leaves s...By default IOobject uses (REGISTER). When a tmp field is created, its name will be registered in the corresponding objectRegistry (invoking an allocation to add to the HashTable, plus calculation of a hash value etc). If the tmp leaves scope immediately, it is removed from the registry which incurs another delete in addition to that of the tmp itself.https://develop.openfoam.com/Development/openfoam/-/issues/2725changeDictionary does not work for multiple regions (i. e. for chtMultiRegion...2023-06-30T15:04:24ZMarco MüllerchangeDictionary does not work for multiple regions (i. e. for chtMultiRegionFoam) on mingw cross compilation### Summary
based on what I see, only the last solid region in the regionProperties lists can be handled with changeDictionary. All other regions abort.
### Steps to reproduce
run i. e. chtMultiRegionFoam\multiRegionHeater tutorial
...### Summary
based on what I see, only the last solid region in the regionProperties lists can be handled with changeDictionary. All other regions abort.
### Steps to reproduce
run i. e. chtMultiRegionFoam\multiRegionHeater tutorial
### What is the current *bug* behaviour?
changeDictionary sets the dictionaries correctly
### What is the expected *correct* behavior?
changeDictionary aborts
### Relevant logs and/or images
i.e. log.changeDictionary.leftSolid (unicode character 0x80 at the end):
...
Create mesh leftSolid
for time = 0
fileName::stripInvalid() called for invalid fileName leftSolid
For debug level (= 2) > 1 this is considered fatal
### Environment information
- OpenFOAM version : tested v2212|v2206|v2112|v2106|v2012|v2006
- Operating system : Win 10
- Hardware info :
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/2726createPatch removes newly added patches2023-03-22T11:23:39ZDarren GarveycreatePatch removes newly added patchesI am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the com...I am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the commit ad6d3a088eb5bfeab806e159f25526a102deb3bc changed the behaviour, specifically with the removal of
```
void filterPatches(polyMesh& mesh, const wordHashSet& addedPatchNames)
```
Where `addPatchNames` was there to make sure that `createPatch` doesn't remove newly created patches when they have no faces.
The `system/createPatchDict` to reproduce this is simple:
```
pointSync false;
patches
(
{
name patch_0_1_back;
patchInfo
{
type patch;
}
constructFrom patches;
patches ();
}
);
```
The newer versions of `createPatch` (since v2206) add then remove this patch:
```
Removed zero-sized patch patch_0_1_back type patch at position 9
```
It is possible that this use-case isn't supported and/or there is a Better Way to do it. Is there a good reason this feature should not be added back into `createPatch` (before I look at doing that)?