Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-11-09T15:05:13Zhttps://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/3018pTraits for complex looks incorrect2023-11-13T13:53:25ZMark OLESENpTraits for complex looks incorrectThe complex type is defined to have two components (ie, real, imag) but has cmptType as "complex" - doesn't really make sense, and has labelType as label anyhow.
It doesn't seem to be used anywhere but could be interesting with different...The complex type is defined to have two components (ie, real, imag) but has cmptType as "complex" - doesn't really make sense, and has labelType as label anyhow.
It doesn't seem to be used anywhere but could be interesting with different backends (eg ADIOS).
@andy @kutiv2406Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3026rigidBodyMotion linearAxialAngularSpring theta angle appears to be incorrectl...2023-11-16T15:20:33ZChristian RohrrigidBodyMotion linearAxialAngularSpring theta angle appears to be incorrectly signed - spring acts in wrong direction### Summary
Theta angle used in (at least) `linearAxialAngularSpring.C` in the rigidBodyMotion solver appears to be signed incorrectly.
### Steps to reproduce
Apply the linearAxialAngularSpring restraint to a body, and observe it be p...### Summary
Theta angle used in (at least) `linearAxialAngularSpring.C` in the rigidBodyMotion solver appears to be signed incorrectly.
### Steps to reproduce
Apply the linearAxialAngularSpring restraint to a body, and observe it be pulled in the wrong direction. Have tested with pimpleDyMFoam. This has occured on another case which I cannot share, so I have created a new one from one of the tutorials.
Modifying the code for this restraint to ouptut the current angular position shows that the "theta" variable is signed incorrectly. For example a clockwise rotation around the z axis of 45° will be reported as 45° instead of -45°.
### Example case
Attached a case modified from the overset airfoil simpleFoam tutorial. It has been made transient, switched to rigidBody, and a spring constraint has been applied. Increasing the stiffness of this spring exacerbates the movement of the airfoil rather than assisting.
[testCase_axialSpring.zip](/uploads/676fc081bc3e63b66c9376639aa163e3/testCase_axialSpring.zip)
### What is the current _bug_ behaviour?
Spring moment acts in wrong direction.
### What is the expected _correct_ behavior?
A positive rotation should create a negative torque.
### Relevant logs and/or images
In the example case, I have attached a spring at the bottom of the domain to the airfoil with an Rz joint. The spring pulls the airfoil down and to the right, and this is accelerated for higher spring stiffnesses. Some movement in that direction is expected for the aerodynamic load, but it should reduce with increasing stiffness rather than worsen.
The case should be run with a stiffness of 1 and then with a stiffness of 100 to observe the issue.
Alternatively, add an `Info <<` message reporting the theta angle of the airfoil body at line 143 of `linearAxialAngularSpring.C` : it is signed incorrectly for the observed rotations.
![image.png](/uploads/71c2ddc6030e147d4b073b8df15267aa/image.png){width="314" height="299"}
### Environment information
- OpenFOAM version : v2112
- Operating system : WSL - OpenSUSE Leap 15.4
- Hardware info : x86_64
- Compiler : gcc
### Possible fixes
Manual flip to theta's sign on line `112` of `linearAxialAngularSpring.C`. But I have not been able to get to the bottom of why this is incorrectly signed to begin with. Could this just be due to case configuration?https://develop.openfoam.com/Development/openfoam/-/issues/3027Evaporation of two liquid phases using icoReactingMultiphaseInterFoam2023-11-16T15:20:51ZMark YEvaporation of two liquid phases using icoReactingMultiphaseInterFoam### Summary
The Solver I used is the icoReactingMultiphaseInterFoam V2306, the Ubuntu version is 20.04.
I try to simulate two different liquid droplets, i.e., liquid1 and liquid2, evaporating to the gas phase. If I set two liquid drop...### Summary
The Solver I used is the icoReactingMultiphaseInterFoam V2306, the Ubuntu version is 20.04.
I try to simulate two different liquid droplets, i.e., liquid1 and liquid2, evaporating to the gas phase. If I set two liquid droplets, the vapor of the liquid, i.e., vapor1, occurs in both two locations, see the picture(the same as vapor2). Physically, vapor1 should occur in location 1 and vapour2 should occur at location 2.
![figure](/uploads/1b20be65014dcb0ad7784a44b6f28dee/figure.png)
I found the code to calculate the massSpeciesTransfer in multiphaseInter::MassTransferPhaseSystem.C. No matter what species is transferred from the liquid phase (liquid1 or liquid2), the value of Su is the same.
The attached is the setting case.[debug.tar.gz](/uploads/83421f905cc567ec6fd5249dac37fee9/debug.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/3029Adding the repositories and trying to update apt in WSL with Ubuntu 18.04 LTS...2023-11-16T15:27:35ZMatti ViljamaaAdding the repositories and trying to update apt in WSL with Ubuntu 18.04 LTS reports 404 Not found on some URLs even though the URLs work in a browser.<!--
*** 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 -->
Adding the repositories and trying to update apt in WSL with Ubuntu 18.04 LTS reports 404 Not found on some URLs even though the URLs work in a browser.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
I am using WSL with Ubuntu 18.04 LTS and the guide at:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/windows
and in particular:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
I am doing:
`curl https://dl.openfoam.com/add-debian-repo.sh | sudo bash`
and adding trusted=yes to:
deb [trusted=yes arch=amd64] https://dl.openfoam.com/repos/deb bionic main
in
/etc/apt/sources.list.d/openfoam.list
(This fixes another problem with the repositories. You can see the problem by removing trusted=yes.)
After this, shell reports 404 on some urls when doing the `sudo apt-get update` even though the URL (https://downloads.sourceforge.net/project/openfoam/repos/deb/dists/bionic/main/binary-amd64/Packages?ts=gAAAAABlU0ddE33NYF2BYJCrUgKdzm3tdc4pT5s50s0bO4jq_uOT3e-imqmuDbyW9FG41PrmLX9L7rvax9Dfyt7RR5uaZ2ydbg==&use_mirror=master&r=) itself works in a browser. Full output:
```
sudo apt-get update
Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Ign:5 https://sourceforge.net/projects/openfoam/files/repos/deb bionic InRelease
Ign:6 https://sourceforge.net/projects/openfoam/files/repos/deb bionic Release
Ign:7 https://dl.openfoam.com/repos/deb bionic/main amd64 Packages
Ign:8 https://dl.openfoam.com/repos/deb bionic/main all Packages
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:7 https://dl.openfoam.com/repos/deb bionic/main amd64 Packages
Ign:8 https://dl.openfoam.com/repos/deb bionic/main all Packages
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:7 https://dl.openfoam.com/repos/deb bionic/main amd64 Packages
Ign:8 https://dl.openfoam.com/repos/deb bionic/main all Packages
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:9 https://dl.openfoam.com/repos/deb bionic/main Translation-en
Ign:10 https://dl.openfoam.com/repos/deb bionic/main all c-n-f Metadata
Ign:11 https://dl.openfoam.com/repos/deb bionic/main amd64 c-n-f Metadata
Ign:7 https://sourceforge.net/projects/openfoam/files/repos/deb bionic/main amd64 Packages
Ign:7 https://sourceforge.net/projects/openfoam/files/repos/deb bionic/main amd64 Packages
Ign:7 https://dl.openfoam.com/repos/deb bionic/main amd64 Packages
Ign:7 https://dl.openfoam.com/repos/deb bionic/main amd64 Packages
Ign:8 https://sourceforge.net/projects/openfoam/files/repos/deb bionic/main all Packages
Ign:8 https://sourceforge.net/projects/openfoam/files/repos/deb bionic/main all Packages
Ign:8 https://dl.openfoam.com/repos/deb bionic/main all Packages
Ign:8 https://dl.openfoam.com/repos/deb bionic/main all Packages
Err:7 https://sourceforge.net/projects/openfoam/files/repos/deb bionic/main amd64 Packages
404 Not Found [IP: 82.71.205.33 443]
Reading package lists... Done
E: Failed to fetch https://downloads.sourceforge.net/project/openfoam/repos/deb/dists/bionic/main/binary-amd64/Packages?ts=gAAAAABlU0ddE33NYF2BYJCrUgKdzm3tdc4pT5s50s0bO4jq_uOT3e-imqmuDbyW9FG41PrmLX9L7rvax9Dfyt7RR5uaZ2ydbg==&use_mirror=master&r= 404 Not Found [IP: 82.71.205.33 443]
E: Failed to fetch https://downloads.sourceforge.net/project/openfoam/repos/deb/dists/bionic/main/binary-all/Packages?ts=gAAAAABlU0ddOvkkOuXCeg05riwpnOabnmAYq42Yl6AoBItkbuf95la7On9UFcH_JnZb9QeAH4IobNvAs2ekXvWON2UqNm0oVQ==&use_mirror=master&r= 404 Not Found [IP: 82.71.205.33 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.
```
### 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 -->
No errors.
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
- Operating system : WSL Ubuntu 18.04 LTS
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Based on some threads like:
https://unix.stackexchange.com/questions/148303/apt-get-install-gives-404-not-found-but-url-works
it could be a bug with apt.
Or it could be a problem with the installer script.https://develop.openfoam.com/Development/openfoam/-/issues/2925Tensor operations: taking the inner product of three tensors produces a diffe...2023-11-17T19:24:36ZRyley McConkeyTensor operations: taking the inner product of three tensors produces a different result depending on if an intermediate variable is used<!--
*** 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
The following operations do not produce the same result for C :
1. C = A & A & A;
2. B = A & A; then C = B & A;
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Here is an example set of operations. Tensors B2a and B2b should be equal (since they are both S & S & S), but the results are different.
```
S = symm(fvc::grad(U));
B1 = S & S;
B2a = S & S & S;
B2b = B1 & S;
```
### 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 have attached an example case and example application that writes the above two results.
### What is the current *bug* behaviour?
A different result is produced for the two operations.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The two operations should produce the same result. I believe the second result (after using an intermediate variable) is correct mathematically. I am not sure yet what operation is being performed in the first case (S & S & S).
<!-- 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.
-->
![Screenshot_from_2023-06-29_14-10-26](/uploads/cd1596da5d86af14d126bc93c02b109d/Screenshot_from_2023-06-29_14-10-26.png)
### 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 : v2112
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->[case_0p5.zip](/uploads/bb01c9483630e4766047cdd604e4a897/case_0p5.zip)[writeFields_test.zip](/uploads/e1acfc378b8ff008c795511c01ca5bec/writeFields_test.zip)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3031BUG: multiple mapFields2023-11-21T14:27:42ZKutalmış BerçinBUG: multiple mapFields### Summary
The problem is that, apart from the first 'mapFields' function object, the following 'mapFields' function objects don't appear to be registering the fields they're working on to the correct region. For instance, in the probl...### Summary
The problem is that, apart from the first 'mapFields' function object, the following 'mapFields' function objects don't appear to be registering the fields they're working on to the correct region. For instance, in the problematic case below, the 'mapFields2' function object maps the 'UMean' from 'region0' to 'coarseMesh'. However, the object registry of 'coarseMesh' lacks any 'UMean'.
### Steps to reproduce
[2274-multiple-mapFields-21Nov23-GitLab.zip](/uploads/656e6c1e94ae2143f2373bad13ea4927/2274-multiple-mapFields-21Nov23-GitLab.zip)
### Environment information
api = 2308
HEAD = 0ae6141397
compiler = clang version 15.0.7
mpi = mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = openSUSE Leap 15.5
opts = linux64ClangDPInt32Opt
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/2924resdistributePar -decompose fails in postChannel tutorial2023-11-22T07:22:27ZTimofey MukharesdistributePar -decompose fails in postChannel tutorial<!--
*** 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
Running
`mpirun 36 redistributePar -decompose -parallel`
in `planeChannel/results/DFSEM` crashes with
`[20] Cannot find point in pts1 matching point 0 coord:(57.65 0.88207685 3.1415927) in pts0 when using tolerance 6.2398167e-06`
and a following cascade of errors.
### Steps to reproduce
Go to the planeChannel tutorial, and run ./Allrun to generate the cases. Then execute `redistributePar` as above.
### A comment
I would like to stress that getting this utility to work properly, also in conjunction with the collated file format, is absolutely critical for LES/DNS runs. Serial `decomposePar` is just no longer an option, once the number of processors is in the order of thousands.
### 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 : master @ spack
- Operating system : Linux
- Hardware info : LUMI C node/ AMD EPYC 7742 64-Core Processor
- Compiler : gcc (SUSE Linux) 7.5.0Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3032redistributePar slow with preservePatches cosntraint2023-11-23T07:14:20ZTimofey MukharedistributePar slow with preservePatches cosntraintFollow-up to #2924, but not necessarily related in terms of what causes the issue.
To reliably decompose cyclic boundaries with `redistributePar` we currently need to use the `preservePatches` constraint for the cyclic boundaries. Unfor...Follow-up to #2924, but not necessarily related in terms of what causes the issue.
To reliably decompose cyclic boundaries with `redistributePar` we currently need to use the `preservePatches` constraint for the cyclic boundaries. Unfortunately, this seems to cause a strong dip in performance of the utility. According to @Mattijs this should not really happen. I have first observed this on my own case, but now got some numbers using the `periodicHill` tutorial.
I use the `steadyState` case in the tutorial, bump the number of processors in `decomposeParDict` to 32, and accordingly switch to 4 partitions along y. Additionally, we add
```
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (inlet outlet);
}
}
```
which we can comment and uncomment to compare.
Furthermore, it is better to make the case a bit larger, so in `blockMeshDict` we set the size of the `hex` to `(200 160 400)`, and then run `blockMesh`.
Now, we decompose the case with
`time mpirun -n 32 redistributePar -decompose -latestTime -parallel -fileHandler collated`
On my machine, I get a 3x slowdown when preserving the patches.https://develop.openfoam.com/Development/openfoam/-/issues/1601Feature request: sedFOAM submodule2023-11-24T16:26:48ZKutalmış BerçinFeature request: sedFOAM submodule### Functionality to add/problem to solve
http://servforge.legi.grenoble-inp.fr/pub/soft-sedfoam/
https://github.com/sedfoam/sedfoam
Following the short discussion in their repo: https://github.com/SedFoam/sedfoam/issues/15
the mainta...### Functionality to add/problem to solve
http://servforge.legi.grenoble-inp.fr/pub/soft-sedfoam/
https://github.com/sedfoam/sedfoam
Following the short discussion in their repo: https://github.com/SedFoam/sedfoam/issues/15
the maintainer of sedFOAM showed keen interest on OpenFOAM's submodule functionality.
sedFOAM is represented as a code suite for two-phase flow sediment flow applications.
### Target audience
Wave/free surface involved applications, e.g. masts erected in sea bed, tidal turbines, or in general, underwater structures close to sea bed (might misunderstand).
### Proposal
If the maintenance cost of adding and shipping a new submodule is very low for OpenFOAM, sedFOAM submodule would be a win-win.
### What does success look like, and how can we measure that?
The suite is based on a set of publications, and has its own user group (it seems). Also, reasonably well maintained by a group of people, compatible with recent OF versions.
### Funding
NA
@andy @mark @Mattijs @Sergio @Prashant @RogerKutalmış 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/2788openfoam conda2023-11-26T17:23:29ZHenning Scheufleropenfoam condaA possibility to install OpenFOAM without admin rights is conda:
https://github.com/HenningScheufler/conda-openfoam
The installation process would be quite straightforward. Download and install the miniconda then run following commands...A possibility to install OpenFOAM without admin rights is conda:
https://github.com/HenningScheufler/conda-openfoam
The installation process would be quite straightforward. Download and install the miniconda then run following commands:
```bash
conda create -n openfoam # create new env named openfoam
conda activate openfoam # activate the enviroment
conda install openfoam -c conda-forge # download and install openfoam from conda forge
```
This could simplify the installation on workstations. For HPC spack is probably the better optionhttps://develop.openfoam.com/Development/openfoam/-/issues/3036epsilonWallFunction: Expression of espilon in log layer2023-11-27T17:35:31Zs1291epsilonWallFunction: Expression of espilon in log layerIn this documentation page about [`epsilonWallFunction`](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-epsilonWallFunction.html), the expression of $\epsilon_\text{log}$ is given by:
$$
\epsilon_\tex...In this documentation page about [`epsilonWallFunction`](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-epsilonWallFunction.html), the expression of $\epsilon_\text{log}$ is given by:
$$
\epsilon_\text{log} = wC_\mu\frac{k^{3/2}}{\nu_{t,w}y} \tag{1}
$$
However, in the [source code](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/epsilonWallFunctions/epsilonWallFunction/epsilonWallFunctionFvPatchScalarField.C#L225), the following expression is used:
$$
\epsilon_\text{log} = wC_{\mu}^{3/4}\frac{k^{3/2}}{\kappa y} \tag{2}
$$
Unless the expressions $\frac{C_\mu}{\nu_{t,w}}$ and $\frac{C_{\mu}^{3/4}}{\kappa}$ are equivalent, the expression (1) should be corrected in the documentation.
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/3040Turbulence model not runtime selectable2023-12-05T11:50:08ZBas NieuwboerTurbulence model not runtime selectable<!--
*** 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 I change a turbulence model during runtime, the turbulence properties are re-read as shown by the log: "Re-reading object turbulenceProperties from file ". However, the turbulence model itself does not change. I've tested this on openfoam V2306 and V1712 (oldest one I have on my machine).
It might be a design choice not to have this feature. However, I cannot find any warning on this in the documentation (or in the log). I might be a an odd one, wanting to change the turbulence model during runtime. I would like to change the turbulence model, since it allows using a more stable turbulence model during startup and changing it to a more accurate one during runtime.
### Steps to reproduce
1) Take the incompresseble TJunction case: (tutorials/incompressible/pimpleFoam/RAS/TJunction)
2) Increase the simulated time (say 15 s) to ensure you have time to change the turbulence dict before the end of the simulation
3) run blockMesh
4) run pimpleFoam > log
5) Change the turbulence model to kOmega in turbulenceProperties
- This should cause a crash, since the Omega field is not created/read. However, the solver just keeps on running
- Check if the turbulence properties is changed by looking for: "Re-reading object turbulenceProperties from file " in the log file.
### Example case
the incompresseble TJunction case: (tutorials/incompressible/pimpleFoam/RAS/TJunction)
### What is the current *bug* behaviour?
The simulation keeps on running using the kEpsilon model
### What is the expected *correct* behavior?
The simulation should crash, since the Omega field is not present.
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : aff5c3b680-20230703 OPENFOAM=2306 version=v2306 | v1712
Operating system : ubuntu 18.04
Compiler : gcc
### 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/3012variableHeightFlowRateInletVelocity & dynamic meshes2023-12-06T14:53:25ZShannon LeakeyvariableHeightFlowRateInletVelocity & dynamic meshes### Summary
A colleague (Bernardas Jankauskas) and I have been investigating a problem where `variableHeightFlowRateInletVelocity` doesn't seem to work with dynamic meshes. The problem has also been mentioned on [CFD Online](https://www....### Summary
A colleague (Bernardas Jankauskas) and I have been investigating a problem where `variableHeightFlowRateInletVelocity` doesn't seem to work with dynamic meshes. The problem has also been mentioned on [CFD Online](https://www.cfd-online.com/Forums/openfoam/220909-variableheightflowrateinletvelocity-whith-dynamicmesh.html) by another user.
### Steps to reproduce
1. Copy the `weirOverflow` tutorial for `interFoam`
2. Add a `constant/dynamicMeshDict` file
3. Add a `0.orig/pointDisplacement` file
4. Amend `system/fvSolution` to include a solver for `cellDisplacement`
5. Run without making any changes to the boundary condition (it crashes)
6. Run after changing `value` in the `inlet` boundary condition in `0.orig/alpha.water` to `0.000001` (it doesn't crash)
### Example case
[weirOverflow.zip](/uploads/cb578ffdd40af3da21be22650d40d716/weirOverflow.zip)
### What is the current *bug* behaviour?
Divide by zero [on this line](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/variableHeightFlowRateInletVelocity/variableHeightFlowRateInletVelocityFvPatchVectorField.C#L124)
### What is the expected *correct* behavior?
It shouldn't divide by zero
### Relevant logs
```
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 Foam::variableHeightFlowRateInletVelocityFvPatchVectorField::updateCoeffs() at ??:?
#4 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() at ??:?
#5 Foam::dynamicMotionSolverFvMesh::update() at ??:?
#6 ? at ??:?
#7 __libc_start_main in /lib64/libc.so.6
#8 ? at ??:?
```
### Environment information
- OpenFOAM version: v2112
### Possible fixes
`(alphap + VSMALL)` but that wouldn't explain why it thinks `alphap` is zero only when a dynamic mesh is used?https://develop.openfoam.com/Development/openfoam/-/issues/2442chtMultiRegionFoam with anistropic diffusivity2023-12-07T05:40:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam with anistropic diffusivity### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the proper...### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the properties
- if the thermo properties change (e.g. temperature varying alpha)
- if the coordinate system changes (e.g. cylindrical coordinate system, pivoting across second axis)
### Target audience
Anyone using cht with changing solid properties.
### Proposal
Two possibilities:
- have option to update/correct coordinate system and update anisotropic diffusivity accordingly
- not cache aniAlphas but calculate it on-the-fly
@mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/3047mapDistribute does not support non-blocking2023-12-09T18:13:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commapDistribute does not support non-blocking### Functionality to add/problem to solve
mapDistributeBase supports non-blocking / two-stage communication + consumption. This is not mapped through to mapDistribute. This is currently not used (e.g. non-blocking cyclicAMIFvPatchField ...### Functionality to add/problem to solve
mapDistributeBase supports non-blocking / two-stage communication + consumption. This is not mapped through to mapDistribute. This is currently not used (e.g. non-blocking cyclicAMIFvPatchField applies its own transformation). It might be useful if we want to extend e.g. wall distance calculation to use this two-stage process.
### Proposal
Add an send/receive equivalent to mapDistribute to replace the single mapDistributeBase::distribute.https://develop.openfoam.com/Development/openfoam/-/issues/3041cht solid temperature distribution2023-12-11T19:23:58ZPekkacht solid temperature distribution### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region...### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region case.
In pureZoneMixture case temperature distribution look that heat goes from lower to higher temperature. In pureMixture case heat flux does not match between regions. Temperature distribution looks logical but temperature levels are much higher that single region case.
![T2](/uploads/7aaa99e1c9251e903504ed2ac6cd0726/T2.png)
### Steps to reproduce
Please find attached cases. By looking heat flux data from log files and temperature distribution is possible notice difference between mixture models.
### Example case
### What is the current _bug_ behaviour?
Results are unreliable
### What is the expected _correct_ behavior?
In pureZoneMixture case temperature distribution can be "fix" by setting the same Cp values to all materials. I think that in solid solver is used alpha instead of kappa in temperature equation.
### Relevant logs and/or images
T fixed wall0 to 300 and wall1 to 400 K. Heat source 10 W in middle of the model. pureZoneMixture heat flux:
```plaintext
min/max/integ(wall0) = -1322.838, -1322.838, -132.2838
min/max/integ(wall1) = 1222.838, 1222.838, 122.2838
```
difference between in and out 10 W and it is OK. Respectively pureMixture case
```plaintext
min/max/integ(wall0) = -114.41282, -114.41282, -11.441282
min/max/integ(z1_to_z2) = 594.6436, 594.6436, 59.46436
min/max/integ(z2_to_z1) = -594.6436, -594.6436, -59.46436
min/max/integ(z2_to_z3) = 2408.3388, 2408.3388, 240.83388
min/max/integ(wall1) = -15889.687, -15889.687, -1588.9687
min/max/integ(z3_to_z2) = -2408.3388, -2408.3388, -240.83388
```
wall0 and wall1 difference is much higher (1588 - 11) than 10 W.
### Environment information
- OpenFOAM version : v2212
- Operating system : AlmaLinux 8
- Hardware info : Intel Core 8
- Compiler : gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)
### Possible fixes
\[chtCases.zip\](/uploads/0b33599299701063e04e68c42a50fb47/chtCases.zip
[chtCases.tar.xz](/uploads/12757bc6320abcbbc15e9fded6189f8e/chtCases.tar.xz)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3056checkMesh writes fields with 'calculated' also on empty patches2023-12-13T17:10:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh writes fields with 'calculated' also on empty 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 -->
`checkMesh -writeAllFields` on case with empty writes volFields with 'calculated' on empty patches. E.g. paraview does not like this at all.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cavity tutorial
checkMesh -writeAllFields
```
and look at e.g. `faceWeight` on frontAndBack empty patches.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Probably not override the empty constraint? Or have paraview accept `patchType` override?
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3055snappyHexMesh :: Prediction of maxNewCells wrong with new code2023-12-15T22:25:11ZTobias HolzmannsnappyHexMesh :: Prediction of maxNewCells wrong with new code<!--
*** 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
Hey everybody,
in v2306, the balancing method within snappy was improved based on the code snippet I provided to L2.
https://develop.openfoam.com/Development/openfoam/-/merge_requests/607
The issue appears now due to a one-liner change from Mattijs:
- This line now calculates only zero for the `maxLocalCell` variable, if we first refine and then balance https://develop.openfoam.com/Development/openfoam/-/commit/4a5f542cb431665fc85165e13b29ab1202b99aa3#31acf059fb90704d54379ac0c705eac1a85803dd_2601_2632
- This is related to the fact that this line was introduced by Mattijs to fix the wrong `balance` calculation: https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/mesh/snappyHexMesh/meshRefinement/meshRefinementRefine.C?ref_type=heads#L2762
Hence, the calculation of `maxLocalCells` is wrong (as it is zero all the time and the trigger value will never be taken into account). However, this value is mainly necessary if e.g., locally on one single proc a refinement happens significantly (imagine a refinement based on the surfaceFeatureAngle while using a `level (4 6)` refinement for example.
The discrepancy at the moment is:
- The balancing factor is calculated correctly (in previous versions we were over predicting the nNewCells value due to the fact that the refinement took place alreads)
- On the other hand, the balancing trigger value `maxLocalCells` is zero now (if refineAndBalance is used) and thus, the trigger will not be used anymore
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
To check that the values of `maxLocalCells` are always zero, simply execute snappyHexMesh while having `maxLocalCells 100000000;` to explicitly go step into the `refineAndBalance` function rather than `balanceAndRefine`.
<!-- How one can reproduce the issue - this is very important -->
<!--
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?
Described in the summary.
<!-- What actually happens -->
### What is the expected *correct* behavior?
If we use `refineAndBalance` the `maxLocalCells` should be calculated correctly.
<!-- What you should see instead -->
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->